Troubleshooting Hyper-V Debugging
This section discusses some problems that can arise during Hyper-V debugging.
Cabling and Configuration Problems
If there is no connection string when the root partition starts up, this is usually caused by a cabling or configutation issue. For example, output such as the following might be displayed:
Waiting to reconnect... Connected to Windows 6001 x64 target, ptr64 TRUE Kernel Debugger connection established. Symbol search path is: c:\mysymbols\ Executable search path is: Loading symbols for fffff800`01602000 ntkrnlmp.exe -> ntkrnlmp.exe ModLoad: fffff800`01602000 fffff800`01b17000 ntkrnlmp.exe Windows Kernel Version 6001 MP (1 procs) Free x64
To address this problem, check the configuration of the root partition by typing bcdedit at a command prompt, and verify that the values are correct.
If you restart vmdemux (virtual machine demultiplexer) after you have begun debugging Windows hypervisor, you must add -channel 0 to its command-line options in order to have the hypervisor channel re-created. This is typically done automatically by Windows hypervisor, but in this case it is not possible, because Windows hypervisor is already being debugged.
For a full list of the VMDemux command-line options, type vmdemux -? at the command prompt.
Problems with Unmodified Partitions
If you have already set up Hyper-V debugging across a null-modem cable, and have copied the Kdhvcom.dll file to the root partition, and then you later restart the target computer in another partition that does not have this file installed, the debugger may freeze. In this case, restart vmdemux. This problem arises because unmodified partitions cannot handle multiplexed traffic. Typically, vmdemux closes down all the pipes on a clean shutdown. However, a non-clean shutdown, such as doing a hard restart, is not detectable.