Share via

Diagnostics tools in NDIS

  • Article

Evolving beyond DbgPrint

I'd like to take a break from our series on WMI (don't worry -- more WMI is coming soon!)  to respond to a recent discussion in the community.  Traditionally, we've used DbgPrint to debug NDIS issues.  This is convenient, since you can see the traces right in the kernel debugger as you're interacting with the system.  But it has a number of drawbacks, as well:

  1. Because DbgPrint trace statements take up a lot of space (the entire trace message is stored as a string in NDIS.SYS), we only include them in CHK builds of the OS.  It's often inconvenient or impossible to deploy a CHK version of NDIS.SYS to a customer.  (Although you should use CHK builds in-house when developing an NDIS driver!)
  2. There is a noticeable performance overhead to DbgPrint.  Each trace statement must stop into the debugger, emit the message, and resume running the OS.  This makes it unusable for tracing network packets, and it often perturbs the system enough that race conditions don't repro when tracing is enabled.
  3. Trace messages are only meant to be consumed in the debugger.  Tools like DebugView help, but it is still pretty intimidating to walk an end-user through the steps to collect the debug log.

With that in mind, I'd like to offer two alternative diagnostics tools, available starting with Windows 7 and Windows Server 2008 R2.  In order to prevent this blog post from becoming a blog novel, I've created a separate page for each tool:

Continue reading about the Event Viewer Continue reading about WPP I already know how to use WPP; just give me the TMF files!