troubleshooting:windows_update_wiped_esp
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:
Unexpected return from initial read: Volume Corrupt, buffersize 1000 Failed to load image ??: Volume Corrupt start_image() returned Volume Corrupt
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.efibut 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 Informationpresent). The dirty bit was cleared by the boot-timefsck.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.vfatafter 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\EFIinto the ESP and re-runningbcdbootfrom Windows.
See Also
troubleshooting/windows_update_wiped_esp.txt · Last modified: by 127.0.0.1
