Why my NDIS filter driver' FilterReceiveNetBufferLists handler is not called?

Question

everyone. It's me again, the guy porting WinPcap from the NDIS 6 protocol to NDIS 6 filter:) I have encountered a bug, which trapped me for two days. Here it is: After I installed the npf6x.sys driver (original named npf.sys), the service can be started by "net start npf". Then I opened Wireshark. Then the network got down (an exclamation mark on the tray icon). After remote debugging, I found the FilterReceiveNetBufferLists routine is never called. I believe the RX link was broken here. However, FilterSendNetBufferLists is called normally. I'm sure the FilterAttach has been successfully called and no FilterUnload is called now. So the filter module should be still in its place. But it just cannot work in the RX path. Then I clicked the "Start" button of Wireshark, I unexpectedly found the network had recovered. Then I stopped the current capture and clicked "Interface List", the network was down again. It is so weird.

I didn't change the handler pointer in the running process of the driver. I seems that the driver is not blocked by locks too. Can anyone tell me if there is any case to cause NDIS not to call the FilterReceiveNetBufferLists of a filter during its running?

Also are there any offcial documents addressing how to port from NDIS 6 protocol to NDIS 6 filter? I only found documents for porting from NDIS 5 to NDIS 6.

thanks.

Answer 1

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 its MiniportSendNetBufferLists 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. . . .