Two Azure virtual machines stopped booting unexpectedly, and the serial console shows a Windows blue-screen error for INACCESSIBLE_BOOT_DEVICE with status code 0xFFFFFFFFC0000034. I created snapshots, mounted copies of the OS disks on a recovery VM using Hyper-V, and confirmed that Windows boots normally there. However, swapping those disks back into the Azure VMs produces the same failure. I also tried repairing the EFI partition with bcdboot, redeploying the VMs, and creating new VMs from copied disks, but nothing changed. A similar disk swap fixed this problem in the past, so I'm wondering whether this could be related to an Azure host platform change or another issue with how the OS disk is being presented.
3 Answers
For faster troubleshooting, create a nested rescue environment so you can access the affected VM’s filesystem and registry directly. Microsoft’s Azure guidance for nested virtualization and VM repair walks through setting this up. If the repair becomes too time-consuming, restoring from a known-good backup may be quicker, but the disk being healthy under Hyper-V points toward an Azure platform or driver issue rather than data corruption.
This looks consistent with an Azure host platform update rather than corrupted disks. Use an Azure repair VM or the Azure VM Repair commands to attach the affected OS disk, apply the documented offline registry fix, and then restore the repaired disk to the original VM. Simply copying or swapping the disk may not help if the boot failure is caused by a platform-level storage or driver change.
The fact that the disk boots under Hyper-V suggests the Windows installation, EFI partition, and BCD are probably intact. Check whether the VM recently changed size, generation, or disk controller. Moving from SCSI to NVMe can cause this error if the NVMe storage driver isn’t enabled as a boot-start driver. In this case, you can temporarily use a SCSI-based VM size or repair the offline registry so the VM can boot with NVMe. Since both machines failed at once, it’s also worth asking Microsoft whether platform maintenance or an automatic host change occurred.
Both VMs are still using SCSI and there haven’t been any recent size changes, but this is useful to know for the future.
That was the fix in my case. The repair VM and registry change resolved the boot failure.