Operations 8 min read

Setting Up a Dual-Machine Debugging Environment with VirtualKD and Network Methods

This guide explains why dual-machine debugging is needed, outlines the two main scenarios (virtual machine and physical machine), and provides step‑by‑step instructions for configuring VirtualKD as well as network‑based kernel debugging on Windows systems, including common test cases and useful commands.

360 Quality & Efficiency
360 Quality & Efficiency
360 Quality & Efficiency
Setting Up a Dual-Machine Debugging Environment with VirtualKD and Network Methods

During testing, unexpected scenarios often require deeper analysis; memory dumps may be unavailable or insufficient, so dual-machine debugging is used to capture system state at any point, including early boot, which memory dumps cannot achieve.

Dual-machine debugging falls into two cases: (1) the target system runs inside a virtual machine, and (2) the target system runs on a separate physical machine.

VirtualKD method offers a higher transfer rate (up to 4.5 MB/s) compared to virtual COM ports (≈10 KB/s). It works by patching a process in the VM with the Kernel Debugger (KD) extension DLL and communicating via a pipe. Required environment includes VMware 16 Pro with a Windows 7 x64 guest, a Windows 10 x64 host, VirtualKD‑Redux (or VirtualKD 3.0 for older VMware), WinDbg 10.0.18362.1, and a local symbol directory (e.g., C:\Symbols ). Download links: VirtualKD3.0: https://sysprogs.com/legacy/virtualkd/download/ VirtualKD‑Redux: https://toscode.gitee.com/wangwanfeng520/VirtualKD-Redux

Setup steps: run vmmon64.exe on the host and set the debugger path; copy the appropriate target64 (or target32 ) folder into the VM and execute vminstall.exe , then reboot the VM; during reboot select the new boot entry and press F8 to disable forced signing; the host debugger should launch automatically, otherwise click the “Run Debugger” button; finally, in the VM’s WinDbg window type g to continue execution.

Network method is used when the target cannot be tested in a VM. Both host and target must run Windows 8 or later (commonly Windows 10 x64). After ensuring network connectivity (ping) and disabling the target’s firewall, configure the target with the following commands (run as administrator): bcdedit /set {default} DEBUG YES bcdedit /debug on bcdedit /dbgsettings net hostip:192.168.0.110 port:55555 key:your.own.safe.key Note that hostip refers to the debugger host’s IP and the port must be between 49152 and 65535. On the host, open WinDbg, choose “Kernel Debug”, enter the target’s IP, port, and key, and connect.

Common testing scenarios include locating system slow‑downs (using .dump /ma C:\testdump.dmp or forcing a crash), capturing kernel debug output via registry settings ( [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter] = 0x0000000f ), and checking loaded driver versions (using the lmdrv command to list drivers and their timestamps).

Summary : While many tests can be performed locally, issues like system hangs, crashes, or driver instability often require dual-machine debugging to obtain detailed logs. VirtualKD provides a fast, easy‑to‑use solution for VM‑based debugging, whereas network debugging enables kernel analysis across two physical machines, both essential for thorough Windows kernel testing.

debuggingKernelWindowsnetwork debuggingdual-machineVirtualKD
360 Quality & Efficiency
Written by

360 Quality & Efficiency

360 Quality & Efficiency focuses on seamlessly integrating quality and efficiency in R&D, sharing 360’s internal best practices with industry peers to foster collaboration among Chinese enterprises and drive greater efficiency value.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.