For a very long time, I've quite enjoyed testing early builds of things. Getting onto the DOS 5 beta was cool, as was NT 3.1 B1. More recently, the Windows Insiders builds have been interesting. Most have been pretty simple - a bit of new functionality here, a bit there. Occasionally, stuff just doesn't work - in one build WSL was broken, in another Bluetooth was borked. Such is life - and if the feedback generated is helpful that's great.
Recently, I had some more serious issues. Build after build would simply not stick. After something like 25 failed attempts, there were two suggestions. The first was to take Hyper-V off which seemed like Voodoo (not that that is a bad thing!). The second was to do kernel debugging to help the team work out why the failures were occurring.
So I began looking at kernel debugging across the network. The directions at https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-a-network-debugging-connection-automatically seemed to be pretty simple. And assuming you can read, they looked easy enough for me to try.
Initially, I had issues using KDNet and got some curious error messages. KDNet said that my NIC was supported, but not plugged in. Weird as I was able to use Google to see if I could find the error message. After getting windbg setup on the debug host, KDNet on the target gave me further registry read errors. I took the opportunity of changing the network cable (although the old one worked fine in another host). But I was stuck with networking not working.
Using KDNet to setup kernel debugging makes changes to the boot configuration database (you can see that with BCDEdit). And that means after rebooting, the NIC appears to be gone. Looking at Device Manager, I saw a weird (to me) error message "This Device Has Been Reserved for Use by the Windows Kernel Debugger for the Duration of This Boot Session." I was about to just flatten the box, when one last bit of search engine magic pointed me to this post: https://www.majorgeeks.com/content/page/code_53_this_device_has_been_reserved_for_use_by_the_windows_kernel_debugger_for_the_duration_of_this_boot_session.html
But even so, my system was just not working and I decided that flattening it and starting over would be the fastest way to move on. But given how long it was going to take - why not try to take Hyper-V off and see if it made a difference. So after backing up 250GB of VMs, I took Hyper-V off and rebooted.
With Hyper-V removed, I was back to having just one NIC, and after configuring the IP address, it worked. Then I used WU to download the latest Insiders build - and that installed OK! Adding Hyper-V and importing the VMs went flawlessly and I'm back in business. On the latest Insider's build and with a working Hyper-V farm (and no need to reinstall all those apps...)
Thanks to some great folks: Eddie Leonard, Jason Howard, and Murray Wall were all helpful. Murray was the one who suggested removing Hyper-V (which did not seem logical). Jason/Eddie got me into a mess of my own making. It is reassuring to know that the Insiders folks are able to help!
Kernel Debugging across the network is easy if you follow directions properly. IMHO, the instructions could be improved a bit for non-dev types and to make it even clearer what to do on the host vs what to do on the target. And for sure a "how to undo what kdnet did" section would be useful!
It is disappointing that this episode did not capture any useful output for the Insiders team. But it's good to be back and working again.
