Hi,
I’m in the process of creating a NDIS(6) filter driver, and I’ve come a across, what I believe is strange behavior. Starting with the sample ‘NDIS 6.0 filter Driver’, I modified the ‘FilterReceiveNetBufferLists’ as follows:
Use_decl_annotations
VOID
FilterReceiveNetBufferLists(
NDIS_HANDLE FilterModuleContext,
PNET_BUFFER_LIST NetBufferLists,
NDIS_PORT_NUMBER PortNumber,
ULONG NumberOfNetBufferLists,
ULONG ReceiveFlags
)
{
…
PNET_BUFFER_LIST pCurrentNbl;
ULONG NetBufferCount;
pCurrentNbl = NetBufferLists;
for (NetBufferCount = 0; NULL != pCurrentNbl; NetBufferCount++)
{
pCurrentNbl = NET_BUFFER_LIST_NEXT_NBL (pCurrentNbl);
}
FILTER_ASSERT (NetBufferCount == NumberOfNetBufferLists);
…
The problem is – the above FILTER_ASSERT fails. When I WinDbg it, I see that NumberBufferLists is 4, but I’m only seeing 2 NBLs in NetBufferLists ??
I should point out that this does not seem to be the case for all machines/NICs – the first machine I tried this on did not fail the ASSERT.
Am I missing something – is NumberOfNetBufferLists supposed to represent something else. incidentally, if I use NumberOfNetBufferLists in my subsequent call to NdisFIndicateReceiveNetBufferLists, then everything works fine. However, if I use NetBufferCount (on this machine), then all is not fine – I basically lose communication over the NIC.
Any ideas?
Thanks
/Paul
The truth is that the OS doesn’t actually use the NumberOfNetBufferLists parameter, and our logo tests don’t validate that it’s passed up correctly. So I’m afraid that if some NIC or filter driver gets it wrong, nobody would notice.
And I’ve learned that if something is permitted to go wrong without anybody noticing, then it most certainly will go wrong.
I suggest ignoring the parameter.
(I hope you didn’t spend too much time questioning your own ability to count to 4 or write for-loops.)
But, it seems that Paul is saying that in this case when he counts NBLs he
finds 2 instead of the 4 indicated in the NDIS-provided
NumberOfNetBufferLists parameter.
If he uses his own count (2) when calling
NdisFIndicateReceiveNetBufferLists he looses communication over the NIC.
If he uses NumberOfNetBufferLists (suggested to be ignored), then he
doesn’t loose communication over the NIC.
Catch 22.
This is probably when lower-level indicates with NDIS_STATUS_RESOURCES.
Thomas F. Divine
On Wed, Jan 29, 2014 at 4:15 PM, Jeffrey Tippet <
xxxxx@microsoft.com> wrote:
The truth is that the OS doesn’t actually use the NumberOfNetBufferLists
parameter, and our logo tests don’t validate that it’s passed up correctly.
So I’m afraid that if some NIC or filter driver gets it wrong, nobody
would notice.
And I’ve learned that if something is permitted to go wrong without
anybody noticing, then it most certainly will go wrong.
I suggest ignoring the parameter.
(I hope you didn’t spend too much time questioning your own ability to
count to 4 or write for-loops.)
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
Thomas F. Divine
http://www.pcausa.com
Hmm, I missed the part about losing network connectivity. That baffles me. We might use the field when doing translation to NDIS_PACKET arrays - do you have any legacy NDIS 5.x drivers (especially NDIS 5 Filter-IM drivers) in the picture?
Do you have access to a CHK version of NDIS.SYS from Windows 8.1? (E.g., a MSDN subscription). I added
ASSERT(NumberOfNetBufferLists == ndisNumNblsInNblChain(NetBufferLists));
to the receive path of all NICs and filters. If there’s hijinks going on, this will catch the offending driver.
>do you have any legacy NDIS 5.x drivers (especially NDIS 5 Filter-IM drivers) in the picture
Oh sure, we’re the bad guys 
Dave Cattley
> Any ideas?
Can you show us a full stack backtrace when this condition occurs?
The first thing that comes to mind is that some other component (other than the NIC itself) is between you and the original indication and that it has botched the handling of either the count or the NBL chain.
Good Luck,
Dave Cattley
Opps.
Turns out, this one is on me. Well, mostly on me I guess.
The mis-matched NumberOfBufferLists is the result of the following code at the end of my FilterReceiveNetBufferLists:
ReturnFlags = 0;
if (NDIS_TEST_RECEIVE_AT_DISPATCH_LEVEL (ReceiveFlags))
{
NDIS_SET_RETURN_FLAG (ReturnFlags, NDIS_RETURN_FLAGS_DISPATCH_LEVEL);
}
NdisFReturnNetBufferLists (FilterHandle, SunkNbls, ReturnFlags);
So what is SunkNdls? It is a PNET_BUFFER_LIST who is ?supposed? to represent the set of NBLs that are being ?filtered?, or sunk, by this filter driver. However, that portion of my code is currently disabled as I simply wanted to pass all of the NBLs along though my driver without filtering anything. So in this instance, SunkNbls is NULL. If I qualify the above logic so that it only does it when SunkMbls is non-NULL (which is never), then I no longer see the mis-matched NumberOfBufferLists. Furthermore, calling NdisFReturnNetBufferLists with a NULL SunkNbls is also the source for my computer losing communication for the NIC. So clearly, this is not something NdisFReturnNetBufferLists is expecting, so it?s not something I should be doing.
Thanks for your suggestions.
/Paul