Why does trying to break into the NT 3.1 kernel reboot my 486DX4 machine?

I installed Windows NT 3.1 on a Compaq ProSignia 3080 system, because of several reasons: I know that this machine was running Windows NT 3.1 when it was in productive use. And I think this machine was one of the machines Microsoft explicitly targeted with Windows NT. For improved performance, I maxed out the RAM at 128MB and swapped the socketed Intel 486DX-33 by an AMD enhanced 486DX4-SV8B (write-back cache and SMM) in a voltage adapter socket. I postponed dealing with BIOS support for 486DX4 processors, and jumpered the processor to a 2x multiplier. Without chipset support for L1 write-back and with a 2x multiplier, the processor is supposed to be software compatible to the Intel 80486DX2-66, which is a supported option for that system.

While installing Windows NT 3.1 worked perfectly, I really like to tinker with my retro stuff. The Windows NT 3.1 CD comes with the full set of debugging symbols, I'm curious into investigating why NetDDE throws an error into the event log, and the system crashes with a specific EISA ethernet card (which might be due to faulty hardware), so I decided to dive into kernel debugging. Setting up kernel debugging is straight-forward, once you realize you should use the i386kd executable supplied with Windows NT 3.1 instead of kd/ntkd from the current Windows 10 develepmont kit.

As soon as I want to break in (using Ctrl-C in i386kd), the target machine reboots instead of providing a kd> prompt.

I already tested the following:

• Memory in that system is OK
• The system files are not corrupted
• There is no hardware watchdog active that reboots the machine when the kernel is interrupted for debugging
• The USB-to-serial adapter I use (which seems to be a counterfeit PL2301) in the host communicates properly. It's not mis-sending some debugger commands as "reboot system" command (the KD protocol provides one, though!)
• It's not related to some remote management or alerting options provided by the mainboard.