In this configuration, KDNet will not successfully load and the kernel debugger in the guest will not be able to make a connection with WinDbg running on a remote system. The problem occurs when you enable the kernel debugger in the guest, and specify KDNet as the transport, and enlightenments are enabled and the hypervisor ID is set to “Microsoft Hv”. The enlightenments that are enabled by default include setting the hypervisor ID to the same ID that’s reported by Microsoft Hyper-V (which is “Microsoft Hv”).
#Windows 10 kernel debug network windows
The enlightenments that are enabled results in a Windows guest that runs much faster (and, reportedly, more reliably) than a Windows guest that is fully virtualized. We know this is the default configuration for Windows VMs created using virt-manager and Cockpit on RHEL 8, and we suspect it is the default for any VMs created through libvirt. When you create a VM on Centos/RHEL, and you specify the OS type as being “Windows”, a standard set of Windows enlightenments will be enabled, resulting in a para-virtualized installation. If you want to enable the Windows kernel debugger using network transport (KDNet) in a guest is hosted on Linux under QEMU-KVM, you need to use specific VM settings.Įither the guest must be fully virtualized (that is, no hypervisor enlightenments enabled), or the hypervisor vendor ID must be set to something other than the default, which is the Windows hypervisor ID (“Microsoft Hv”). Thus began something like two weeks of pain, suffering, and debugging, that lead us to discussions with the Windows debugger people, the Hyper-V people, and the Redhat QEMU developers (Aside: Anybody wanna bet who the most supportive/responsive team was? Anybody?)Īnyhow, we suffered so you don’t have to. And, yes, everything was swell… until we tried to hook up the kernel debugger via a network connection to that Windows VM. Installing RHEL on a spare server machine and on that a Windows VM using virt-manager is a piece of cake.
#Windows 10 kernel debug network driver
I’ll spare you all the gory details about why we had to actually dev and test the driver on a Windows system running in a VM hosted by Linux, but suffice it to say there was absolutely no alternative.Īnd, really, in the beginning, we didn’t much mind. We spent several months working on a very intensive (and very interesting) project that required a writing a driver that was specifically intended to run on a Windows system running under QEMU-KVM hosted on a Linux system (specifically, RHEL 8).