Two Azure virtual machines stopped booting unexpectedly. The serial console shows a Windows blue-screen error with INACCESSIBLE_BOOT_DEVICE and stop code 0xC0000034. I created snapshots, mounted cloned disks on a recovery VM using Hyper-V, and confirmed that the Windows installations boot normally there. However, replacing the disks on the original Azure VMs produced the same failure. I also tried repairing the EFI partition with bcdboot, redeploying the VMs, and creating a new VM from a disk copy, but none of those steps helped. Both machines failed around the same time, and there were no recent size changes. Has anyone seen this after an Azure platform update, and what repair procedure worked?
3 Answers
For deeper troubleshooting, set up a nested rescue environment so you can inspect the affected filesystem and registry while the original VM remains offline. Microsoft support will often ask for this setup as part of the investigation. If the systems are covered by reliable backups, restoring from a known-good image may be faster, but the fact that both VMs failed together is worth having Microsoft check for platform maintenance or a host-side change.
Since the cloned disks boot under Hyper-V, the Windows installation, EFI partition, and BCD are probably intact. That points more toward how Azure is presenting the OS disk. Check the VM's disk controller type and whether the VMs were moved to a size or generation that uses NVMe instead of SCSI. If NVMe is involved, temporarily switching back to a SCSI-based size or enabling the NVMe storage driver offline may resolve the boot failure. However, you mentioned both VMs are still using SCSI and there were no recent resizing changes, so this may not be the cause in your case.
This looks consistent with an Azure host-platform change rather than corrupted disks. Use an Azure VM repair environment to attach the affected OS disk, apply the documented offline registry repair for the platform-update boot failure, and then restore the repaired disk to the original VM. Simply copying the disk or redeploying the VM will not help if the issue is caused by the host presenting the boot device differently.
That was exactly the fix. Repairing the disk through the recovery VM and applying the platform-update registry change brought the machine back online.
Both VMs still report SCSI and neither was resized recently. I didn't realize that changing VM sizes could also change the disk controller, though, so that's definitely something I'll watch for in the future.