Fix Windows 11 25H2 Failed Install Error 0x800f0922

Your update reaches somewhere around 35-36%, the PC reboots, and instead of finishing you get "Something didn't go as planned. Undoing changes." Windows Update then logs error 0x800f0922 and puts the update back to where it started. You try again. Same result. Same percentage, almost to the digit, every single time.

That repeatability is the tell. A flaky error would fail at a different point each attempt. Yours doesn't. That's diagnostically useful before you even open a log file, because it rules out network hiccups and points straight at something structural — most likely a servicing step that runs at a fixed stage of the install and chokes on the same obstacle every time.

0x800f0922 translates to CBS_E_INSTALLERS_FAILED. It's a generic code meaning the "advanced installer phase" of a servicing operation failed — not a specific cause. Treat any article (including this one) that tells you there's one dominant cause with suspicion. There isn't. What there is, right now, is one documented cause for a specific May 2026 update, plus a handful of other causes that have shown up repeatedly across 2025 and 2026 servicing cycles. Work through them in the order below, starting with the one Microsoft has actually confirmed.

What 0x800f0922 actually means

CBS — the Component-Based Servicing engine — stages an update, then tries to commit it during the reboot phase. "Installers failed" means the commit step itself blew up, not that the download was bad or that your component store is generally unhealthy. That's why running DISM's health checks on an affected machine so often comes back clean: the store isn't corrupt, the commit step just hit something it couldn't get past. Knowing that distinction matters, because it means the DISM RestoreHealth ritual — which is usually the first thing every troubleshooting guide throws at any 0x800fXXXX code — isn't guaranteed to touch this particular failure at all.

Check this first: is this the May 2026 EFI partition issue?

If the failing update is KB5089549 (the May 12, 2026 cumulative security update, taking Windows 11 24H2 to build 26100.8457 and 25H2 to build 26200.8457), you're very likely looking at a known issue Microsoft confirmed on May 15, 2026. The confirming check is simple and specific — this is exactly the kind of thing you verify before touching anything else:

Open Command Prompt or PowerShell and run Get-Volume, or open Disk Management and look at the EFI System Partition (it usually has no drive letter and shows around 100–260 MB total).
Open C:\Windows\Logs\CBS\CBS.log and search for the string 800f0922, then look just above and below it for lines like SpaceCheck: Insufficient free space or ServicingBootFiles failed. Error = 0x70.

Microsoft's own release-health notes for KB5089549 describe exactly this pattern: "some devices might fail to complete installation with error code 0x800f0922. This issue occurs on devices that have limited free space on the EFI System Partition (ESP), especially if it has 10 MB or less available." The failure shows up during the restart phase at roughly 35–36% completion — which matches what you're seeing if you're in this bucket.

If your CBS.log doesn't mention the EFI System Partition or "SpaceCheck," skip this section — you're dealing with one of the other causes further down, not this one.

The good news, if you match this pattern: Microsoft has already fixed it. The May 26, 2026 update KB5089573 resolves the underlying issue. Installing that update (or anything released after it) makes the whole problem go away without registry surgery. Check Settings > Windows Update > Update history; if KB5089573 or a later cumulative update is already listed as installed and you're still failing, this isn't your issue after all — go to the next section.

If you haven't got that update yet and Windows Update keeps failing before it can even get there, there's an official interim workaround, and it's more surgical than most workarounds I've seen for stuff like this:

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

Run that from an elevated Command Prompt, restart, then retry the update. It reduces the padding percentage the installer reserves on the EFI partition before it'll proceed, which is enough to get past the space check on borderline systems. Back up the registry first — Microsoft's own guidance says as much, and for once I agree with the boilerplate, because this key sits close to boot servicing behavior.

For managed fleets, Microsoft shipped this as a Known Issue Rollback too. Consumer and unmanaged devices get it automatically (a restart speeds that up); domain-joined and Intune-managed devices need the KIR Group Policy MSI deployed and a restart to apply it. If you're patching a few hundred laptops and don't want to touch the registry key on each one, that's the route — it's reversible and it's the one Microsoft actually built for this.

If it's not the ESP issue: rule out the older, more common causes

0x800f0922 predates 25H2 by years and has shown up for reasons that have nothing to do with EFI partitions. Here's how to tell which one you've got, checked in order of how invasive the fix is.

Symptom / confirming check	Likely cause	Fix
CBS.log mentions EFI System Partition / SpaceCheck	Known KB5089549 issue (see above)	Install KB5089573+ or apply the registry workaround / KIR
.NET Framework 3.5 shows disabled in Windows Features	Update installer depends on a .NET 3.5 component that isn't present	Turn Windows features on or off > enable .NET Framework 3.5, reboot, retry
Scheduled Tasks shows a corrupted entry under `Microsoft\Windows\PI\SecureBootEncodeUEFI`	Stale scheduled task blocking a staged package from completing	Clear the corrupted task entry, clear staged packages, retry
System has MPIO (Multipath I/O) installed, error appears on storage-heavy servers	Stale MPIO registry entries conflicting with the update	Review and clean MPIO registry keys per vendor guidance, retry
App Readiness service is disabled in services.msc	Service needed to finalize app-related install steps isn't running	Set App Readiness to Manual, start it, retry
None of the above; DISM/SFC report a healthy image; error persists across manual MSU install and clean ISO upgrade	Deeper CBS state corruption not tied to a documented cause	Repair-install (see below) — don't keep retrying the same update

Run the standard repair pass — but know its limits here

This is the point where DISM and SFC belong, and it's worth doing even though it won't fix the ESP issue on its own:

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

I've watched administrators run this exact sequence, get a "no component store corruption detected" result, and conclude the tools are broken because the update still fails afterward. They're not broken. If your CBS.log points at the EFI partition or a scheduled task, a healthy component store was never the problem — the store isn't what CBS_E_INSTALLERS_FAILED is complaining about in that scenario. Run this pass to rule out plain corruption, then move on regardless of the result if your log evidence already points elsewhere.

Reset the Windows Update components

If your CBS.log doesn't clearly implicate the ESP or one of the specific causes above, a stale Windows Update cache is worth eliminating next. It's non-destructive and reversible:

net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old
net start wuauserv
net start cryptSvc
net start bits
net start msiserver

Retry the update afterward. This clears out anything Windows Update itself has cached badly; it does nothing for a genuinely corrupted servicing chain, which is why it sits above the registry-level fixes but below plain retries.

What I would not do

Don't force-uninstall unrelated older KBs as a "prerequisite test." I've seen people spend a full evening trying to manually install a KB from a year earlier because a forum post said it was a dependency. On a currently-serviced branch that update is almost certainly already superseded and won't install standalone anyway — it's a dead end, not a diagnostic step.
Don't repeatedly retry the identical update expecting a different result once you've confirmed the failure point is fixed. If CBS.log shows the same commit-phase failure three times running, a fourth attempt burns time without new information.
Don't jump to a factory reset before checking CBS.log. A reset erases the evidence that would have told you exactly what failed, and for the ESP issue specifically, it fixes nothing — the partition size is unaffected by resetting Windows.
Don't disable Secure Boot to "get past" a servicing error unless a specific, verified guide tells you to for a specific symptom. It's unrelated to 0x800f0922 in every documented case here, and it weakens your boot security for no benefit.

If you're managing more than one machine, check for the pattern before it spreads

The EFI System Partition issue doesn't announce itself until an update actually tries to write to that partition and runs out of room — which means a fleet of machines can be sitting one cumulative update away from this same failure without anyone noticing. If you administer more than a handful of Windows 11 24H2 or 25H2 devices, it's worth checking EFI free space proactively rather than waiting for the next Patch Tuesday to surface it one help-desk ticket at a time.

The EFI System Partition is easy to overlook precisely because most disk-space monitoring focuses on the C: volume, and the ESP usually has no drive letter at all. A machine can report 200 GB free on its main drive while its boot partition has single-digit megabytes left — these are unrelated pools of space, and only one of them matters for this failure. Older machines that have been through several in-place feature upgrades tend to be the most exposed, since each upgrade can leave behind boot-related files that never get cleaned out of the original 100 MB partition Windows created at factory install time.

To check without mounting the partition, PowerShell's Get-Partition and Get-Volume cmdlets can report ESP size and usage on most systems, though the exact syntax varies by disk layout (GPT vs. MBR, single disk vs. multiple). If you find machines sitting close to the 10 MB threshold Microsoft's advisory calls out, plan to address it before the next monthly update rather than after a failure — expanding an EFI partition after the fact usually means shrinking an adjacent partition and extending the ESP into the freed space, which is more involved than it sounds and isn't something to attempt across a fleet without testing on one machine first.

Last resort: repair-install or clean install

If you've matched none of the specific causes, DISM/SFC come back clean, the Windows Update reset didn't help, and CBS.log genuinely gives you nothing actionable, a repair install is the reasonable next step — not a factory reset, which throws away apps and settings unnecessarily. From Settings > System > Recovery, use "Fix problems using Windows Update > Reinstall now" if available, or run setup.exe from a freshly downloaded, current Windows 11 ISO and choose to keep apps and files. This replaces the servicing stack and component store wholesale, which resolves whatever CBS-level corruption a scan couldn't detect.

I'd only reach for a full clean install as an absolute last step, and only after confirming a repair install genuinely didn't fix it — which, for 0x800f0922 specifically, is rare. Most cases trace back to the ESP issue, a disabled feature or service, or a stale scheduled task, all of which are fixable without reinstalling anything.

Checklist before you close this out

Confirm the exact KB number failing and cross-reference it against Microsoft's resolved issues page for 25H2 before doing anything invasive.
Pull the relevant lines from CBS.log around the 800f0922 string — don't guess at the cause.
Apply the least invasive fix that matches your confirmed symptom, not the most popular one from a forum thread.
If you used the registry workaround, plan to remove it once you've installed KB5089573 or later — it was a bridge, not a permanent setting.