Overview of NDIS Debugging

The two primary tools for debugging a network driver are debug tracing and the Network Driver Interface Specification (NDIS) extensions. For more information on debug tracing, see Enabling NDIS Debug Tracing. For more information on the NDIS debugging extensions, see NDIS Extensions, which provides a complete list of the extension commands found in the extension module Ndiskd.dll.

Use the ndiskd.netreport command to generate a visual report showing the current adapters and protocols.

Screenshot of ndiskd.netreport color-coded output displaying two columns representing various network adapters.

Then the ndiskd.netadapter kernel debugger command is a good place to start to investigate the current set of the drivers.

1: kd> !ndiskd.netadapter
    Driver             NetAdapter          Name
    ffffdf8015a98380   ffffdf8015aa11a0    Microsoft ISATAP Adapter #2
    ffffdf801418d650   ffffdf80140c71a0    Microsoft Kernel Debug Network Adapter

An additional tool for debugging a network driver is the collection of regular debugging extensions, which are useful for obtaining debugging information. For example, entering !stacks 2 ndis! displays all threads in the stack beginning with ndis!. This information can be useful for debugging hangs and stalls. For general information about getting started with the WinDbg, see Getting started with Windows Debugging.

Driver Verifier

Another useful tool for testing an NDIS driver is NDIS Verifier. For more information, see Rules for NDIS Drivers and Static Driver Verifier.

NDIS Debugging Resources

Episode 175 of the Defrag Tools show covers NDIS debugging - Defrag Tools #175 - Debugging the Network Stack.

The NDIS team blog archives are available at The NDIS blog.

NDIS Bug checks

There is also a NDIS-specific bug check code, bug check 0x7C (BUGCODE_NDIS_DRIVER). For a complete list of its parameters, see Bug Check 0x7C.

A common NDIS misbehavior related bug check is Bug Check 0xD1: DRIVER_IRQL_NOT_LESS_OR_EQUAL which can be caused by the driver code itself. This is most likely a bug or memory corruption that eventually manifests itself as a bad pointer.

Another common issue is Bug Check 0x9F: DRIVER_POWER_STATE_FAILURE.

First step with all bug checks is to locate a good dump file, load it in the Windows debugger and use the !analyze command. For more information, see Using the !analyze Extension.