====== Windows Update Wiped the ESP ======

**Status:** Resolved\\
**Observed:** 2026-10-13\\
**Affects:** Dual-boot machines (Xubuntu + Windows 11)

===== Symptom =====

After a Windows update and reboot, the firmware refused every boot entry:

<code>
Unexpected return from initial read: Volume Corrupt, buffersize 1000
Failed to load image ??: Volume Corrupt
start_image() returned Volume Corrupt
</code>

No GRUB, no Windows. The rescue path was a live USB, boot menu, chainload to the disk's GRUB.

===== Cause =====

The Windows ESP partition mounted cleanly but contained zero files: the update had refreshed boot files inside Windows but wiped the ESP itself, so the firmware could not load ''bootmgfw.efi''.

Related causes on any dual-boot machine:

  * **A leftover ESP on a second disk.** An old Windows disk still carried a complete ESP with a ''bootmgfw.efi'' but a BCD pointing at a partition that no longer held Windows. Windows Startup Repair kept writing to the stale ESP, and the firmware offered it in the boot menu: which leads to a failed Automatic Repair.
  * **The Linux ESP was left dirty** because Windows had mounted and written to it (''System Volume Information'' present). The dirty bit was cleared by the boot-time ''fsck.vfat''.
  * **Fast Startup hibernation** meant the Windows kernel image was suspended mid-update.
  * **Stale NVRAM entries** pointing at two different ESPs made the BIOS list ambiguous.

===== Fix =====

Phase 1, from Linux:

  1. Map every ESP and boot entry with ''lsblk'', ''efibootmgr -v'', and journal logs. ''udisksctl mount -b'' mounts filesystems without sudo.
  2. Rebuild the empty ESP by copying the ''EFI/'' tree from the leftover ESP, then byte-patch the BCD: every embedded GUID is GPT-order and must be rewritten to the real disk and partition GUIDs. Verify by re-parsing the hive with ''regipy''.
  3. Upgrade the binaries to the current versions from ''C:\Windows\Boot\EFI'' and ''Boot\Fonts''.
  4. ''fsck'' every FAT ESP, clear Windows litter, fix the Linux ESP's partition type (it had been mistyped as basic-data), enable os-prober, re-run ''grub-install'' and ''update-grub'', delete stale NVRAM entries, and set ''BootOrder'' Linux-first.

Phase 2, inside Windows:

  1. Boot Windows via GRUB's "Windows Boot Manager (on the real ESP)" entry. The update's ''pending.xml'' processes and the desktop loads.
  2. ''powercfg /hibernate off'' kills Fast Startup. Leave it off: hybrid shutdown leaves NTFS dirty and is a classic dual-boot hazard.
  3. Mount the ESP (''mountvol S: /s'') and run ''bcdboot C:\Windows /s S: /f UEFI'': the official ESP rebuild, replacing the hand-patched BCD with a canonical one. Keep a backup of the patched hive.
  4. ''DISM /Online /Cleanup-Image /RestoreHealth'' plus ''sfc /scannow'' for good measure.

===== Lessons =====

  * Every FAT partition gets ''fsck.vfat'' after an incident like this.
  * Empty or remove the EFI tree on leftover ESPs so no tool or boot menu can ever find the stale boot files again.
  * Keep a tarball snapshot of each ESP (they are ~200 MB total) so a rebuild is a restore.
  * If it happens again: live USB -> Linux -> restore the ESP tarball, or rebuild by copying ''C:\Windows\Boot\EFI'' into the ESP and re-running ''bcdboot'' from Windows.

===== See Also =====

  * [[troubleshooting:start|Troubleshooting Log]]
  * [[guides:new_machine|New Machine Setup Playbook]]
  * [[start|Return to wiki home]]