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 140 Reputation points

2025-11-08T21:48:11.8233333+00:00

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
Please sign in to rate this answer.

13 people found this answer helpful.
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.
Sign in to comment

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

17 additional answers

Stefan Cuypers 100 Reputation points

2025-09-03T17:40:52.6966667+00:00
I have a fix that seems to work for my 2012R2.
After more testing with MS support, the support engineer suggested to do an inline repair :

First run the VM on an unpatched Windows Server 2025 so we can start it up. (may also work if done on a 2022, but not tested)

Attach the Windows Server 2012R2 DVD (I used the latest from volume licensing)

Run setup from the DVD and select the option to upgrade (keep settings)

Let it run the upgrade

Then move the VM back on a patched Windows Server 2025

After that my 2012R2 VM booted fine on a patched Windows Server 2025.
Please sign in to rate this answer.

1 person found this answer helpful.
Hammer 0 Reputation points

2025-09-04T17:46:01.25+00:00

Hi, tried this and was able to bring up my 2012R2 Essentials VM on an unpatched Server 2025 host. However, when I try to do the “upgrade” I get an error that says Server 2012R2 Essentials cannot be upgraded to Server 2012R2 Essentials. Maybe this is specific to the Essentials version. So hopefully, another workaround will be found! Thank you.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Ben Gillam 10 Reputation points

2025-07-30T09:46:33.1433333+00:00

We have this same or similar issue although not a cluster.

Windows 2025 server - Moved 3x Windows 2012 R2 VMs to it back in April time - They are archival manual boot access for old accounts system. Worked fine at time. Later tried to boot and they all fail. Restores from backup failed, new export and import fails etc which lead me here.

The tweaks to Storsvc recommended along with a new export didnt work for me.

I don't seem to have any of the updates listed however maybe they were bundled into a cumulative update.

At the point now of bringing a previous 2019 host online again to host these VMs if 2025 isnt going to play ball with them unless a fix comes along soon.
Please sign in to rate this answer.

1 person found this answer helpful.
Kalabis Tomáš 15 Reputation points

2025-07-30T09:56:49.4933333+00:00

try to run this comman in ps:
Get-HotFix -Id KB5060842

Dimitri Iacomi 0 Reputation points

2025-07-30T10:04:28.2+00:00

Same scenario here, KB5060842 NOT installed and vm not booting.

Only those 3 hotfix are installed:

Kalabis Tomáš 15 Reputation points

2025-07-30T10:33:54.64+00:00

what about try to uninstall KB5063666 ? - the security update.
did you have resoruce to try it ?

Ben Gillam 10 Reputation points

2025-07-30T10:51:34.2366667+00:00

these are my updates

in terms of removal I would have to wait until the weekend to test it. Although i'm never a huge fan of removing or blocking an update if it affects something else adversely or leaves a security risk.

Stefan Cuypers 0 Reputation points

2025-07-30T12:11:59.71+00:00

These are cummulative updates, so the problem is in any of the later updates too. Starts with KB5062553 but also present in later updates KB5064489 and KB5062660.

Still no engineer assigned on Microsoft support ticket. Got assigned an Escalation Support Manager though. Hope to get a reaction soon now.

Derek Loseke 5 Reputation points

2025-07-30T21:29:31.46+00:00

Same for me. I tried the registry keys and no dice. Then I tried the other suggestion of adding and removing a storage adapter and when I brought the 2012 R2 machine back up, it started boot looping the same as well, but on the 2016 cluster now. Fortunately, it was a clone of the production machine.

Derek Loseke 5 Reputation points

2025-07-30T22:45:36.8333333+00:00

Okay, so I have a 2025 3-node cluster. I'm coming from a 2016 cluster. Server 2012 R2 VM was blue screening on boot until I removed KB5060842 from one of the hosts. With that KB removed, VM boots up perfectly fine. I'm going to roll back to my 2016 cluster for the time being until there is a good solution that doesn't involve uninstalling/blocking an update, but that worked perfectly for me. The other suggestions haven't worked at all for me.

Kalabis Tomáš 15 Reputation points

2025-07-31T06:35:59.9033333+00:00

Yes Derek, same issue as in the cluster of my customer. remove of KB5060842 helps !

https://tomaskalabis.com/wordpress/problem-booting-windows-2012r2-vm-on-windows-2025-hyper-v/
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Oliver Kehling 0 Reputation points

2025-07-22T16:41:13.6+00:00

Hi, I have a similar problem. I'm currently replacing a Hyper-V Server 2019 with a Hyper-V 2025. There are still two Windows Server 2012 R2 VMs on the Hyper-V 2019 server. After exporting and then importing to the Hyper-V 2025, the VM won't boot. Error: Inaccessible Boot Device. I tried the workaround with the SCSI controller, but unfortunately it didn't help. Regards, Oliver
Please sign in to rate this answer.

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Henry Mai 7,970 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

What Generation is the failing 2012 R2 VM (Gen 1 or Gen 2)?

In the VM's settings, is the boot VHDX file attached to an IDE Controller or a SCSI Controller?

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

Move the problematic VM back to the working cluster and boot it up.

Shut down the VM. In Hyper-V Manager, go to its Settings.

Add a SCSI Controller to the VM. You don't need to attach a disk to it; just adding the controller hardware is enough.

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.

Once the driver is installed, shut down the VM.

You can now remove the temporary SCSI controller you added in step 3.

Move the VM to the new cluster and try to boot it.

Hope this helps.
Please sign in to rate this answer.
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 7,970 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 180 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 7,970 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 7,970 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 7,970 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.

Share via

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

17 additional answers

Your answer