Hyper-V generation 2 virtual machines – part 5

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.


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:


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:


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.


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:


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.)


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


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


Onwards to part 6 and Secure Boot.