0

We are working on a modifying filter for NDIS6 that uses wrapping of original packets into its own layer protocol.

Before adding our own header, we call NdisRetreatNetBufferDataStart(pNetBuffer, sizeof(OurHeader), 0, NULL), assuming that NDIS will allocate additional MDL on its own, via its 'default' function, as described in http://msdn.microsoft.com/en-us/library/windows/hardware/ff570697%28v=vs.85%29.aspx ("If the entry point is NULL, NDIS uses a default method to allocate MDLs.")

We take care to NdisAdvanceNetBufferDataStart(pNetBuffer, sizeof(OurHeader), TRUE, NULL) in FilterSendNetBufferListsComplete.

However, we get a BSOD DRIVER_IRQL_NOT_LESS_OR_EQUAL, which means that some paged memory was accessed (a read operation, judging by the 3rd parameter of the bugcheck) from within an IRQ handler.

We suspect that our RetratXxx call led to allocating paged memory, and the miniport trapped when trying to send that data? If so, which is that "default" memory allocation behavior, and how should we call NdisRetreatNetBufferDataStart for such a case?

Vitalie
  • 3
  • 3
  • The NDIS datapath typically runs at `DISPATCH_LEVEL`, so all NDIS datapath-related APIs operate on nonpaged buffers already. For example, Retreat/Advance allocate nonpaged memory. It's more likely that the bugcheck is due to a bad pointer, either use-after-free or NULL pointer dereference. – Jeffrey Tippet Dec 14 '14 at 00:14
  • Thanks, Jeffrey. Indeed, it turned out that we tried to retrieve more data from a received packet that was there (at receive path, when inspecting what to drop and what to keep). – Vitalie Dec 14 '14 at 09:46
  • 2
    Cool, glad you found the issue. I'm sorry about the debugger's help text for `DRIVER_IRQL_NOT_LESS_OR_EQUAL`; it's terribly misleading. – Jeffrey Tippet Dec 14 '14 at 19:16

0 Answers0