Windows VM Won't Boot After the Proxmox 9 Upgrade? Read the Error Before You Reinstall (2026)

By LK Wood IV · Published 2026-08-25 · ~9 min read · St. Louis County, MO

The host reboot after a Proxmox VE 8-to-9 upgrade has a particular quiet moment. The console comes back. The containers go green. The Debian guests come up. And the one Windows VM lands on a blue recovery screen instead of a login: “Your PC/Device needs to be repaired… 0xc0000001. An unexpected error has occurred.”

Nothing inside Windows changed. That is the tell.

A guest that booted fine before the upgrade and refuses after it is reporting a change in the layer underneath — firmware type, disk controller, boot entries, or the host kernel itself. Which layer depends on what the failure looks like, and the failure tells you if you read it before touching anything. Reinstalling Windows, the move half the panic threads reach for, is the one response that cannot be right: it destroys a healthy guest to address a host-side change, and in the worst case reinstalls onto the exact configuration that triggers the bug.

I maintain the upgrade guide this page pairs with, and I want to be straight about sourcing: I have not reproduced this failure on a lab host. Every fix below instead names the community thread or vendor document that confirmed it, chiefly the Proxmox forum thread where the 0xc0000001 signature was worked to a confirmed fix, and the r/Proxmox reports that match it. Where a step was tried in those threads and did not work, I say that too. That list of dead ends is half the value here.

What the failure looks like

Four screens, four different problems. Match yours before running a single command.

One honest caveat on ordering. Nobody has failure-rate telemetry for this, me included, so the ladder below is ordered by cost of the test, cheapest and most reversible first. Anyone who tells you which of these causes is “most common” is guessing.

The 30-second configuration checks

Before changing anything, pull the VM’s config on the host and read five lines:

qm config <vmid>

• bios: is ovmf or seabios (absent means SeaBIOS, the default). This decides which fork you are in. A UEFI Windows install needs ovmf; if this line says otherwise, something rewrote your config (a restore, a migration script, a manual edit).
• efidisk0: must exist on every OVMF VM. An OVMF guest with no EFI disk has nowhere to store boot entries, and boot-entry loss is exactly the Fork B symptom.
• machine: shows whether your virtual hardware moved. Windows VMs get their QEMU machine version pinned at creation (pc-q35-8.1, say) precisely because, in the words of the Proxmox reference documentation, “Windows is sensitive to changes in the virtual hardware.” If yours shows a pinned version, the upgrade did not move it. If it shows latest or a bare q35, the upgrade silently jumped your virtual hardware to QEMU 11’s newest revision.
• scsihw: and the boot disk’s bus (scsi0: / sata0: / ide0:) matter for Step 4, so note what they are. If Windows last booted from a scsi0 disk and the disk now hangs off ide0, that mismatch is your Fork C.
• ostype: should be win11 for the Windows 11 / Server 2022 / Server 2025 generation and win10 for Windows 10 / Server 2016 / 2019 — the qm.conf reference defines win11 as “Microsoft Windows 11/2022/2025” and win10 as “10/2016/2019”, and Server 2022 on the win10 setting is a common leftover. The forum thread’s reboot-loop case (Fork D) was resolved by exactly this one-line correction on a UEFI Windows 11 guest, so check it before deeper surgery.

Five lines, under a minute, and you have usually already picked your fork.

Why Proxmox 9 breaks Windows VMs and leaves Linux guests alone

The 8-to-9 upgrade is not one change. Landing on the current 9.2 means Debian 13.5, QEMU 11.0, and the Linux 7.0 kernel all arrive at once, and each is a layer a guest boots through.

The kernel is the loud one right now. Within days of kernel 7.0 reaching 9.2 hosts, the Proxmox forum thread above collected Windows Server guests failing with 0xc0000001 across three hosts with different storage back-ends — all SeaBIOS, all MBR boot disks, all fine again the moment the host booted the previous 6.17.13 kernel. The thread’s participants converged on a kernel regression affecting SeaBIOS/MBR guests specifically; no OVMF guest shows up among the failures, and one commenter reported his OVMF guests running fine on the same PVE version. As of this writing there is no Proxmox staff reply in that thread, so treat the diagnosis as strong community evidence rather than an official statement. The fix pattern it produced, though, was confirmed by two separate users in the linked discussion, which is more than most boot-failure folklore ever gets.

QEMU 11 is the quiet one. Windows VMs carry a pinned machine version for stability, so most survive the QEMU jump untouched. The r/Proxmox comments on the same failure confirm the corollary: rolling the machine version back (pc-q35-8.0) did not fix the 0xc0000001 failure. Machine versions matter at the margins. Guests set to latest get a large hardware jump, and QEMU’s own policy now removes machine versions from upstream after six years, so a config pinned to something ancient will eventually stop starting at all. Worth reading once and then not obsessing over.

And Windows itself is simply the fussy tenant. It refuses to boot from a disk bus it was not prepared for (the documented INACCESSIBLE BOOT DEVICE failure in Step 4), its Boot Configuration Data store assumes the firmware handoff never changes shape, and a BitLocker-protected guest treats TPM changes as a reason to demand its recovery key. Linux guests and containers re-enumerate most of this on every boot and move on. That asymmetry (host change, Windows-only casualty) is the entire diagnostic frame of this page.

The fix ladder, least invasive first

Each step says what it does, when it is the right one, and how to undo it.

Step 1: update the host before you change the VM

The bug you hit may already be fixed. One commenter in the boot-menu thread reports a similar failure (his word — similar, not identical) that cleared up with a later Proxmox kernel or qemu-server update. Check and apply point updates on the host, reboot, and re-test the VM before touching its config.

apt update && apt dist-upgrade

When it is the one. Always first. It costs a host reboot and nothing else, and every later step benefits from being on current packages. How to revert. Nothing to revert.

Step 2: boot the previous kernel — the confirmed 0xc0000001 fix

This is Fork A’s move, and it doubles as its diagnostic. Proxmox keeps the previous kernel installed; proxmox-boot-tool can select it, and the selection works on both systemd-boot and GRUB hosts:

proxmox-boot-tool kernel list
proxmox-boot-tool kernel pin 6.17.13-13-pve --next-boot
reboot

--next-boot applies for one boot only. If the Windows VM comes up normally on 6.17 (as it did for the reporters in the forum thread, whose guests failed on kernel 7.0.6-2 and booted on 6.17.13-13), you have confirmed the kernel fork in one reboot with zero permanent changes. Then make it stick until you are ready for Step 5:

proxmox-boot-tool kernel pin 6.17.13-13-pve

The cost is real, and I want it on the page: a pinned host is not running the kernel line that receives current fixes. You are trading an unbootable guest for a slightly stale host, which is the right trade this week and the wrong one forever. Record the pin somewhere you will see it, re-test on each new point release, and proxmox-boot-tool kernel unpin the day the current kernel boots your guests again. If you run GPU passthrough, you may already know this dance. Kernel pinning is the same escape hatch the passthrough community reaches for when a new kernel breaks VFIO.

Step 3: repair the UEFI boot path — when manual boot works

Fork B has the friendliest tell in the whole taxonomy: press Esc at the VM’s firmware splash, pick the Windows disk by hand, and it boots perfectly. The OS is fine. Only the automatic handoff is broken. Three sub-fixes, in cost order:

Boot order first. VM → Options → Boot Order. After upgrades and restores this list can end up pointing at the wrong device or de-selecting the boot disk entirely. Fix, cold-boot (full stop/start, not a guest reboot), done.

Get the boot disk off IDE. In the r/Proxmox thread where two of four Server 2022 guests dropped to the boot menu after a 9.2.9 update, the affected disks hung off IDE, and a commenter identified the mechanism as the BCD not supporting IDE EFI boot chaining, which is exactly why manual selection worked while auto-boot failed. Moving the boot disk to SCSI resolved it, with one caveat the reporter hit honestly — Windows needed a Safe Mode boot to bind the storage driver on first start after the move. Do it in Step 4’s driver-safe order rather than a blind detach/re-attach.

Rebuild the EFI vars and TPM state. This is the heavier variant, reported working across a fleet. Detach and delete the VM’s EFI disk and TPM state, re-add both fresh, and — the detail that made it stick — reset the TPM to factory keys before the first boot. The thread’s reporter found a plain rebuild did not stick (Windows booted once, then the failure returned on the next reboot); the commenter who recovered roughly two dozen VMs adds the factory-key reset before first boot as the step that makes it hold. Nobody in-thread tested the two variants side by side. Before you touch either disk, have your BitLocker recovery key in hand. Clearing the TPM is on Microsoft’s own list of events that put a BitLocker device into recovery, so expect the recovery prompt at next boot — and without the key that screen is a lockout.

When it is the one. The manual-selection tell, or an OVMF guest whose efidisk0 is missing or damaged. How to revert. Boot order and controller moves reverse in the GUI; a deleted EFI/TPM disk does not come back, which is why the recovery key comes first.

Step 4: swap the disk controller without losing boot

Fork C is the one you can give yourself mid-troubleshoot, and the shape of it is worth thirty seconds. When the boot disk arrives on a bus Windows has not booted from before, Windows can fail before it is up — the standard explanation is that boot-critical storage drivers are only armed once Windows has actually used them. Whatever the exact mechanism, Proxmox’s driver documentation states the outcome flatly: installing the VirtIO drivers and switching the boot disk in one step “will result in a blue screen, claiming an ‘INACCESSIBLE BOOT DEVICE’.”

So the swap is a two-boot procedure, per that same document:

1. Load the virtio-win ISO in the VM’s CD drive and attach a small temporary disk (1 GB) on the VirtIO SCSI bus.
2. Boot Windows, install the drivers, and wait until the temp disk shows up in Disk Management. That appearance is the proof the driver is genuinely bound.
3. Shut down. Remove the temporary disk, then detach the boot disk and re-attach it on the target bus (SCSI on the VirtIO SCSI single controller is what Proxmox’s Windows best-practices guide has you pick).
4. Fix Options → Boot Order to point back at the boot disk, boot, and take the ISO out once you are up.

If you are already stuck on the blue screen because the bus changed underneath you, put the disk back on the old bus first. That is the one-minute undo (detach, re-attach on the previous bus type, restore boot order), and Windows boots because the old driver is still the one it trusts. Then do the procedure above properly. And a warning from the founding thread worth repeating: controller shuffling was tried against Fork A’s 0xc0000001 and did nothing — VirtIO SCSI single versus VirtIO SCSI, iothread on or off, none of it moved that failure. Controller surgery fixes controller problems. It does not fix kernel problems.

Step 5: convert SeaBIOS/MBR to UEFI — the permanent Fork A fix

The kernel pin in Step 2 avoids the wedge; this removes it. The wedge condition is SeaBIOS firmware booting an MBR disk, so the reporter converted his Windows guests to UEFI/GPT and ran them on kernel 7.0 without issue — “everything runs now fine,” in his words in the r/Proxmox comments after migrating his whole fleet — and a second user in the same discussion, after converting his Server 2025 guest the same way, closed with “everything is ok.”

Inside Windows, validate before you commit. mbr2gpt refuses ineligible layouts (more than three primary partitions, extended/logical partitions present), and per Microsoft’s documentation BitLocker protection must be suspended first:

mbr2gpt /validate /allowFullOS
mbr2gpt /convert /allowFullOS

The conversion rewrites the partition table in place, creates the EFI system partition, and migrates the BCD. Data stays, but there is no un-convert command, so this is a tested-backup-first operation. Then shut down and flip the Proxmox side to match, because a GPT disk under SeaBIOS boots nothing:

1. Hardware → Add → EFI Disk.
2. Options (or Hardware → BIOS) → change SeaBIOS to OVMF (UEFI).
3. Re-check Boot Order, cold-start, and expect one trip through the firmware menu if the fresh EFI vars need the Windows Boot Manager entry selected once.

When it is the one. Fork A guests you want back on the current kernel line, done one VM at a time in a maintenance window. I would not run it on a domain controller before its backup restore had been tested. The tool is fine; “no undo command” plus “untested backup” is the combination you only get burned by once. How to revert. You do not; you restore.

Step 6: restore the pre-upgrade backup

If you took the tested backup the upgrade guide insists on, the calm exit was available the whole time. Restore the guest as it was, pin the kernel if the restored VM still hits Fork A, and schedule the UEFI conversion for a quieter week. A restore also cleanly unwinds a troubleshooting session that changed five things: restored config, restored disk, known state.

If you did not take one, let this be the page that converts you. Every fork above is survivable with a backup and console access; several are miserable without. The 3-2-1 setup takes an evening.

What not to do

• Do not reinstall Windows. Wrong layer. The guest is healthy; the platform moved. In the kernel-regression case a fresh install onto SeaBIOS/MBR can hit the same wall on first boot.
• Do not detach and re-attach disks “to see if it helps.” Every detach can drop the disk from the boot order, stacking a Fork B problem on top of whatever you had. Config changes here should be single, deliberate, and written down.
• Do not upgrade the rest of the cluster while node one’s Windows guests are down. The failure travels with the kernel, and so does your blast radius. Diagnose on one node; pin or fix before the next node moves.
• Do not run fixes from the wrong fork. The reporter’s threads already burned the hours for you: against 0xc0000001, controller swaps did nothing, iothread toggles did nothing, machine-version rollback to pc-q35-8.0 did nothing, and a QEMU 10-vs-11 switch did nothing. The kernel pin worked. The UEFI conversion worked. Match the signature, run its fix.

Prevent it on the next node

Everything above compresses into three pre-upgrade lines for whatever you upgrade next:

1. qm config every Windows guest and record bios / machine / boot bus / ostype. Thirty seconds per VM, and it turns any post-upgrade surprise into a diff instead of a mystery.
2. Convert SeaBIOS/MBR Windows guests to UEFI before the host jumps to kernel 7.0, on your schedule instead of during an outage.
3. Take the tested backup. Then run the full pre-flight checklist (pve8to9, NIC pinning, console access) and upgrade knowing the escape hatches on this page exist but expecting not to need them.

The upgrade itself is routine. The preparation is the whole job — and for Windows guests specifically, the preparation now includes knowing which firmware they boot with.

Sources

• Proxmox forum — “Windows Server 2025 fails to boot after PVE 9.2 / Linux 7.0 Kernel upgrade” (the 0xc0000001 thread; kernel versions, controller/iothread and QEMU 10-vs-11 non-fixes, the ostype win10→win11 boot-loop fix): https://forum.proxmox.com/threads/windows-server-2025-fails-to-boot-after-pve-9-2-linux-7-0-kernel-upgrade.183958/
• r/Proxmox — the same failure’s discussion thread (three hosts, SeaBIOS/MBR/VirtIO SCSI, broken 7.0.6-2-pve vs working 6.17.13-13-pve; machine-version-rollback non-fix; both UEFI-conversion confirmations): https://www.reddit.com/r/Proxmox/comments/1trztwg/
• r/Proxmox — Server 2022 guests dropping to the boot menu after 9.2.9, manual disk selection working; IDE/EFI boot chaining diagnosis, EFI+TPM rebuild fix, the similar-failure-fixed-by-update report: https://www.reddit.com/r/Proxmox/comments/1vgbstt/
• Proxmox wiki — Paravirtualized Block Drivers for Windows (the temporary-disk procedure and the INACCESSIBLE BOOT DEVICE warning, quoted verbatim): https://pve.proxmox.com/wiki/Paravirtualized_Block_Drivers_for_Windows
• Proxmox wiki — Windows 10 guest best practices (SCSI bus on the VirtIO SCSI single controller for Windows guests): https://pve.proxmox.com/wiki/Windows_10_guest_best_practices
• Proxmox wiki — Host Bootloader (proxmox-boot-tool kernel list / pin / –next-boot / unpin): https://pve.proxmox.com/wiki/Host_Bootloader
• Proxmox VE reference documentation — QEMU/KVM Virtual Machines (Windows machine-version pinning, machine-version removal policy): https://pve.proxmox.com/pve-docs/chapter-qm.html; ostype value definitions (win10 = 10/2016/2019, win11 = 11/2022/2025): https://pve.proxmox.com/pve-docs/qm.conf.5.html
• Microsoft Learn — MBR2GPT (validate/convert syntax, /allowFullOS, disk prerequisites, BitLocker suspension, UEFI firmware requirement): https://learn.microsoft.com/en-us/windows/deployment/mbr-to-gpt
• Microsoft Learn — BitLocker recovery overview (“Turning off, disabling, deactivating, or clearing the TPM” as a recovery trigger): https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/recovery-overview
• Proxmox VE roadmap — 9.2 release contents (Debian 13.5, kernel 7.0, QEMU 11.0), verified 2026-08-25: https://pve.proxmox.com/wiki/Roadmap