Windows 11 Update keeps failing (0x800f0922), EFI Partition issue?

GFDyuscc

Hi everyone,

Has anyone else run into the 0x800f0922 error lately when trying to install the latest Windows 11 cumulative updates?

It's driving me crazy. My main C: drive has plenty of space (I have like 200GB+ free), but the update fails every single time it hits around 80%. I did some digging in the Event Viewer and found some threads online suggesting that the "System Reserved" partition or the EFI partition might be full and that's why it's erroring out.

Is there a safe, straightforward way to extend/clean up the EFI partition without having to reinstall Windows or use some sketchy third-party software that looks like adware? Or am I better off just waiting to see if Microsoft pushes a fix for this?

Any advice would be appreciated, I’m just trying to get my system updated and back to work...

Thanks in advance.

April4safrh

GFDyuscc Ah yes, the classic 0x800f0922. Microsoft, a multi-trillion dollar indie startup, strikes again. You have half a terabyte of free space on your NVMe, but the OS throws a tantrum because a 100MB hidden partition from 2015 is choking on a 15MB security patch. Peak software engineering. Have you tried offering a blood sacrifice to Satya Nadella?

krisliu77

Don't panic, you don't need any sketchy partition tools. The issue is usually the Windows font files taking up too much space in the EFI System Partition (ESP). Open an elevated Command Prompt (Run as Administrator) and type exactly this:

mountvol y: /s

cd EFI\Microsoft\Boot\Fonts

del *.*

(Hit Y to confirm when prompted).

Don't worry, these are just boot screen fonts for different languages. Restart your PC and run Windows Update again. 99% of the time, clearing this folder forces the update through.

User7569

krisliu77 Deleting system files is a terrible band-aid fix. The actual root cause here is that OP clearly upgraded from an improperly configured Windows 10 image, leaving them with a legacy 100MB EFI partition instead of the 500MB standard mandated by modern UEFI specs. By deleting the fonts, you're just delaying the inevitable. Next time MS pushes a large DBX revocation list, it'll fail again. The only structurally correct way to fix this is to shrink the C: drive by 500MB, create a brand new EFI partition via diskpart, format it to FAT32, and rebuild the BCD from scratch. Do it right once, or don't do it at all.

kasseen

Just leaving a comment here so I can find this later. My Dell laptop has been stuck in the exact same update loop for 3 days and I was about to wipe the whole drive. Bless you guys.

Dsirius777

To expand on what @User7569 is pointing out, the error is specifically tied to the UEFI Secure Boot DBX (revocation list) payload in recent cumulative updates. Microsoft periodically pushes out these updates (like KB5012170) to blacklist vulnerable third-party UEFI bootloaders. This list is stored directly in your motherboard's NVRAM and mirrored in the EFI partition. Over years of updates, dual-boot setups, or OEM firmware patches, the 100MB ESP gets cluttered with crash dumps and localized boot resources. The OS literally runs out of blocks to write the new security hashes.

@krisliu77's method is actually perfectly sound for most users. It clears about 15-20MB, which provides exactly the headroom the Windows Update API needs to unpack the capsule.

GFDyuscc

Dsirius777 Thank you both! But wait... if I delete those fonts as @krisliu77 suggested, will my PC still boot?! I’m terrified of touching the EFI partition because I need this rig for a massive project due on Friday. I can't afford to have a bricked, unbootable machine right now. Is @krisliu77's method actually safe?

krisliu77

GFDyuscc Yes, your PC will boot perfectly fine. The fonts in that folder are literally just for rendering text in the Windows Recovery Environment (WinRE) and the boot manager in languages like Korean, Chinese, Japanese, etc. If you delete them, the Windows bootloader just falls back to the default English font (wgl4_boot.ttf).

If you are feeling extremely paranoid, don't delete everything. Just run del chs_boot.ttf and del kor_boot.ttf, deleting just those heavy Asian language fonts alone will free up enough megabytes to let the update install.

User7569

krisliu77 I'm not "overcomplicating" it, I'm providing the correct system administration standard. Relying on undocumented fallback behaviors of the Windows Boot Manager is exactly why consumer IT is a mess. But sure, let OP patch a leaky boat with duct tape. When the 24H2 feature update completely rewrites the bootloader folder next year and restores all those font files, you'll be right back on this forum asking why 0x800f0922 is back.

kasseen

krisliu77 Wait, quick question... after I do the mountvol y: /s thing and fix the update, do I need to unmount Y:? How do I hide the partition again so I don't accidentally mess it up later?

krisliu77

kasseen The mountvol drive letter assignment is not persistent. The moment you restart your machine to apply the Windows Update, the OS will release the drive letter automatically. The EFI partition will return to its hidden, protected state upon reboot. It's a completely ephemeral mount point, so you don't need to do anything manually to unmount it.