If you used Disk2vhd utility on a Windows 7 box to create an image, but your new VHD or VHDX has a “Windows failed to start” message and/or a blue screen of death (BSOD) which references 0x000000d7, then you’re in the right place to get it sorted.
First off there may be more than one way to solve this problem. Some people suggest using a dedicated industry tool to move systems from P2V (Physical to Virtual). Totally get that and if you find yourself doing P2V a lot then buying software likely makes sense to you. Other people suggest using Sysprep to prepare your old system as a quasi-template (they say it disconnects the software from the specific hardware on that machine so you can stand the image up elsewhere). You’re free to try that too; I don’t know if it does because I only ever used Sysprep when deploying a bunch of duplicate images to identical hardware, not for moving an already established and well-worn OS like this 7 build. Others say you need to use DISM to inject missing drivers into the image,…blah blah blah. If you want to spend your time locating old motherboard drivers and trial-and-error inserting and spinning up the same VM many times that’s fine. It may even work, but I didn’t do that either.
What I know does work when you are faced with a Win 7 guest OS that won’t start in your Hyper-V is some simple editing of the Registry on the new VHDX. I know, I know…nothing in the Registry is simple and you could screw it up. So be careful, okay?
The Problem:Â
The BSOD is a boot driver problem. The OS isn’t on the same hardware anymore, so it freaks out and stops. It’s probably the AHCI (Advanced Host Controller Interface) giving you grief (and intel hardware more generally, IDK exactly). But regardless, I’m reliably informed that if you remove the AHCI support on the virtual machine you can get it to boot.
The Fix:
When your VM doesn’t start up, the system will likely try to self-heal by going through a Restore. That won’t work, but after it fails you’ll have the option to bail into the Advanced Repair Options. Select the Command Line interface, open up RegEdit, then start the easy fix outlined below:
- In RegEdit: select HKEY_LOCAL_MACHINE (HKLM)
- Click File–>Load Hive
- Navigate to C:\Windows\System32\Config
- Load the SYSTEM hive
- Give it a temporary name…..like…TEMPHIVE
- You’ll see it show up on the left under HKLM/TEMPHIVE. Click on it. Navigate to TEMPHIVE/ControlSet001/services
- Modify all these keys in the following way. NOTE: Some keys’ values may already be correct! Document any changes you make so you can reverse them if you find you need to for some reason.
aliide  – Change the value “Start” to 3
amdide – Change the value “Start” to 3
atapi   – Change the value “Start” to 0
cmdide – Change the value “Start” to 3
iaStorVÂ – Change the value “Start” to 3
intelide – Change the value “Start” to 0
msahci – Change the value “Start” to 3
pciide  – Change the value “Start” to 3
viaide  – Change the value “Start” to 3 - Once you are done, click back on the folder for TEMPHIVE and then go to
File–>Unload the Hive - ‘exit’ and restart the VM and it should load Windows 7 correctly (expect to see the usual notifications about drivers being loaded etc). It’s not super clean… the correct thing to do would be to build a new Win 7 guest OS, apply all the patches, install the software, etc etc. I didn’t do that. I just needed this machine to exist somewhere for a few more months as the users who depend on it need to run a piece of legacy software that doesn’t run on anything above 7. This solution gets me there. YMMV. Use at your own risk.
Shout Out: The above instructions were reproduced for my own use/archive from an excellent source I stumbled upon through searching forums for a quick solution: VHD boot to Hyper-V => blue screen | Kouilb’s Blog (wordpress.com).
