Hi everyone.
2 months ago, I posted a question in the following thread:
“BugCheck when running HCK MPE_Ethernet test, on windows 8.1 x86/x64”
Since then I found the cause of the BSOD, and I want to share it with you.
I am starting a new thread, because I cannot post an answer on the original one (Why ??).
For details about the problem / environment, etc. please visit the original thread.
Briefly, the problem was the following:
When NDIS pauses a miniport driver, (for example, when going to D3), the registered
Pause handler is called.
The pause handler must return either:
- STATUS_SUCCESS ==> in which case, NDIS immediately calls NdisMPauseComplete.
- STATUS_PENDING ==> in which case, the driver should call NdisMPauseComplete by itself, whenever it is ready (Rx/Tx queues are drained, etc.).
In our mini port driver, every DPC handler (e.g. Rx or Tx), checked a flag that indicated whether a pause is pending.
If a pause was pending, and Tx and Rx queues were empty, the DPC handler called NdisMPauseComplete.
The bug scenario was the following:
The Pause handler function was entered, and initially set the flag as “pause pending”.
A DPC handler for Tx executed on another CPU core (another context).
Since pause was pending, and Tx and Rx queues were empty, it called NdisMPauseComplete, as expected.
The pause handler resumed. It detected that Rx and Tx queues were empty, so it returned STATUS_SUCCESS (safe to pause) to NDIS.
As a result, NDIS called NdisMPauseComplete (again), and we got a BSOD.
The fix was simple - update the flag only after returning from the pause handler. Now MPE_Ethernet test completes successfully.
This was a very frustrating search, but it paid off.
The bug was found by extensive logging (in almost every line of code, in the pause path).
I hope it will help someone, in the future.
Regards,
Albert.