I already posted this in the windbg list, but noticed it got no replies and that list only has only 1 other post in the last 2 weeks. Here is my issue:
I’m trying to use WinDbg 10 (1607) to debug Hyper-V and can’t get the target to connect.
* I have tried with Windows 2008 x64 and Windows 10 x64
* I checked my .vmx file and have my serial settings set to \.\pipe\com1_w2k (or win10) The other settings also look ok.
* I am following the directions on https://msdn.microsoft.com/en-us/library/windows/hardware/ff540654(v=vs.85).aspx
* vmdemux.exe prints “Requerying active channels from the hypervisor” Sometimes it also prints "Read Failed again 87071468
* kd.exe just shows “Waiting to reconnect…”
* On windows 2008, I was able to do echo hello>com1 and confirm from my host machine that the message was arriving in putty
* On Windows 10, I couldn’t echo to com1, but I could see that the early boot process is calling out because it dumps a chunk of non-ascii to COM1 followed by the text “hvi64.exe”
* In both cases, it was not connecting to remote.exe , kd.exe, or windbg.exe
Suggestions?
I should probably clarify that I am trying to get setup to debug the Windows hypervisor itself. I have a Windows host OS running VMWare and several VMWare guests running Windows Server 2008, Windows 10, etc…
Ideally, I’d like to do all the debugging on 1 computer. Given that I see data coming out the Virtual Serial port in putty, it seems like my connection is fine, but windbg and remote.exe are not recognizing the debugging target.
I considered using VMWare and gdb stubs, but I’d really prefer using windbg
Use network debugging rather than serial debugging, it is much faster.
Use two machines, the first runs WinDbg and the second (test machine) runs the hypervisor (Win10). Do not install VMWare on the second machine, just activate the HyperV feature of the OS. You can download Win10 Entreprise Evaluation Version from MSFT web site.
I just got a chance to try out your suggestion of using network debugging and it worked.
On a related, I was debugging an issue on a Windows 10 target and also could not get either VirtualKd or serial to connect, but was able to get network debugging to connect. This seems very strange to me.
The code needed to send and receive data across a serial port is about 50 bytes and requires no OS support. The code needed to enable TCP/IP network debugging is much larger and requires significant OS support. It seems really strange that network debugging of some kernel component would succeed while serial debugging, which is recommended on MSND, would fail.
Today, you have more computers with a NIC card and no serial port than computers with a serial port and no NIC card. A network cable is also far easier to find than a USB, serial or firewire cable.
Network debugging is available since Win8 and since Win7 owners have recieved an offer to upgrade to Win10 freely, there are little chance that you will need serail debugging again.
I guess it depends on what you count as a “computer” – My Surface, for example… Does that count? My Raspberry Pi? My phone??
Yeah… no.
Network debugging is fine, and works pretty well, when you want it. But it is absolutely, positively, NOT a cure-all for all problems related to debugging.
The biggest problem with network debugging is that it requires you to have your test system ON THE NETWORK. Unless you live on an air-gapped network, or you have multiple NICs in your dev machine (one for your ordinary network access to the symbol server and the other for a private network to your test systems), this means that your test machine will have the pleasure of spewing stuff out onto your ordinary development network… and YOU will have the pleasure of getting Windows Update run on your test system whenever it feels like it.
So, network debugging has its place. But it is NOT my preferred debug transport. That honor goes to 1394… which isn’t officially supported for debugging anymore.
Here is an excerpt of an interesting article published on OSR’s web site that may help understand what happens with the OP’s setting:
"For all that I love debugging with VMs, there is one thing that I absolutely hate: KD debugging with virtual COM ports. Specifically in the case of VMware Workstation, which is what I use for my day to day virtualization needs, it?s painfully slow. Even worse, the virtual COM port doesn?t quite mimic the behavior that WinDbg expects from a real COM port. This leads to more than the occasional WinDbg hang or crash.
Thankfully, starting in Windows 8 there is a new way to solve this problem: KD debugging over Ethernet! Instead of piping a virtual COM port over a named pipe …"