{"componentChunkName":"component---src-templates-post-template-js","path":"/windows-windbg-proxmox-remotekd-en","result":{"data":{"markdownRemark":{"id":"b3130164-37d6-50a0-becb-bf7c2abaf126","html":"
\n

This page has been machine-translated from the original page.

\n
\n

This article summarizes how I resolved a problem where remote kernel debugging with WinDbg did not work between Windows 11 VMs on Proxmox.

\n

I eventually got remote kernel debugging between Proxmox VMs working by applying the following settings.

\n
    \n
  1. Instead of using kdnet.exe, explicitly set the busparams=b.d.f value for the NIC that KDNET should use with bcdedit
    2. \n
\n
bcdedit /debug on\nbcdedit /dbgsettings net hostip:192.168.10.20 port:50000 key:<Key> nodhcp\nbcdedit /set \"{dbgsettings}\" busparams <busparams you checked>\n\n# Verify the settings\nbcdedit /dbgsettings
\n
    \n
  1. Start the target machine with qm start <VMID> --force-cpu host so it boots without using the Hyper-V Enlightenments settings that Proxmox enables by default
    2. \n
\n\n

Table of Contents

\n\n

Environment

\n

The environment in this case was as follows.

\n\n

\n \n \n \n \n \n \n \n \n

\n

The Problem I Ran Into and What Seems to Have Caused It

\n

I followed the same steps as Perform Kernel Debugging over the Network to configure network debugging with kdnet.exe, and I also had WinDbg listen on the host side, but after rebooting the target it still did not connect.

\n
windbg.exe -k net:port=50000,key=<Key>
\n

On the target side, running kdnet.exe did display Network debugging is supported, but it also displayed an error with error code 0xC0000182 like the following.

\n
KDNET transport initialization failed during a previous boot. Status = 0xC0000182.\nNIC hardware initialization failed.\nKDNET did not successfully receive any packets during init.\nKDNET did not successfully send any packets during init.
\n

Apparently, the target was not generating any debugging traffic at all. While investigating, I found the following article.

\n

Reference: libvirt的Hyper-V虚拟化或导致Windows KDNET初始化失败 - Silver

\n

According to that article, QEMU as used by Proxmox has a feature for Windows guests called Hyper-V Enlightenments that makes the guest recognize itself as running on Hyper-V, and this apparently can affect how KDNET behaves on virtual machines that are not actually using Hyper-V.

\n

Reference: Hyper-V Enlightenments — QEMU documentation

\n

(I have not been able to investigate this in detail, but it seems KDNET behaves differently on machines running on Hyper-V, and when a virtual machine that is not actually using Hyper-V ends up in this state, network debugging may stop working properly.)

\n

Notes: What I Checked on Proxmox

\n

First, I ran the following command to inspect the options used when Proxmox starts the VM.

\n
qm showcmd <VMID> --pretty
\n

As a result, I found that the CPU flags included several options starting with hv_, as shown below.

\n

\n \n