B
BerntR
Guest
I am supposed to make an audio driver, but so far I have been unable to connect a debug session with the client.
I can ping back and forth between the machines by numbers, by name only from vm to host.
Windows 10 pro on host and vm. Logging on with admin rights on both.
I've tried to start debugging through network and com ports, but I get the same result.
Right now, when I start windbg I get:
Opened \\.\pipe\vcom2
Waiting to reconnect...
... and that pretty much sums up my most successful trials. Restarting the VM makes no difference,
I get similar results from visual studio 2019 (with the addition: ... the client actively refused...) and when try to start a debug session using kd.exe.
I've tried 1st and 2nd gen hyper-V and get the same result.
My PC is wifi connected to internet. I get the VM on internet by using a network adapter with an internal switch, and on the host share the wifi adapter with the virtual adapter. Somewhere along the road I learned that the wifi adapter is not on the VerifiedNICList.xml. The ethernet adapter is on the list and I have also made a network adapter with external switch where this is embedded. The machine is however not ethernet connected and I don't know whether I can use it here.
I've made the required openings in the firewall on the vm and for the last days I've simply kept the firewall turned off just in case.
I've tried several step-by-step procedures and to my knowledge I have followed them all to the letter.
My journey started here - KDNET v1: Setting Up KDNET Network Kernel Debugging Automatically - Windows drivers
I see one deviation from the example that may be significant:
C:\KDNET>kdnet
From the article: Network debugging is supported on the following NICs: busparams=1.0.0, Broadcom NetXtreme Gigabit Ethernet, Plugged in. This Microsoft hypervisor supports using KDNET in guest VMs.
On my vm:
Network debugging is supported by this Microsoft Hypervisor Virtual Machine.
Based on this I decided to try the com route (somewhat later)
Tried kdnet v2: Setting Up Kernel-Mode Debugging of a Virtual Machine Manually using a Virtual COM Port - Windows drivers
KDNET v3: Attaching to Windows Kernel with KDNET — a Short Guide
Com: Setting Up Kernel-Mode Debugging of a Virtual Machine Manually using a Virtual COM Port - Windows drivers
Since I couldn't find the com ports in 2.gen vm I made 1st gen vm and tried that too. Got the same result.
Then I found a way to establish named pipes in 2. gen here: Hyper-V generation 2 virtual machines – part 5
When I follow the com approach I see no deviation from the prescribed one until I try to start the debugging session.
My most recent "discovery" was to use msconfig to specify com2 as the debug port. Same result.
I suspect that the problem is network related. My knowledge in this area is very limited and do not know what to do when the suggested step-by-step instructions fail. And for the first time I am at the point where I am unable to google up anything worth trying that I haven't tried several times already.
Continue reading...
I can ping back and forth between the machines by numbers, by name only from vm to host.
Windows 10 pro on host and vm. Logging on with admin rights on both.
I've tried to start debugging through network and com ports, but I get the same result.
Right now, when I start windbg I get:
Opened \\.\pipe\vcom2
Waiting to reconnect...
... and that pretty much sums up my most successful trials. Restarting the VM makes no difference,
I get similar results from visual studio 2019 (with the addition: ... the client actively refused...) and when try to start a debug session using kd.exe.
I've tried 1st and 2nd gen hyper-V and get the same result.
My PC is wifi connected to internet. I get the VM on internet by using a network adapter with an internal switch, and on the host share the wifi adapter with the virtual adapter. Somewhere along the road I learned that the wifi adapter is not on the VerifiedNICList.xml. The ethernet adapter is on the list and I have also made a network adapter with external switch where this is embedded. The machine is however not ethernet connected and I don't know whether I can use it here.
I've made the required openings in the firewall on the vm and for the last days I've simply kept the firewall turned off just in case.
I've tried several step-by-step procedures and to my knowledge I have followed them all to the letter.
My journey started here - KDNET v1: Setting Up KDNET Network Kernel Debugging Automatically - Windows drivers
I see one deviation from the example that may be significant:
C:\KDNET>kdnet
From the article: Network debugging is supported on the following NICs: busparams=1.0.0, Broadcom NetXtreme Gigabit Ethernet, Plugged in. This Microsoft hypervisor supports using KDNET in guest VMs.
On my vm:
Network debugging is supported by this Microsoft Hypervisor Virtual Machine.
Based on this I decided to try the com route (somewhat later)
Tried kdnet v2: Setting Up Kernel-Mode Debugging of a Virtual Machine Manually using a Virtual COM Port - Windows drivers
KDNET v3: Attaching to Windows Kernel with KDNET — a Short Guide
Com: Setting Up Kernel-Mode Debugging of a Virtual Machine Manually using a Virtual COM Port - Windows drivers
Since I couldn't find the com ports in 2.gen vm I made 1st gen vm and tried that too. Got the same result.
Then I found a way to establish named pipes in 2. gen here: Hyper-V generation 2 virtual machines – part 5
When I follow the com approach I see no deviation from the prescribed one until I try to start the debugging session.
My most recent "discovery" was to use msconfig to specify com2 as the debug port. Same result.
I suspect that the problem is network related. My knowledge in this area is very limited and do not know what to do when the suggested step-by-step instructions fail. And for the first time I am at the point where I am unable to google up anything worth trying that I haven't tried several times already.
Continue reading...