Hello folks,
We have a NDIS Lightweight filter based on the WDK “filter” sample, it’s working pretty well but we are facing an annoying issue when it comes to unloading it.
In our FilterReceiveNetBufferLists routine, we are creating a copy of the received buffer and originating a receive indication with the copy (including the NDIS_RECEIVE_FLAGS_RESOURCES flag). The original buffer is returned using NdisFReturnNetBufferLists.
It’s worth noting that we are making a new copy and calling NdisFIndicateReceiveNetBufferLists for every buffer in the received buffer list, so this means that we may be indicating several times for one NBL received.
Of course, we are freeing the new buffers right after returning from the indicate call.
Also, we are doing passthrough for every receive having the NDIS_RECEIVE_FLAGS_RESOURCES flag.
It seems to work fine, but we are having problems with the Unload phase, when there is some application using the network. If, for example, Dropbox is running (not necessarily uploading or downloading content, just active) and we try to unload the filter, the system enters in an almost freezed state, and the driver won’t unload until we close Dropbox; then everything goes back to normality and our filter unloads without problems.
Tracing our driver we can see several calls to FilterPause for the adapters and protocols installed on the system.
The hang occurs after returning from the FilterPause that corresponds to the NIC miniport. This is the stack:
[83d46958 System]
4.000040 83daf798 0003019 Blocked nt!KiSwapContext+0x26
nt!KiSwapThread+0x266
nt!KiCommitThreadWait+0x1df
nt!KeWaitForSingleObject+0x393
nt!ExWaitForRundownProtectionReleaseCacheAware+0x9c
tcpip!FlUnbindAdapter+0x61
ndis!ndisUnbindProtocol+0x235
ndis!ndisCloseMiniportBindingsForPause+0x1d3
ndis!ndisDetachFilter+0x288
ndis!NdisFDeregisterFilterDriver+0xf0
MYDRIVER!FilterUnload+0xc2
nt!IopLoadUnloadDriver+0x1e
nt!ExpWorkerThread+0x10d
nt!PspSystemThreadStartup+0x9e
nt!KiThreadStartup+0x19
Then when we close Dropbox, we can see NDIS calling FilterRestart, FilterPause and finally FilterDetach.
Doing some disassembly we have seen that after closing Dropbox, the system signals the event that unblocks us, and that TCPIP frees the NBL list calling “flpFreeNetBufferListChain”, so it seems pretty clear that the problem is related to buffers, so we tracked every indication, returning buffer, and so on, but we don’t see any buffer loss or mishandling.
Also, the NDISKD debugger extensions didn’t help me; trying to find pending NBLs shows this:
3: kd> !ndiskd.pendingnbls
Type information missing error for ndisGlobalNetBufferListPoolList
PHASE 1/3 Found 0 NBL pool(s).
Type information missing error for ndisMaxNumberOfProcessors
PHASE 2/3: Found 0 freed NBL(s).
Pending Nbl Currently held by _
No pending NBLs were found.
PHASE 3/3: Found 0 pending NBL(s) of 0 total NBL(s).
Search complete.
BTW, got the same output with the checked build version.
So, any ideas?
Thanks a lot in advance!