crash during wake only when kernel debugger enabled

Hello,
I am investigating the issue on one of newly manufactured platforms. I tend to think that it is hw issue, because only happens on one specific system, other seemingly identical systems work under the same test.
Before I signoff engineering investigation report, would like to check with you experts, just in case.

Custom made Core-i5 based system. Windows 10 RS5 IoT Enterprise operating system with some customization (i.e. lacks some rarely used parts of Windows 10).
Secure boot disabled, Kernel debugger enabled in bcdedit settings and configured to use on-board Ethernet (I210 I think it is).
Ethernet cable is connected but host computer (where windbg could be run) is not connected to the switch.

test case
Cold boot system and wait to get to desktop.
using Windows start button, navigate to Power then Sleep
Verify that system successfully entered low power state S3
Wait for some time(variable but order of at least minutes) and verify that system is still in S3
Press USB keyboard key and expect system to wake up to S0

In reality this particular system crashes on wake, while other identical ones don’t.
Crash dump is captured, and shows something looks a bit odd. Maybe someone can give their thought, but again I suspect defective hw.

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000000000003300, memory referenced
Arg2: 00000000000000ff, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff80776637642, address which referenced memory

STACK_TEXT:
fffff187a6d0a1e8 fffff807771d9be9 : 000000000000000a 0000000000003300 00000000000000ff 0000000000000000 : nt!KeBugCheckEx
fffff187a6d0a1f0 fffff807771d5fd4 : ffffe6d10a1ddb3e 000000000000000f fffff8077666eae4 fffff80777a802e2 : nt!KiBugCheckDispatch+0x69
fffff187a6d0a330 fffff80776637642 : 0000041f00000001 fffff807766367a6 fffff8077666c2e8 fffff8077663803c : nt!KiPageFault+0x454
fffff187a6d0a4c0 fffff807766360b3 : 00000000fffffff7 0000000000000000 0000000000000000 000000004efc62f7 : kd_02_8086!e1000_UNDI_APIEntry+0x32
fffff187a6d0a4f0 fffff80776635f0b : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : kd_02_8086!UndiShutdownController+0x3f
fffff187a6d0a550 fffff8077663536c : 0000000000000000 fffff80776ef7000 000000000000fff9 00000000c000000e : kd_02_8086!UndiInitializeController+0x573
fffff187a6d0a6e0 fffff807766350b9 : fffff80776ef7000 0000000000989680 00000000c00000c2 fffff807766972a0 : kd_02_8086!IntelInitializeController+0xf0
fffff187a6d0a710 fffff80776683fa6 : 0000000000000000 0000000000000000 ffff2436e4ef7eb3 ffff2436e4ef7f13 : kd_02_8086!KdInitializeController+0x9
fffff187a6d0a740 fffff8077667d3f1 : 0000000000000000 00000000c00000c2 0000000000087000 fffff807766972a0 : kdcom!InitializeController+0xf6
fffff187a6d0a770 fffff8077667d642 : 0000000000000000 0000000000000000 00000000c00000c2 fffff187a6d0a9cc : kdcom!KdNetInitialize+0x209
fffff187a6d0a7d0 fffff8077729857e : 0000000000000001 000000000000000f fffff807757ef180 000000000000000f : kdcom!KdPower+0x102
fffff187a6d0a800 fffff8077729845b : 0000000000000000 fffff807757ef180 fffff187a6d0a990 0000000000000000 : nt!KdPowerTransitionEx+0x10e
fffff187a6d0a840 fffff80777581ad4 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KdPowerTransition+0xb
fffff187a6d0a870 fffff8077757632a : fffff187a6d0a990 fffff187a6d0a9f0 fffff187a6d0a990 0000000000000000 : nt!PopHandleNextState+0xb704
fffff187a6d0a8c0 fffff80777576020 : 0000000000000100 0000000000000000 ffff9e8000000000 0000000000000000 : nt!PopIssueNextState+0x1a
fffff187a6d0a8f0 fffff8077758342a : fffff187a4392750 fffff18700000000 ffffc8014ec11040 ffffc8014cfac100 : nt!PopInvokeSystemStateHandler+0x29c
fffff187a6d0ab00 fffff807770ec645 : ffffc8014ec11000 ffffc8014ec11040 fffff80777579090 0000000000000001 : nt!PopTransitionToSleep+0xa39a
fffff187a6d0ab90 fffff807771cf82c : fffff807757ef180 ffffc8014ec11040 fffff807770ec5f0 0000000000000246 : nt!PspSystemThreadStartup+0x55
fffff187a6d0abe0 0000000000000000 : fffff187a6d0b000 fffff187a6d04000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x1c

Thanks for looking

Looks to me like the kernel debugger is failing during its attempt at initializing the hardware, and dies during exit. But it’s hard to know.

COULD it be bad hardware? I guess. It could be some funky state in the KDNET code, too.

Peter