Freigeben über

Hyper-V generation 2 virtual machines – part 5

  • Artikel

Part 1: Introduction to generation 2 virtual machines
Part 2: Networking and boot order
Part 3: Storage
Part 4: Keyboard for Windows 8 & Windows Server 2012
Part 5: Kernel debugging
Part 6: Secure Boot
Part 7: FAQ
Part 8: Manually migrating generation 1 virtual machines to generation 2
Part 9: Installing from ISO
Part 10: Utility for converting generation 1 virtual machines to generation 2 (Convert-VMGeneration)

This part of the series on generation 2 virtual machines in Hyper-V looks at kernel debugging using the serial port. It's spookily simple (it's Halloween!). If you don’t have any need for kernel debugging, skip to the next part.

In generation 1 virtual machines, one of the most common ways of attaching a kernel debugger to a guest operating system is using a COM port. However, in generation 2 virtual machines, there are no COM ports. Or are there….?

Well the answer is both yes, and no. By default, the answer is no. However, you can change this. For the following screenshots, I’m using a Windows 8 virtual machine (in fact using the media I created in the previous part which has the software based keyboard driver added). For example, here’s the settings for a typical generation 2 virtual machine where there is no COM port shown.

clip_image002

That is simply because Hyper-V Manager will never show COM ports regardless of whether they are present or not in a generation 2 VM. Let’s look at PowerShell instead:

clip_image004

Here you can see PowerShell believes there are two COM ports. However, if you look inside device manager in a guest operating system, you’ll notice that there really are no COM ports present as devices enumerated to the virtual machine. (I won’t include a screenshot, I did that in a previous part.)

While a VM is running, you can set a pipe path for a COM port, so let’s do that for COM1:

clip_image006

Again, if you were to look inside device manager in the guest, the COM1 port is still not present. However, if you shutdown and re-start the VM, you’ll notice that the COM ports are indeed now present.

clip_image008

The rest of this isn’t rocket science for those of you familiar with kernel debugging, except for one small thing which is relevant to generation 2 virtual machine (or more specifically UEFI based machines with Secure Boot enabled).

Using msconfig, here I’m enabling kernel debugging for the VM on COM1, but after hitting OK, you get the following error:

clip_image010

This is because policy in Windows dictates that Secure Boot and kernel debugging are incompatible. Hence, shut-down the virtual machine and disable Secure Boot in the firmware settings. (I’ll talk more about Secure Boot in the next part.)

clip_image012

Use msconfig again to enable kernel debugging which will succeed, then restart the VM. Using windbg on the parent partition, connect to the pipe

clip_image014

At which point you can break in as per normal kernel debugging

clip_image016

Onwards to part 6 and Secure Boot.

Cheers
John.

Comments

  • Anonymous
    January 01, 2003
    I see further that I have to run the Windows debugger (windbg.exe) elevated to make contact with the debuggee.Another question: Is it possible to use NET as the transport, as one would define it in the debuggee? When I have done so, I never make contact from a kernel debugger. Other kernel debugger sessions using NET to real debuggees (versus a VM debuggee) work fine.
  • Anonymous
    January 01, 2003
    The comment has been removed
  • Anonymous
    January 01, 2003
    windbg does not support NET debugging of Hyper-V VMs using KDNet in Windows 8.1. Using the serial alternate is supported and should work.
  • Anonymous
    January 01, 2003
    Yes, that is expected. Apologies, I should have been clearer when writing the post originally.
  • Anonymous
    January 01, 2003
    Alex - had to do some digging to get you an answer. Officially "synthetic" debugging is not a supported end customer feature that we've explicitly documented (although I'm aware Jake did mention that in that thread). "Supported" in the sense that if there were a problem, Microsoft Support Services would investigate. Certainly due to the deprecation of the rootvirtualization namespace in favour of the rootvirtualizationv2 namespace in Windows 8.1/Server 2012 R2 means that script will no longer operate without some porting effort. I don't know the answer to whether the functionality has been removed as such though as it was never officially supported in the first place. Hope that helps.
    John.
  • Anonymous
    January 04, 2014
    The comment has been removed
  • Anonymous
    January 04, 2014
    The comment has been removed
  • Anonymous
    January 04, 2014
    The comment has been removed
  • Anonymous
    January 04, 2014
    The comment has been removed
  • Anonymous
    January 04, 2014
    The comment has been removed
  • Anonymous
    March 03, 2014
    John, is Synthetic Debugging still supported, vs. using an (extremely slow) Com Port? This post from Jake Oshins and Ken Johnson: http://www.osronline.com/showthread.cfm?link=234398 works perfectly on Hyper-V 2.0 on a Windows Server 2012 machine, but fails on R2 (Windows 8.1). Has this functionality been removed?

    It's also pretty surprising that KDNet was broken in Win 8.1. It was perfectly working in Win8 because of the emulated network card. Expecting people to get large crash dumps over serial ports in VMs is pretty bad :(

    --
    Best regards,
    Alex Ionescu
  • Anonymous
    May 09, 2014
    Hi John,

    Thanks for your answer. I've been able to port the script and confirm that the feature still works in the latest Hyper-V on Windows 8.1. I understand it's still unsupported (and it's a bit flaky when setting up a connection) but it's good to get those dumps at 100x the speed.

    Too bad kdnet is not supported. It works in every other single VM product out there!
  • Anonymous
    October 21, 2014
    I'm attempting to follow these instructions on a 2012 server, but powershell is reporting that "Get-VMComPort" is not recognized.