BSOD when running Wireshark with Ndis IM driver installed

NTDEV
21

That would be weird, because the backtrace indicates an issue on the Rx path.

22

One thing to look at is if NDIS_RECEIVE_FLAGS_RESOURCES is properly handled (along with other flags if any set in ReceiveNBLs() callback)

23

Thanks msr, I am suspecting the same and it looks like it isn’t handled properly. Debugging along those lines.

In the sample code itself, when NDIS_RECEIVE_FLAGS_RESOURCES is set in the ProtocolReceiveNBL callback, I do not see a copy being made of the NBL. Also, if this flag is set, we need to maintain the NBL linked list structure as is, so that is definitely an issue in my case.

I am unsure as to why the sample (https://github.com/Microsoft/Windows-driver-samples/blob/master/network/ndis/mux/driver/60/protocol.c#L2635) does not make a copy of the packet. In fact, in the following cases, no Ndis call is being made at all:

  1. Packet filter is 0 and NDIS_RECEIVE_FLAGS_RESOURCES is not set

Also the PtReceive callback is calling into NdisMIndicateReceiveNetBufferLists.

So when is PtReceiveNBL supposed to call NdisMIndicateReceiveNetBufferLists vs NdisReturnNetBufferLists()?

24

UPDATE:

I have resolved this issue.

The issue arose from the fact that in my ProtocolReceiveNbl callback, the NDIS_RECEIVE_FLAGS_RESOURCES was not being handled. For some reason, probably due to high CPU consumption, on starting Wireshark my ProtocolReceiveNbl function would get the returnFlags with NDIS_RECEIVE_FLAGS_RESOURCES set, and the code was not honoring the flag to make sure the NBL chain passed to my function is preserved. The other issue was that I was always calling NdisReturnNetBufferLists() from my ProtocolReceiveNbl function irrespective of the flags.

So it looks like Wireshark just happened to manifest this issue, the the real issue was that NDIS_RECEIVE_FLAGS_RESOURCES flag needs to be handled carefully in the ProtocolReceiveNbl callback.

Thanks guys for the help.

25

A while I worked on this path, but below is how it is

  1. Miniports call Ndis"M"IndicateReceiveNbls() - Miniport owns the NBLs

  2. Ndis.sys receives those - NDIS owns those NBLs

  3. Now NDIS has bunch of protocols sitting on top edge of miniport to indicate those NBLs to

  4. Protocols subscribe to ether types, most of then are IP, some are specific ~IP (FCoE) etc.

  5. NDIS.sys based on the ether type tries it best (BEST effort) to indicate only those subscribed ether type NBLs() to protocols
    5.1) So protocols need to skip NBLs they are not interested in.

  6. Protocols receive the NBLs() in ProtocolReceiveNetBufferLists(…,…, Flags).

  7. If ~Resources - Protocol owns those NBLs - Protocol has to specifically call NDis"Return"NBls()

  8. If Resources, the NBLs() ownership returns to NDIS.sys as soon as you return from ProtocolReceiveNbls() AND *** you should not call NdisReturnNBls()*** and a protocol never calls Ndis"M"xxx() funcs.

Probably this was you issue, you explicitly returned NBLs() that you did not own and/or broke the broke the input chain.

MUX has miniport and protocol edge, so it is calling respective funcs at respective places.

  1. So depending on you semantics, either you process all the NBLs INLINE (I.e. no need to make copies) in ProtoclReceiveNBLs() and return
  2. But if your receive processing is intensive, you make copies (because once you return from PRotocolReceive(), Ndis.sys owns them)

wireshark/netmon installs as a protocol or intermediate driver, and due to promiscuous mode etc., NDIS.sys decides to indicate those packets with status_resources to reduce overall latencies in receive path of all protocols

26

That is what a synchonous loopback from promiscuous mode or all local mode looks like.

Cheers

Dave Cattley

Sent from my Windows 10 phone

From: xxxxx@gmail.commailto:xxxxx
Sent: Saturday, November 5, 2016 4:43 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] BSOD when running Wireshark with Ndis IM driver installed

UPDATE:

I have resolved this issue.

The issue arose from the fact that in my ProtocolReceiveNbl callback, the NDIS_RECEIVE_FLAGS_RESOURCES was not being handled. For some reason, probably due to high CPU consumption, on starting Wireshark my ProtocolReceiveNbl function would get the returnFlags with NDIS_RECEIVE_FLAGS_RESOURCES set, and the code was not honoring the flag to make sure the NBL chain passed to my function is preserved. The other issue was that I was always calling NdisReturnNetBufferLists() from my ProtocolReceiveNbl function irrespective of the flags.

So it looks like Wireshark just happened to manifest this issue, the the real issue was that NDIS_RECEIVE_FLAGS_RESOURCES flag needs to be handled carefully in the ProtocolReceiveNbl callback.

Thanks guys for the help.

—
NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></mailto:xxxxx></mailto:xxxxx>