We have no official documentation on LWF->Protocol, since that's not a very common transition.
It's hard to say what's caused the network to go down, since there can be many causes. The best approach is to use a kernel debugger and start analyzing things with !ndiskd.miniport
. Here's a general checklist of things to look at when the network goes down:
- Is the miniport in a normal state? Check that
!ndiskd.miniport
shows everything in the STATE area as green or normal-looking. Make sure the datapath is normal (not bypassed) and the media connect state is connected. - Is your filter driver loaded where you think it should be loaded? Check that
!ndiskd.miniport
's BINDINGS section shows your filter being listed. If you're using the new Windows 8.1 WDK, also check that the filter's binding isn't "declined". - Does the miniport's receive filter allow the usual set of incoming packets? Check that
!ndiskd.miniport -filterdb
shows the miniport has at least DIRECTED and MULTICAST traffic allowed in. - Is the miniport attempting to indicate traffic? Set a breakpoint on
ndis!NdisMIndicateReceiveNetBufferLists
, and verify that the breakpoint hits frequently, as the NIC is giving received packets to the OS. - Is TCPIP attempting to send traffic? If TCPIP isn't sending traffic, then there won't be any replies to receive. Set a breakpoint on
ndis!NdisSendNetBufferLists
to see if TCPIP is sending any traffic. If it is, set another breakpoint on the miniports send handler (use!ndiskd.minidriver
to find itsMiniportSendNetBufferLists
handler) and verify that the send packets are making it down to the NIC. - Is the miniport's pool of receive packets empty? If so, the miniport won't be able to indicate any more packets, because it has run out of NBLs. Use
!ndiskd.pendingnbls
to see if there are any NBLs that haven't been returned yet. It's typical for it to find zero or maybe one pending NBL; if you see it find hundreds, then there's an NBL leak in your filter. - Has the miniport noticed any problems? Check the miniport statistics. In Windows 8, use
Get-NetAdapterStatistics
from PowerShell.
If you're new to Windows kernel network debugging, it will be difficult for you to determine whether some things look good or bad. Ideally, you'd have another working computer to debug, so you can see what "normal" looks like.
If your search still doesn't turn up anything useful, another angle of attack is to do a binary search on the code changes you've made. First, comment-out all the changes you made to your filter's receive path, and restore it to exactly like in the sample. Does that fix the problem? If so, continue. . . .