Windows kernel debugging unavailable - all documented method don't work

Hi.

I just purchased a Parallels Pro license. I started with the trial and everything looks so good that I didn't event wait for the trial to end before buying a license. Generally I am very quite pleased, but I have one serious problem. I can't get Windows kernel debugging to work properly, no matter what I try.

There are two main documented ways this is supposed to work:

1. Kernel debugging over Ethernet. This is the preferred way which works with physical machines as well as with many virtual machines (Hyper-V, VMware Workstation, VMware ESX, etc.) - https://docs.parallels.com/parallel...sks/device-management/virtual-network-adapter
2. Using Parallels' built-int support for the "KDBG protocol" - https://docs.parallels.com/parallel...bugging-a-virtual-machine-using-kdbg-protocol

At the moment both of them don't work for me. The environment I'm using is:

• Host: macOS 26.1 on M3 16-inch MacBook Pro, Parallels Pro 26.1.2 (57293)
• Guest: Windows 11 Enterprise (ARM64, of course), 25H2 26200.7171

I'd appreciate any assistance on what to do, in case I'm doing something obviously wrong, before opening a support request.
Below are the details of what exactly I did and how it didn't work.

Thank you.

Kernel Debugging over Ethernet

This method depends on the Windows machine (physical or virtual) a NIC drawn from a list of NICs for which Windows has special drivers that allows them to be used as kernel debugging transport. The list for Windows 11 can be found here: https://learn.microsoft.com/en-us/w...cs-for-network-kernel-debugging-in-windows-11

Note that the 1AF4 vendor ID (used by the VirtIO devices) is not included, but Intel E1000 is supported (and indeed works), and E1000 is also supposed to be supported by Parallels, according to the documentation and the output of prlctl. See https://docs.parallels.com/parallel...sks/device-management/virtual-network-adapter

Unfortunately in practice this doesn't work. The prlctl commands seem to work:

Code:

~> prlctl list -i 'Windows 11 - Target'
INFO
ID: {9dbfa855-28d9-4bfb-8925-1b962460dbd7}
Name: Windows 11 - Target
Description:
Type: VM
State: stopped
OS: win-11
<...>
Hardware:
  cpu cpus=4 auto=on VT-x accl=high mode=64 type=arm
  <...>
  net0 (+) type=shared mac=001C424D4DC2 card=virtio
  <...>

~> prlctl set 'Windows 11 - Target' --device-add net --type host-only --adapter-type e1000
Creating net1 (+) type=host mac=001C4272F18A card=e1000

Created net1 (+) type=host mac=001C4272F18A card=e1000


The VM has been successfully configured.

~> prlctl list -i 'Windows 11 - Target'
INFO
ID: {9dbfa855-28d9-4bfb-8925-1b962460dbd7}
Name: Windows 11 - Target
Description:
Type: VM
State: stopped
OS: win-11
<...>
Hardware:
  cpu cpus=4 auto=on VT-x accl=high mode=64 type=arm
  <...>
  net0 (+) type=shared mac=001C424D4DC2 card=virtio
  net1 (+) type=host mac=001C4272F18A card=e1000
  <...>

~>

Once I start the VM I see two VirtIO NICs:





As expected, since we didn't really get an Intel E1000, nothing works:




Just for completeness I tried e1000e and rtl mentioned in the documentation. In both cases the prlctl reports success but when I power on the machine I see just more and more VirtIO devices.

"KDBG protocol" support

Looking for solutions for that problem I came across this page: https://docs.parallels.com/parallel...bugging-a-virtual-machine-using-kdbg-protocol

It asserts that similar to how Parallels and others (VMware, QEMU, etc.) have a builtin gdbserver for debugging "the actual machine", Parallels also contains a "kd server" wherein Parallels itself implements the KD protocol, and allows debugging Windows guests (presumably without even disabling UEFI Secure Boot, since the debugger runs at the hypervisor level and Windows isn't aware of it). The documentation mentions a lot of serious limitations (no breakpoints...), but I couldn't get even that to work.

After some fidgeting around I managed to get it "work". Building upon the example provided I used:

Code:

<SystemFlags>
vm.efi.monitor=1;
vm.efi.kernel_address=1;
vm.efi.kernel_modules=1;
vm.debug=1;
vm.debug.protocol=1;
vm.debug.local_addr=10.37.129.2;
vm.debug.windbg_stub.guest.port=50000;
vm.debug.key=1.1.1.1;
vm.debug.host_addr=10.37.12.13;
</SystemFlags>

Unfortunately the results weren't very good:

Code:

Microsoft (R) Windows Debugger Version 10.0.29457.1000 ARM64
Copyright (c) Microsoft Corporation. All rights reserved.

Using NET for debugging
Opened WinSock 2.0
Waiting to reconnect...
KDNET received an out of sequence ping packet.
The target machine restarted without notifying the debugger.
No ping packet received, reseting data channel.
Connected to target 10.37.129.2 on port 50000 on local IP 10.37.129.13.
You can get the target MAC address by running .kdtargetmac command.
Connected to Windows Boot Debugger 3500 ARM 64-bit (AArch64) target at (Sun Dec  7 00:40:52.617 2025 (UTC + 2:00)), ptr64 TRUE
Kernel Debugger connection established.

************* Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       srv*
Symbol search path is: srv*
Executable search path is: 
Module List address is NULL - debugger not initialized properly.
WARNING: .reload failed, module list may be incomplete
KdDebuggerData.KernBase < SystemRangeStart
Windows Boot Debugger Kernel Version 3500 UP Free ARM 64-bit (AArch64)
Primary image base = 0x00000000`00000000 Loaded module list = 0x00000000`00000000
System Uptime: not available
Single step exception - code 80000004 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
Module List address is NULL - debugger not initialized properly.
fffff802`42503e40 b9007d28 str         w8,[x9,#0x7C]
Module List address is NULL - debugger not initialized properly.
0: kd> r
 x0=ffffb00121755a50   x1=0000000000000000   x2=5600000f60000040   x3=000000005600000f
 x4=000000e2fb57f7e0   x5=ffffb00121755a50   x6=0000000000000000   x7=0000000000000000
 x8=00000006d8658280   x9=fffff80242e16380  x10=00000000000e2484  x11=fffff8023afc0000
x12=0000000000000000  x13=0000000000000000  x14=0000000000000000  x15=00007ff8d4bd3310
x16=00007ff8e54110f0  x17=000035cd40883b1a  x18=fffff8023afc0000  x19=0000000000000274
x20=00007ff8e16a3000  x21=0000000000000000  x22=0000000000000000  x23=000002b76113a710
x24=0000000000000016  x25=00007ff6814d7840  x26=0000000000000000  x27=0000000000000000
x28=0000000000000000   fp=ffffb00121755b90   lr=fffff8024262aed8   sp=ffffb00121755a50
 pc=fffff80242503e40  psr=600003c4 -ZC- EL1
fffff802`42503e40 b9007d28 str         w8,[x9,#0x7C]
Module List address is NULL - debugger not initialized properly.
0: kd> lm
start             end                 module name
Module List address is NULL - debugger not initialized properly.
0: kd> k
Module List address is NULL - debugger not initialized properly.
 # Child-SP          RetAddr               Call Site
00 ffffb001`21755a50 fffff802`4262aed8     0xfffff802`42503e40
Module List address is NULL - debugger not initialized properly.
Module List address is NULL - debugger not initialized properly.
01 ffffb001`21755a50 00000000`00000000     0xfffff802`4262aed8
Module List address is NULL - debugger not initialized properly.
Module List address is NULL - debugger not initialized properly.
0: kd> ~
       ^ Syntax error in '~'
0: kd> ~*
       ^ Syntax error in '~*'
Module List address is NULL - debugger not initialized properly.
0: kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
Could not get address of nt!KdVersionBlock.
Could not get address of nt!KdVersionBlock.
unable to get nt!MmUserProbeAddress
NT symbols are incorrect, please fix symbols
Module List address is NULL - debugger not initialized properly.

I have no idea what's going on here. If I had to guess I'd say it should be related to the three options mentioned in the documentations, and enabled by me as required:

Code:

vm.efi.monitor=1;
vm.efi.kernel_address=1;
vm.efi.kernel_modules=1;

So what else is there to do?

Anyway, I'd prefer for the E1000 to just work.

 

I see that the problem falsely acknowledging creating an e1000 NIC while actually creating a VirtIO NIC exists for at least 2 years.

However older content (circa 2019, even in these forums) suggests it once worked. Perhaps this is regression on related to ARM?

 

Now that I've verified that indeed this is a regression with the ARM versions I am able to find it "documented".
Of course it's only documented in the GUI "User's Guide" or some obscure KB article, but the Developer's Guide makes no mention of it, and the command itself claims it to be possible, and the command actually "succeeds" when run, leaving you to wonder what happened.

This is quite unserious. I think both the documentation and the command itself should be promptly fixed to reflect reality.

As for the original matter, since E1000 is in fact unavailable and the "KDBG" thing doesn't work I've resorted to doing everything except kernel debugging on Parallels, and have VMware Fusion VM as a debug target (since they support E1000 on ARM and have supported it for as long as remember).
Since Fusion is free it's kind of not that bad, as I don't have to pay for two solutions, but it's still annoying. That I even need to have another virtualization software installed in addition to Parallels seems superfluous. It's many more GBs for something I almost don't need. Parallels has managed to outperform Fusion in many aspects and I see no reason why they couldn't be at least as good as in this regard.