Share via

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

Stefan Cuypers 75 Reputation points
2025-07-20T05:33:22.69+00:00

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.

Windows for business | Windows Server | Storage high availability | Virtualization and Hyper-V

17 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. HenryMai-3878 6,585 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.

  2. 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

    0 comments
  3. BryceSor 4,500 Reputation points Volunteer Moderator
    2025-07-23T07:35:30.35+00:00

    Hi Stefan,

    I been watching this post and ask CP if a script would help in your case to check the drivers etc in your 2012r2 VM.

    Its up to you to try it but I hope it helps .

    Absolutely, Bryce. Here's a PowerShell script tailored to check whether key storage and synthetic drivers (like storvsc, vmbus, winhv) inside a Windows Server 2012 R2 VM are:

    • Present and properly registered in the system registry

    Configured to load during boot

    Part of the correct driver group (e.g., System for boot-critical)

    Compatible with newer Hyper-V patch levels

    You can run this inside the affected VM (or remotely with PowerShell Direct):

    powershell

    # PowerShell Script: VM Boot Driver Audit Tool for Windows Server 2012 R2
$driversToCheck = @("storvsc", "vmbus", "winhv")

foreach ($driver in $driversToCheck) {
    $path = "HKLM:\SYSTEM\CurrentControlSet\Services\$driver"
    Write-Host "`n--- Auditing Driver: $driver ---"
    
    if (Test-Path $path) {
        $props = Get-ItemProperty $path
        Write-Host "Start value:`t" $props.Start
        Write-Host "Group:`t`t" $props.Group
        Write-Host "Type:`t`t" $props.Type
        Write-Host "ImagePath:`t" $props.ImagePath
    } else {
        Write-Host "❌ Driver '$driver' registry key not found!"
    }
}

Write-Host "`n--- OS and Integration Services Info ---"
Get-HotFix | Sort-Object InstalledOn | Select-Object Description, HotFixID, InstalledOn
(Get-WmiObject Win32_OperatingSystem).Caption

    🧠 What to Look For in Output

    For storvsc, ideally:

    Start = 0 → Loaded during boot

    Group = System

    Type = 1 (Kernel Driver)

    If Start is 3 (Manual), the driver won’t load early enough, which is a major cause of the 0x7B BSOD.

    Also, compare HotFixIDs against the new working 2012 R2 image to see if patch level might be helping it survive the new cluster environment.

  4. BryceSor 4,500 Reputation points Volunteer Moderator
    2025-07-23T22:16:41.1166667+00:00

    Did you try this using Henry Mai method,

    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.

    Why This Works

    When you add a new SCSI device, Windows:

    Detects the virtual SCSI controller (storvsc)

    Loads storvsc.sys during device discovery

    Automatically updates the registry under HKLM\SYSTEM\CurrentControlSet\Services\storvsc to mark it as boot-critical (Start=0, Group=System)

    Even though storvsc.sys is already present, older VMs sometimes lack proper boot-time flags, especially if they've never been re-initialized on newer Hyper-V hardware. This update convinces Windows to commit to using storvsc.sys during boot.

  5. Andy Bryant 20 Reputation points
    2025-07-24T10:57:09.7266667+00:00

    I have exactly the same problem as Stefan. It's all the more frustrating as I can export/import the VM's to 2016 & 2022 Hyper-V hosts and they work flawlessly. Also, if I create a vanilla 2012R2 VM, leave unpatched, go through the export/import cycle that also works. So, it looks like it's something that was introduced in a Windows Update somewhere along the line. Looking on the EFI partition there are some differences there. Ultimately, the 2012R2 VM's will be replaced but I need to get them on to the new cluster first.

    I tried adding an additional SCSI controller, but I also didn't have success.

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.