IRQL_UNEXPECTED_VALUE after NdisFIndicateReceiveNetBufferLists?

Hi,

We have an NDIS LWF driver, and only combined with a particular VPN and its NDIS driver, we get IRQL_UNEXPECTED_VALUE BSOD on the NdisFIndicateReceiveNetBufferLists, But we do not raise or lower IRQL in any part of the code, and the NdisFIndicateReceiveNetBufferLists is called in the irp_mj_device_control callback. We also check the IRQL and if its DISPATCH, we set the last argument to NDIS_RECEIVE_FLAGS_DISPATCH_LEVEL, and 0 otherwise, could this be the issue?

I also found this article:

https://knowledge.broadcom.com/external/article/164146/crash-with-bug-check-0xc8-after-installi.html

They had a similar issue, and the issue seems to be that there was another NDIS driver raising the IRQL to DISPATCH_LEVEL and forgeting to lower it? But I’m still not sure if this is applicable to our issue or not? Could this be also our issue? That the NDIS driver for the VPN is raising the IRQL without lowering it? And How can we resolve this BSOD?

IRQL_UNEXPECTED_VALUE (c8)
The processor's IRQL is not what it should be at this time.  This is
usually caused by a lower level routine changing IRQL for some period
and not restoring IRQL at the end of that period (eg acquires spinlock
but doesn't release it).
Arguments:
Arg1: 0000000000020002, (Current IRQL << 16) | (Expected IRQL << 8) | UniqueValue
Arg2: fffff82621a444f0, Depends on UniqueValue:
	If UniqueValue is 0 or 1: APC->KernelRoutine.
	If UniqueValue is 2: the callout routine
	If UniqueValue is 3: the interrupt's ServiceRoutine
	If UniqueValue is 0xfe: 1 iff APCs are disabled
Arg3: ffff950cf4dccff0, Depends on UniqueValue:
	If UniqueValue is 0 or 1: APC
	If UniqueValue is 2: the callout's parameter
	If UniqueValue is 3: KINTERRUPT
Arg4: 0000000000000000, Depends on UniqueValue:
	If UniqueValue is 0 or 1: APC->NormalRoutine

Call stack:

nt!KeBugCheckEx
nt!KeExpandKernelStackAndCalloutInternal
nt!KeExpandKernelStackAndCalloutEx
ndis!ndisInvokeNextReceiveHandler
ndis!ndisFilterIndicateReceiveNetBufferLists
ndis!NdisFIndicateReceiveNetBufferLists
OurNdis

And the second parameter which is the callout routine (based on unique value), is ndis!ndisDataPathExpandStackCallback.

I did a little more digging, and indeed it seems like ndisDataPathExpandStackCallback actually just calls ndisCallReceiveHandler (which doesn’t appear on the stack). and I assume this just indicates the recved NBL to other NDIS drivers? Anyways, ndisDataPathExpandStackCallback is called via KeExpandKernelStackAndCalloutInternal, and the latter stores the IRQL, and checks the IRQL after the call, and if it mismatches, it raises this bugcheck, bingo!

BUT, now my question is, how can i find the faulty driver? Can i somehow use the ndiskd extension to help me which NDIS driver did the KeExpandKernelStackAndCalloutInternal call so i can prove and find the faulty driver?

Although by investigating the stack, i did find pacer!PcFilterReceiveNetBufferLists, but i doubt this is the faulty driver considering its a windows driver, right?