BugCheck when running HCK MPE_Ethernet test, on windows 8.1 x86/x64

Hi,

I have a Windows ndis miniport driver, for a 10BaseT NIC.
This driver passes WHQL (HCK test suits) on all Windows OSs (Windows 7 x32/x64, Windows 8.1 x32/x64, Windows Server 2008 R2, Windows Server 2012 R2, and Windows 10 x86/x64).

However, there is one test which is very problematic : the MPE_Ethernet test, on windows 8.1 (x86 / x64).

On Windows 7 (x86/x64/server 2008 R2), the test passes immediately, but in windows 8.1 it fails repeatedly. I have to run it several times (sometimes more than 10 times in a row), before I manage to get a successful pass.

I noticed, after days of tinkering, that the following configuration gives the best results (i.e.: the test is more likely to pass) : configuring both the device under test, and the support device, to have a link speed of forced 1G.

Even with this “workaround” the test needs to be run several times, before it passes, without a BSOD.

Running !analize -v on the crash dump, I get the following: (the context of the crash is not in my driver… )

3: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

BUGCODE_NDIS_DRIVER (7c)
This is the NDIS Driver Bugcheck for Windows Server 2003 and later.
For Windows 2000 and Windows XP, see 0xD2, BUGCODE_ID_DRIVER.
Arguments:
Arg1: 0000001f, NDIS BugCheck Code
Arg2: 8c4d40e8
Arg3: 00000001
Arg4: 00000000

Debugging Details:

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x7C

PROCESS_NAME: System

CURRENT_IRQL: 0

ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) x86fre

LAST_CONTROL_TRANSFER: from 864d7dfa to 8195d9b4

STACK_TEXT:
82c5a7d4 864d7dfa 0000007c 0000001f 8c4d40e8 nt!KeBugCheckEx
82c5a7f4 8654bf4b 00000000 8650d3d0 8c4d40e8 ndis!NdisMPauseComplete+0xfaa2
82c5a830 86521fa1 893fcfb8 8c4d4da0 00000000 ndis!ndisMPauseMiniportInner+0xff
82c5a840 86518655 8c4d4da0 8c4d4da0 00000000 ndis!ndisMPauseMiniport+0x28
82c5a9c0 865196e7 00000000 8c4d4da0 8c4d4da0 ndis!Ndis::BindEngine::Iterate+0x573
82c5a9dc 8651a363 8c4d4da0 82c5aa0c 86519937 ndis!Ndis::BindEngine::UpdateBindings+0x33
82c5a9e8 86519937 00000000 82c5a9fc 8c4d40e8 ndis!Ndis::BindEngine::DispatchPendingWork+0x43
82c5aa0c 864c9097 00000000 00000005 cf7daeb8 ndis!Ndis::BindEngine::ApplyBindChanges+0x40
82c5aabc 8651778b cf7daf70 00000000 cf7daf70 ndis!ndisPrepForLowPower+0x9d
82c5aadc 86521d66 00000004 8c4d40e8 cf7daeb8 ndis!ndisSetSystemPower+0xf2
82c5aaf4 864c82cc 8c4d40e8 cf7daeb8 8c4d4030 ndis!ndisSetPower+0x7b
82c5ab10 8600aadc 8c43c370 cf7daeb8 b2d32288 ndis!ndisPowerDispatch+0x7e
82c5ab38 81d2e639 8c4d4030 cf7daeb8 864c824e VerifierExt!xdv_IRP_MJ_POWER_wrapper+0xd0
82c5ab4c 81d2e958 8600aa0c 00000016 82c5ab74 nt!ViGenericDispatchHandler+0x2d
82c5ab5c 8194b75d 8c4d4030 cf7daeb8 cf7daeb8 nt!ViGenericPower+0x18
82c5ab74 81d17b3f cf7daf8c 8c4d4030 cf7daeb8 nt!IopPoHandleIrp+0x2f
82c5ab90 818a5527 8194f68a cf7dafb0 cf7daeb8 nt!IovCallDriver+0x2be
82c5aba4 8194f68a 82c5abc8 81d2ef60 8c4d4030 nt!IofCallDriver+0x5b
82c5abac 81d2ef60 8c4d4030 cf7daeb8 cf7daeb8 nt!IoCallDriver+0x10
82c5abc8 8194bc0b 8c4d5d70 cf7daeb8 00000000 nt!ViFilterDispatchPower+0x7c
82c5ac30 818ef66e af0a62d0 2c1e29bf 00000000 nt!PopIrpWorker+0x2bb
82c5ac70 81973401 8194b950 af0a62d0 00000000 nt!PspSystemThreadStartup+0x58
82c5ac7c 00000000 00000000 d9d9d9d9 d9d9d9d9 nt!KiThreadStartup+0x15

STACK_COMMAND: kb

FOLLOWUP_IP:
ndis!NdisMPauseComplete+faa2
864d7dfa 57 push edi

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: ndis!NdisMPauseComplete+faa2

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: ndis

IMAGE_NAME: ndis.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 55a0054c

BUCKET_ID_FUNC_OFFSET: faa2

FAILURE_BUCKET_ID: 0x7C_VRF_ndis!NdisMPauseComplete

BUCKET_ID: 0x7C_VRF_ndis!NdisMPauseComplete

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0x7c_vrf_ndis!ndismpausecomplete

FAILURE_ID_HASH: {bb09945a-48cd-ec14-5cb8-e89bd48f8523}

Followup: MachineOwner

I basically reached a dead end, trying to evaluate the cause for the crash.
Anyone has any ideas? anything that can lead me in the right direction, to find the root cause of the issue…

Thanks!!

Albert.

Anyone ?

Also, the ndprot630.pdb symbols file, which is distributed with the HCK 8.1, is not the correct
symbols file (does not match the ndprot630.sys). Do you know how to obtain the correct ndprot630.pdb?

Thanks.