EFI System Partition Full? Fix Failed Windows Updates

Windows Update keeps failing with error 0x800f0922 or "we couldn't update the system reserved partition"? The culprit is usually a full EFI System Partition — a ~100 MB boot partition that fills up with leftover fonts and OEM files. Free about 15 MB by deleting the unused boot fonts, then retry the update. Here's how to do it safely, and how to stop it recurring.

Why a full EFI System Partition breaks Windows Update

The EFI System Partition (ESP) is the small FAT32 partition your firmware reads first at boot. On a typical UEFI/GPT Windows install it's around 100 MB, and it holds the bootloader, the Boot Configuration Data (BCD) store, and boot-time fonts. During some cumulative and feature updates, Windows has to write new boot files there. If there's no room, the update rolls back.

The maddening part is how healthy the machine looks. Your C: drive can have 400 GB free and Settings will report zero storage pressure, because the partition that's actually full is hidden and has no drive letter. I've hit this most often on OEM laptops where the vendor parks BIOS-recovery images on the ESP, and on machines that have been imaged and upgraded for years.

The error you'll usually see is 0x800f0922 — or the message "We couldn't update the system reserved partition," or 0xc1900104 during a version upgrade. Microsoft's guidance says you typically only need to free 15 MB for an upgrade, or 13 MB for a Windows 10 update. A few unused boot fonts usually get you there.

This isn't theoretical. In May 2026, Microsoft confirmed that the KB5089549 security update fails on some Windows 11 24H2 and 25H2 PCs that have 10 MB or less free on the ESP, rolling back at roughly 35–36% during the reboot phase with 0x800f0922. The CBS log (C:\Windows\Logs\CBS\CBS.log) gives it away:

ServicingBootFiles failed. Error = 0x70
SpaceCheck: <value> used by third-party/OEM files outside of Microsoft boot directories

0x800f0922 vs 0x80073712: fix the right thing first

Before you touch a partition, confirm the error actually points at one. Plenty of guides lump 0x80073712 in with "partition full" advice, and that's wrong. 0x80073712 is ERROR_SXS_COMPONENT_STORE_CORRUPT — your component store (WinSxS) is missing or has damaged manifests. Freeing ESP space won't touch it; DISM and SFC will. Here's the quick map:

Error code	What it usually means	The actual fix
0x800f0922	Not enough free space on the ESP / System Reserved Partition (or a VPN/proxy blocking Microsoft's update servers)	Free ~13–15 MB on the ESP; disable any VPN during the update
0xc1900104	Same ESP/SRP space block, seen during feature/version upgrades	Free space on the ESP, then re-run setup
0x80073712	Component store (WinSxS) corruption — missing/damaged manifests	DISM /RestoreHealth, then sfc /scannow — not an ESP problem
0x800f0993	Component store again (differential-update data missing); common after upgrading older builds to 24H2/25H2	DISM /RestoreHealth, or an in-place repair upgrade

If you're seeing 0x80073712 or 0x800f0993, skip the partition steps and run this from an elevated Command Prompt:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

If DISM can't reach Windows Update, point it at a matching install image instead:

DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:X:\sources\install.wim:1 /LimitAccess

Everything below is for the space-related codes (0x800f0922 / 0xc1900104).

How to check how full your EFI partition actually is

First, find out whether your disk is GPT or MBR, because the cleanup differs. Open Disk Management (diskmgmt.msc), right-click the disk — not the partition — choose Properties, open the Volumes tab, and read "Partition style." Or from an elevated prompt:

diskpart
list disk
exit

An asterisk in the "Gpt" column means GPT. Modern Windows 11 machines are almost always GPT/UEFI.

Don't trust Disk Management's free-space figure for the ESP. It frequently shows these hidden system and recovery partitions as 100% free even when they're packed, which sends people chasing the wrong fix. Mount the partition and look for yourself (GPT):

mountvol y: /s
dir y:\
fsutil volume diskfree y:
powershell -Command "Get-ChildItem Y:\ -Recurse -File | Sort-Object Length -Descending | Select-Object FullName, Length -First 10"

The fsutil line gives you exact free bytes; the PowerShell one-liner surfaces the biggest files so you know what's eating the space — usually CJK boot fonts and OEM firmware images.

How to free up EFI System Partition space (the official method)

Microsoft's supported fix is deleting the unused boot fonts. On a single-language English install, the boot manager doesn't need the Chinese, Japanese, and Korean fonts (chs_boot.ttf, cht_boot.ttf, jpn_boot.ttf, kor_boot.ttf), and they're the largest files in that folder. On a GPT disk, from an elevated Command Prompt:

mountvol y: /s
y:
cd EFI\Microsoft\Boot\Fonts
del *.*
cd \
mountvol y: /d

That mounts the ESP as Y:, deletes the fonts, and unmounts it. Reboot and retry the update. The only thing you lose is localized text rendering on the early boot and recovery screens — fine for most setups, worth knowing if you actually boot in those languages.

On an MBR disk the same fonts live in Boot\Fonts, but they're owned by SYSTEM, so you have to take ownership and grant yourself rights before you can delete them, then restore permissions afterward — the takeown / icacls dance. Follow Microsoft's exact sequence in the official "system reserved partition" article rather than improvising, because botched ACLs on the SRP can stop the machine booting.

If the fonts aren't enough, the other big offender is OEM firmware. Vendors drop BIOS update and recovery images on the ESP: \EFI\Dell\Bios\Recovery on Dell, \EFI\HP\BIOS (or \EFI\HP\DEVFW) on HP, \EFI\Lenovo on Lenovo. Move them off rather than delete them, so you can restore them if needed:

md C:\ESP-OEM-backup
move Y:\EFI\Dell\Bios\Recovery\*.* C:\ESP-OEM-backup\

Heads up: this can disable the vendor's firmware-recovery path until you move the files back, and some OEMs repopulate the ESP on the next feature update — so you may be doing this again.

The KB5089549 registry workaround (EspPaddingPercent)

For the specific May 2026 failure, Microsoft published a registry workaround that relaxes the padding Windows reserves in the ESP while servicing boot files. Run this from an elevated Command Prompt, then reboot and retry the update:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Bfsvc" /v EspPaddingPercent /t REG_DWORD /d 0 /f

One catch worth flagging: the command as originally posted on Microsoft's page had the closing quote in the wrong place (it wrapped the whole line), which produces a malformed key. The version above closes the quote right after Bfsvc — use that one. And remember what it does: it doesn't create space, it changes the rule Windows applies to the space you already have. Treat it as a targeted fix, not routine maintenance.

Microsoft also shipped a Known Issue Rollback (KIR) that reached most consumer and unmanaged devices automatically, so a reboot and a fresh check for updates may clear it with no registry edit at all. A permanent fix landed in a later June 2026 cumulative update, and Windows Server editions weren't affected by this particular issue. Details are on the Windows release health page.

How do I permanently make the EFI partition bigger?

Deleting fonts buys you a few megabytes; it doesn't fix a partition that was undersized to begin with. The honest answer: don't try to enlarge the ESP with Disk Management or diskpart. They can only extend a volume into unallocated space immediately to its right, and the ESP sits at the front of the disk with C: right behind it — there's nowhere to grow. Don't waste an afternoon fighting it.

You have two real options. The low-effort one is a partition tool that can move and resize: MiniTool Partition Wizard, AOMEI Partition Assistant, EaseUS Partition Master, or GParted from a live USB. Shrink C:, shift it to the right, and grow the ESP to 250–300 MB. Image the disk first — moving the system partition is exactly when things go wrong.

The hands-on one is to shrink C:, delete the cramped ESP, create a new larger FAT32 ESP, then rewrite the boot files:

bcdboot C:\Windows /s Y: /f UEFI

Only do that if you're comfortable rebuilding the boot configuration and you have a tested backup. A wrong disk number here turns a failed update into a recovery job. For most people, the GUI partition tool is the better call.

Frequently asked questions

Is it safe to delete the font files in the EFI partition?

Yes — for the boot fonts in EFI\Microsoft\Boot\Fonts specifically. Windows recreates what it needs, and the rest only affect text rendering on early boot and recovery screens. Deleting them is Microsoft's own documented fix. Don't delete anything outside that Fonts folder.

How big should the EFI System Partition be?

Older installs often have a 100 MB ESP, which is tight for current Windows 11 servicing. If you're repartitioning anyway, 250–300 MB gives comfortable headroom for future boot-file updates.

Why does Disk Management show my EFI partition as 100% free when updates fail for space?

Disk Management doesn't report usage reliably for hidden system and recovery partitions. Mount the ESP with mountvol y: /s and run fsutil volume diskfree y: or dir y:\ to see the real numbers.

Does error 0x80073712 mean my EFI partition is full?

No. 0x80073712 is component-store corruption (ERROR_SXS_COMPONENT_STORE_CORRUPT). Fix it with DISM /Online /Cleanup-Image /RestoreHealth followed by sfc /scannow. The space-related codes are 0x800f0922 and 0xc1900104.

Do I have to do this every time Windows updates?

Sometimes. If your ESP is only slightly small, freeing the fonts once may hold for a while. If an OEM keeps writing firmware images there, or the partition is genuinely too small, expect repeats until you resize it.