WinDbg over Ethernet(KDNET) in low power states

Hi,
this question may overlap into hardware and firmware, but please read on.

I have a custom X64 platform with supported Ethernet controller to debug this platform over Erthernet from host PC. Setting up dbgsettings works as expected, and I can happily run WinDbg on host PC to debug that target platform… only after it booted up and stays that way.
If I allow target platform to enter a low power state, then WinDbg hangs. When target platform returns to S0 WinDbg on PC is still hung.
OK maybe it is not the supported way, so I reboot target platform - WinDbg connects right away. Then I exist WinDbg and let target platform go through sleep-wake cycle. Then try connect WinDbg - nope, no matter what tried, does not connect after wake from sleep.

So my question distills to a simple one: should kernel debugging over Ethernet survive sleep-wake cycles on target platform? Is it a supported scenario? Or it depends on what was implemented or not in UEFI for such operation?

Thanks,
Sergey

Kernel debugging over {NET, COM, 1394, USB3} definitely can survive an Sx transition. I’ve personally done seen those work. (I’m still waiting to see USB2 ever work.) Unfortunately I’m not enough of an expert in this area to speculate why it might be broken on your platform. Let me see if I can loop in such an expert.

Hi Jeffrey,
thank you for your reply. Yes, I have successfully used myself WinDbg to debug sleep-wake issues on Windows 10 platforms over serial (IoT Core that was). I have seen some platforms also successfully survive sleep-wake cycle in WinDbg session.
The fact that it can survive is not equal to must survive. Can survive means just nice to have, or optional.
I am wondering what is official word from MSFT: is it must or not?

Thank you for inviting an expert to assist.

Cheers,
Sergey

OK, Don Marshall from MSFT replied to my request in https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-a-network-debugging-connection documentation page.
Reading it makes an impression that there is no such requirement for a platform running Windows 10. That is, given the platform you have, like it or not, but it will only do what vendor decided to implement.