In case you need to debug the kernel on a VM running on Hyper-V, this is how you can do it with a Windows Server 2012 R2 VM Generation 2:
- After the VM has been created, a COM port is needed. By default, you cannot create a COM port with the Hyper-V Manager UI. That’s one of the differences between Gen1 and Gen2. You have to use Powershell to get your COM port. First of all shut down the VM and disable SecureBoot (replace YourVMName with the name of your VM and make sure you run all commands with “run as administrator”):
Set-VMFirmware -VMName YourVMName -EnableSecureBoot Off
- Then create the COM port as follow:
Set-VMComPort -VMName YourVMName 1 \\.\pipe\DebugIT
The “1” is the COM port you want to use (feel free to adjust it if needed) and the pipe path. The last string of the pipe can as well be adjusted, you could use something else than DebuIT.
- Start the VM
- Enable debugging:
bcdedit /debug on
bcdedit /dbgsettings serial debugport:n baudrate:115200
where n is the port number defined in step 2.Reboot the VM.
- Open up WinDbg and choose File –> Kernel Debug
- Configure the COM connection according to the screen shot:
- You will see “Waiting to reconnect…” afterwards. That’s ok because we haven’t started yet debugging. Choose Debug –> Break (or Ctrl+Break). That’s it, you’re now able to debug the kernel of the running VM:
Windows Error Reporting is a nice tool from Microsoft. It collects required Information from an exception that happend and (if you want so) checks online if there is a solution for your issue. By default it creates a memory minidump of that process that crashed. Often a minidump is good enough to narrow down the issue, but what if it’s not enough? There’s the possibility to enable full Memory dumps when an application crashes. You can enable it with the following key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps]
That’s it. There is no restart required.
Note that the above is a global setting (per computer). It’s also possible to set it just for 1 application. See http://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).aspx for more Information.
Currently we get SESSION_HAS_VALID_POOL_ON_EXIT (ab) BSODs regularly on our Windows Server 2012 servers. These servers are used as XenApp servers and therefore a BSOD on such a server is pain in the ass when you have 50 users or even more working on such a server.
Finally Microsoft confirmed that this is a bug and they are now working on a fix. I will update this post as soon as I get a hotfix that resolves the issue.
The windbg output looks as follow:
Update 05.09.14: I got a private hotfix from Microsoft that definitively fixes the issue. I informed the Microsoft engineer today that they can start to initiate the process to release a public hotfix. We have seen the BSOD 1-2 times per day, and it completely disappeared since we applied the hotfix. There seems to be another bug we discovered by another BSOD that Microsoft is analyzing, but finally no AB BSOD!
Update 11.02.15: The fix has now been released for public:
More Information: https://support.microsoft.com/kb/3036220