Defrag Tools #175 - Debugging the Network Stack

Sign in to queue

Description

In this episode of Defrag Tools, Chad Beeder is joined by Jeffrey Tippet from the Windows Networking team to talk about how to debug networking problems in NDIS (Network Driver Interface Specification) using the !ndiskd debugger extension in WinDbg.

Resources:
The NDIS Blog

Timeline:
[00:00] Introductions
[01:10] What is NDIS (Network Driver Interface Specification)
[03:11] Common problems encountered by the Networking Team. (Bug Check 0x9F DRIVER_POWER_STATE_FAILURE, Bug Check 0x133 DPC_WATCHDOG_VIOLATION)
[06:27] Introducing the !ndiskd debugger extension. Start with !ndiskd.help
[10:27] !ndiskd.netreport gives you a Network Debug Report including graphical overview of the network configuration
[18:23] !ndiskd.netreport -verbose takes much longer to run, but gives a lot more detail including animations of how many packets are going over each adapter
[22:58] To enable the logging of recent network traffic, and get the animations in the netreport, enable NBL Logging by setting a registry key (documented here).
[25:20] Wi-Fi can act like an access point in some cases (i.e. Wi-Fi Direct). How this shows up in the Network .
[27:30] The other tabs on the report: Useful if you need to send the report to someone else.
[31:34] DRIVER_POWER_STATE_FAILURE debugging tips: Use !ndiskd.oid to see which network OIDs (networking requests) are pending. One of these may be the power request which is holding up the network stack.
[34:40] DPC_WATCHDOG_VIOLATION debugging tips
[37:15] Comments/questions? Email us at defragtools@microsoft.com

Embed

Download

The Discussion

  • User profile image
    JMSPT

    Hello Guys, great show, this new way of viewing dumps and is really great.

    - I wish that you could do more episodes with windbg cmds for real troubleshooting scenarios, for example NIC dropped packets, communication errors, how to search and related the threads where communications were happening and how to check the destination IPs where communicating at the time of the crash, I also have seen some weird problems with arp cache that I usually solve by clean it with arp -d cmd, but not sure why it happens, can we catch router related errors like spanning tree, etc... (Is it possible to do this post-morten/LiveDebug or we still need a network analyzer to get that information).

    - I tested this on some crashes that I have for Windows 2008 and appears the report will not show all information, for example IP Address is missing and I get some symbol resolution errors for  tcpip!_IP_PROTOCOL, tcpip!_IP_INTERFACE, perhaps it only works for latter OS??!!

    - I have a final question regarding to new protocols introduced since windows vista, appears that when we`re using a given IP in a given subnet and we try to ping an online address in the same subnet, pathping will show that we`re using the correct interface (with the same IP for the same subnet), but when the IP does not exist or the destination server is offline, Windows will try to use the interface with default Gateway!!! Do you know if this behavior is related with any of the newer protocols introduced in windows Vista (in previous OS this didn`t happen)?

    Thank you for all the great shows, learning a lot...

  • User profile image
    Steve Madden

    I found a website from which i get rid out of this type of error problem, now you can also check this for getting rid of it completely: http://www.techinpost.com/fixed-error-driver-power-state-failure-code-problem

Add Your 2 Cents