Problem booting Windows 2012R2 VM on Windows 2025 Hyper-V

Stefan Cuypers 100

We're having a problem with a Windows Server 2025 Hyper-V cluster.

We have 2 identical clusters (same hardware, same BIOS version) and when we move a Windows 2012R2 VM from one cluster to another it does not boot any more (tested with 2 different VM's).

The error is a blue screen 0x7B (INACCESSIBLE_BOOT_DEVICE).

If we move the machine back to the other cluster it boots just fine.

Only difference I see is the cluster path level. The working cluster is an older Windows Update (KB5058411, KB5058523 and KB5054979).

Whereas the newer cluster has KB5063666, KB5062553, KB5056579 and KB5059502. It tried installing KB5064489 also, but that does not help.

A VM with Windows server 2022 of 2025 does move fine, so it seems to be linked to 2012R2.

I also tried to install a brand new 2012R2 VM from the original iso and then completely upgrading it with Windows Update and that machine is working fine. It seems to have the same verson of storage drivers as the non working VM.

The faulting VM does boot succesfully into recovery mode. I tried bootrec /fixmbr and bootrec /fixboot, but that does not help.

TPIT 1 Reputation point

2025-07-21T03:47:13.84+00:00

Same issue here. Sadly I could not pin down the exact faulty update!

but thanks for your direction!

Thought, I killed my VM. Even the back up…. :D

Answer accepted by question author

Vladimir Shebaldenkov 145

I compared the registry of a VM that boots with one that doesn’t and found some differences.

Then I booted into recovery mode, copied the missing registry keys, and successfully booted the Windows Server 2012 R2 VM on a 2025 Hyper-V host.

reg load HKLM\TempHive c:\Windows\system32\config\SYSTEM

reg copy HKLM\TempHive\ControlSet001\Enum\ACPI\VMBus HKLM\TempHive\ControlSet001\Enum\ACPI\MSFT1000 /s

reg copy HKLM\TempHive\ControlSet001\Enum\ACPI\Hyper_V_Gen_Counter_V1 HKLM\TempHive\ControlSet001\Enum\ACPI\MSFT1002 /s

Bjørn Bendix 10 Reputation points

2025-11-09T10:54:45.4333333+00:00

Works perfect! Thx for your work!
TPIT 1 Reputation point

2025-11-09T12:25:02.85+00:00

Thanks !
Hammer 0 Reputation points

2025-11-09T20:50:35.9533333+00:00

Worker for me too! Thank you!!!
Stefan Cuypers 100 Reputation points

2025-11-10T08:12:41.2766667+00:00

Great work! Works for me too. Thanks a lot.
Andy Bryant 20 Reputation points

2025-11-10T09:51:03.03+00:00

Works for me too. Awesome job! Thank you @Vladimir Shebaldenkov
Richard Hunt 0 Reputation points

2025-11-11T06:31:51.77+00:00

Could you not just export the two keys and then import them in the same HKLM/System/CurrentControlSet/Enum/ACPI root or must be done in recovery mode and in must use ControlSet001 ?
Stefan Cuypers 100 Reputation points

2025-11-11T08:44:48.1+00:00

Some more analysis on what in KB5060842 triggers the problems.

Analysing the ACPI configuration in the BIOS it seems that the ids of some devices have changed.

The 'VMBus' name was defined as an _HID (hardware id).

After the update it is defined as a _CID (compatible id) and MSFT1000 has become the _HID.

Same applies for the Hyper_V_Gen_Counter_V1 device which has become _HID MSFT1002.

Though this should theoretically not pose a problem (Windows should look at both _HID and _CID's) it seems Windows 2012R2 (or older Hyper-V integration services on it) has a problem with this for boot devices.
Glenn Rimington 0 Reputation points

2026-02-09T23:01:29.45+00:00

FANTASTIC!!!! - That worked for me too. Thank you.
Peter Jericho 0 Reputation points

2026-02-09T23:20:11.7033333+00:00

Worked straight away. Thank you.
MARKO TAMM 0 Reputation points

2026-02-26T20:02:00.2866667+00:00

Thank You very much, You saved me alot of time :)
Mulani, Waqas 0 Reputation points

2026-03-01T08:12:38.1733333+00:00

I wanted to let you know that this fix works for me as well.

Thank you so much for all your effort in finding this solution.
CARLOS ANDRES BUITRAGO C 0 Reputation points

2026-03-16T18:15:02.2433333+00:00

Gracias!!
Fernando J. Pineda B 0 Reputation points

2026-08-28T13:40:29.5233333+00:00

I used this procedure on 08-27-2026 to gain access to a Server 2012 VM (Host on Server 2012R2 Crashed and serious damaged and unbootable) imported via Server Backup on a 2025 Server Hyper-V Host.

I found two problems, the first one is protections on the registry zone if the computer you are using to edit the registry have KB5060842 installed or its up to date and recently installed, y manage to use an old VM on Windows 10 24H2 and was able to do it (It shows an access denied error but make the changes on the registry file on the TempHive)

The second problem is that the VM (Now able to boot) will boot just once, so don't restart it or turn it off until you upgrade the OS on the VM (InPlace-Upgrade) or get whatever you need from the VM (Don't restart or shut down)

Probably you will get a VM working but without operational network, in my scenario, it get solved while you run the update to server 2019 or newer OS.

Thanks a lot to Vladimir Shebaldenkov to get us a lead to work and solve the problems!

17 additional answers

Henry Mai 8,225 Reputation points Independent Advisor

2025-07-21T09:04:16.85+00:00
Hello Stefan, I am Henry and I want to share my insights about your issue.

The 0x7B INACCESSIBLE_BOOT_DEVICE error means Windows is starting up, but it cannot find the driver for the storage controller that its boot drive is connected to.
- On your old cluster, the VM boots using an older virtual IDE or SCSI controller. Windows has that driver and loads it at startup.
- On your new Server 2025 cluster, Hyper-V presents a newer, more efficient virtual SCSI controller. The driver for this new controller (storvsc.sys) exists inside your 2012 R2 VM (as part of Integration Services), but Windows doesn't know it needs to load it during boot.
To clarify, may I know
1. What Generation is the failing 2012 R2 VM (Gen 1 or Gen 2)?
2. In the VM's settings, is the boot VHDX file attached to an IDE Controller or a SCSI Controller?
3. On the working cluster, have you tried manually updating the Integration Services inside the 2012 R2 guest OS itself?
You can refer the procedure below as it can force the 2012 R2 guest OS to automatically install and register the storvsc.sys driver as a boot-critical device
1. Move the problematic VM back to the working cluster and boot it up.
2. Shut down the VM. In Hyper-V Manager, go to its Settings.
3. Add a SCSI Controller to the VM. You don't need to attach a disk to it; just adding the controller hardware is enough.
4. Start the VM again (on the working cluster). Log in and allow Windows to detect the "new" SCSI controller and automatically install the driver (storvsc.sys). You can verify it appears in Device Manager.
5. Once the driver is installed, shut down the VM.
6. You can now remove the temporary SCSI controller you added in step 3.
7. Move the VM to the new cluster and try to boot it.
Hope this helps.
Was this answer helpful?
Stefan Cuypers 100 Reputation points

2025-07-21T09:21:19.9733333+00:00

Hello Henry,

Thank you for the reaction.
Note that both clusters are on Windows Server 2025 (just a different patch level).

The VM is booting from the SCSI Controller. This is the same on both clusters.

I've looked in msinfo32 in the VM when running on the old cluster. Under Storage-SCSI it has the 'Microsoft Hyper-V SCSI Controller' loaded in status OK. It has version 6.3.9600.19984 which is also the installed version of integration services. I haven't found any more recent versions.

The VM is Gen2.

Henry Mai 8,225 Reputation points Independent Advisor

2025-07-21T09:43:46.5333333+00:00

This suggests your new VM works because it was installed on the new host, so its driver was initialized correctly from the start. I am not sure whether you try manual upgrade of the problematic VM outside the active cluster, that could assist in repairing the OS boot loader and updating the driver store for the new environment.

Stefan Cuypers 100 Reputation points

2025-07-21T10:13:59.8566667+00:00

The drivers should be the same since the host OS is the same.
I just did an export of the VM and restored it on the other cluster. And it does not boot. If I do the export again on the non working cluster and restore that on the working cluster it works fine.
So I suspect strongly that the more recent patch level on the non working cluster is the cause and that it has somehow introduced an incompatibility with the 2012R2 image.
With a completely new installed 2012R2 it does seem to work though, but I can't find the causing difference between then new 2012R2 and the existing 2012R2 machines (I tested 2 existing 2012R2 machines and both fail to boot when moved to the other cluster).
I also tried to mount the disk of the failing VM onto the VM with the working new 2012R2 and that does not help. So the VM configuration itself does not seem to be the causes, but something inside the VM does not like the host.

Mark Zuber 185 Reputation points

2025-07-22T10:20:01.71+00:00

Hello everybody,

We are in the same situation as Stefan.

We suspected the SCSI drivers and integration services as well.

As a possible solution, we moved the 2012 R2 VM to a Windows Server 2019 Hyper-V host and updated the drivers through integration services. The VM was able to start on the 2019 Hyper-V host. However, exporting from the 2019 server and importing to the 2025 server still does not work.

Another unsuccessful attempt was adding an additional SCSI controller to the VM on the 2019 server in the hope that it would initialize newer drivers.

Creating a new VM on the 2019 server and attaching the VHDX disk and exporting/importing it on the Server 2025 did not work either.

We are still looking for a solution.

Stefan Cuypers 100 Reputation points

2025-07-23T05:01:25.24+00:00

I ran a comparison between disks with a working Windows Server 2012R2 and a non working and found a difference in Hyper-V drivers vmbkmcl.sys, vmbus.sys and winhv.sys (and in system32 vmbuspipe.dll and vmbusres.dll). The version on the non working VM is 6.3.9600.18080 and on the working VM 6.3.9600.19984. Both are up to date with Windows Update and I can only find Hyper-V integration components update for Windows virtual machines - Microsoft Support update, which is the 18080 version. Any idea where I can find the 19984 version?

Stefan Cuypers 100 Reputation points

2025-07-23T05:16:37.21+00:00

And even stranger, if I run devmgmt.msc and look at the properties of the Hyper-V Virtual Machine Bus driver it shows the same driver version (6.3.9600.19984) for both working and non working VM's. If I look into Driver Details however the non working machine has version 6.3.9600.18080 on all files except on vmbusres.dll. And the working machine has 6.3.9600.19984 on all driver files.
Looking in the driverstore on the non working machine it does have 6.3.9600.19984 on all dll's.
So I have the impression that a driver update was not applied correctly on the non working machine.

Stefan Cuypers 100 Reputation points

2025-07-23T05:54:15.5+00:00

Tried from recovery console to update the Virtual Machine Bus driver, but does not seem to help.
c:

cd \Windows\System32\drivers

copy C:\Windows\System32\DriverStore\FileRepository\wvmbus.inf_amd64_cd3021d55bc8bd17\vmbus.sys .

copy C:\Windows\System32\DriverStore\FileRepository\wvmbus.inf_amd64_cd3021d55bc8bd17\vmbkmcl.sys .

copy C:\Windows\System32\DriverStore\FileRepository\wvmbus.inf_amd64_cd3021d55bc8bd17\winhv.sys .

cd \Windows\System32

copy C:\Windows\System32\DriverStore\FileRepository\wvmbus.inf_amd64_cd3021d55bc8bd17\vmbuspipe.dll .

copy C:\Windows\System32\DriverStore\FileRepository\wvmbus.inf_amd64_cd3021d55bc8bd17\vmbusres.dll .

Henry Mai 8,225 Reputation points Independent Advisor

2025-07-26T17:02:39.76+00:00

Hello Stefan, I am so sorry for late response. The earlier response was based on initial details and a common root cause for this error. Previous Diagnosis: The VM was missing the updated storage driver, or the driver wasn't registered as boot-critical. Previous Solution: Adding a new SCSI controller to simulate “new hardware” detection, prompting Windows to install and properly register the driver.

However, after you attempted troubleshooting, it appears the VM's boot registry is referencing an incorrect version of the storage driver, despite the correct files being present on disk. As a result, the OS cannot boot to repair itself. So my recommended approach is use a working Windows Server 2012 R2 VM to manually repair the driver registration inside the offline (non-bootable) VHDX by running: DISM /Image:E:\ /Add-Driver /Driver:"C:\Windows\System32\DriverStore\FileRepository" /Recurse

This command scans and installs valid drivers from the functional OS, ensuring they're properly registered in the offline image.

Not sure if you’ve already tried this method.

Stefan Cuypers 100 Reputation points

2025-07-27T08:59:17.8633333+00:00

Hi Henry, does not work I'm afraid.

I executed the command to copy the drivers to the VM and it did not make a difference.

Next I booted the VM in a working environment - took a while to boot so I assume it was applying the drivers.

Then took the VM back to the non working environment with the drivers configured but it keeps failing.

Henry Mai 8,225 Reputation points Independent Advisor

2025-07-27T13:09:58.8933333+00:00

Could you please confirm the following points about the procedure you just tried?

Host Environment: Was the entire repair process (attaching the disk to the working VM and running the DISM command) performed while the "helper" VM was running on a host in the NEW (non-working) cluster?

Post-Repair Steps: After running DISM and shutting down the helper VM, did you immediately try to boot the repaired VM on the NEW cluster, and confirm you did not boot it on the old (working) cluster in between?

Detail Steps:

Attach the Problem VHDX to the Working VM:

In Hyper-V Manager, edit the settings for your new, working 2012 R2 VM.

Select the SCSI Controller, click Hard Drive, and then Add.

Browse to and select the VHDX file of the non-working VM.

Boot the Working VM and Prepare Drives:

Start the working 2012 R2 VM.

Open Disk Management (diskmgmt.msc). You will see the disk from the non-working VM. Right-click it and bring it Online.

Note the drive letters. For example, C:\ is the working OS, and E:\ is the offline OS you just mounted.

Run command: DISM /Image:E:\ /Add-Driver /Driver:"C:\Windows\System32\DriverStore\FileRepository" /Recurse

(Important: Replace E:\ if your offline OS mounted to a different drive letter.)

Henry Mai 8,225 Reputation points Independent Advisor

2025-07-27T13:12:28.52+00:00

Or you can try with this

Attach VHDX and Boot Helper VM: attach the non-working VHDX to the working VM and bring the drive online (e.g., as E:).

Repair the Boot Configuration: Open an elevated Command Prompt inside the working VM and run these commands to repair the boot files on the offline drive.bcdboot E:\Windows /s E: /f UEFI bootrec /rebuildbcd

Attempt to Restore the Registry Hive: We will replace the potentially corrupt SYSTEM hive with its last known good backup.

Back up the current (bad) registry hive: ren E:\Windows\System32\config\SYSTEM SYSTEM.bad

copy the automatic backup to replace it: copy E:\Windows\System32\config\RegBack\SYSTEM E:\Windows\System32\config\SYSTEM

Finalize and Test: Shut down the working VM, detach the repaired VHDX, and try to boot the original VM on the new cluster.

Stefan Cuypers 100 Reputation points

2025-07-27T14:27:23.4666667+00:00

Host Environment: Was the entire repair process (attaching the disk to the working VM and running the DISM command) performed while the "helper" VM was running on a host in the NEW (non-working) cluster? --> Yes

Post-Repair Steps: After running DISM and shutting down the helper VM, did you immediately try to boot the repaired VM on the NEW cluster, and confirm you did not boot it on the old (working) cluster in between? --> Yes, tried that first. Then when that did not work I tried booting on the old working cluster to have the drivers actually updated and then moved back. But that did not work either.

Stefan Cuypers 100 Reputation points

2025-07-27T14:37:52.52+00:00

Or you can try with this:
Tried these steps, but did not help.
The bootrec command was not possible though. That is only available in the recovery console I think. So tried that from recovery console on the failing VM but did not help. Note that bootrec reported it found 0 Windows installations.

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Problem booting Windows 2012R2 VM on Windows 2025 Hyper-V

17 additional answers

Your answer