How I fixed 0x800f0993 / 0x80073712 on an upgraded Windows 11 25H2 PC without reinstalling

System: Windows 11 Pro N 25H2 (build 26200), en-US, x64. Upgraded in place from Windows 10 Pro N 22H2 in January 2026.

For about three months no cumulative update would install on this PC. The July and August 2026 updates each failed around ten times with 0x800f0993. After that Windows Update gave up, and the PC sat on 26200.7922 from February. Nothing I tried from the usual playbook helped, and an ISO repair install refused to keep my apps.

Short version of what fixed it: I gave Windows a clean copy of the original 24H2 files (build 26100.1742) as a repair source, then installed the update manually with DISM. I'm now on 26200.9550 with all my apps and files intact. No reinstall.

It took a few days of digging through logs, so I'm writing it up in case it saves someone else the trouble. It's only been tested on my machine, so please treat it as a field report and post back if it works (or doesn't) for you.

How I knew what I was dealing with

Microsoft acknowledged this issue in June 2026 for PCs upgraded from Windows 10 21H2/22H2 or Windows 11 23H2 to 24H2/25H2. Updates fail with 0x800f0993 (PSFX_E_REBASE_HYDRATION_CANDIDATES_MISSING) or 0x80073712 (ERROR_SXS_COMPONENT_STORE_CORRUPT). Later in my case it was 0x800f0991 (PSFX_E_MISSING_PAYLOAD_FILE).

The giveaway was in C:\Windows\Logs\CBS\CBS.log, which you can read without admin rights. It was full of lines like this:


In plain terms: since 24H2, updates only ship the differences from the original 24H2 files. To install one, Windows rolls each current file back to its 24H2 base version and then applies the update. On my upgraded PC that roll-back failed for 2,440 components. Almost all the base versions it needed were from 26100.1742 or earlier (mostly 26100.1150 and 26100.1591). That pointed me at the fix: an original 26100.1742 image contains exactly those versions.

If you only see a handful of components failing, Microsoft's own workaround (step 1 below) may be enough on its own.

What I tried first (didn't work)

• DISM /RestoreHealth, several times. It reported the store as healthy and nothing changed.
• An in-place repair from ISO. I tried the 26H2 ISO and Windows Update's own "Fix problems using Windows Update". Both hit a hard compatibility block (Setup_HostIsNewer), and "Keep personal files and apps" wasn't available (0xC1900204). Setup treats the 26100-based media as older than a 25H2 (26200) system.
• Removing the 25H2 enablement package (KB5054156) so the PC would look like 24H2 again. DISM refused: it's a permanent package (0x800f0825).
• Letting Windows Update install the update. It switched to a Setup-based install that failed three ways: 0xC1900204, then 0x8000FFFF, then 0x8007042B after the restart. Each attempt rolled back.
• Microsoft's workaround on its own (removing the stuck 26100.1742 package). Worth doing, but on its own it only changed the error to 0x80073712.

So every route that keeps your apps was blocked, apart from the one below.

What fixed it

Everything below ran in an elevated Terminal. I paused Windows Update first so it wouldn't start its own attempt alongside mine.

1. Removed the stuck package (Microsoft's workaround) and restarted:
   
   Code:

   dism /online /remove-package /packagename:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.1742.1.10

   
   
2. Got the original 24H2 ISO, build 26100.1742. Mine was en-us_windows_11_consumer_editions_version_24h2_x64_dvd_1d5fcad3.iso (5,819,484,160 bytes). I checked its SHA-256 against the published value before using it:
   
   Code:

   B56B911BF18A2CEAEB3904D87E7C770BDF92D3099599D61AC2497B91BF190B11

   Use one for your own language and edition. In sources\install.wim, Pro N was index 7 and Pro was index 6. I never ran this ISO's setup.exe; I only used its image as a source.
   
   
3. Exported my edition's image to a local folder (the ISO was mounted as E:):
   
   Code:

   dism /export-image /sourceimagefile:E:\sources\install.wim /sourceindex:7 /destinationimagefile:C:\RepairSource\install.wim /checkintegrity

   
   
4. Mounted it read-only as a folder. This was the key detail. When I pointed Windows at the .wim file itself, CBS logged Failed to create new file source sandbox process [E_ACCESSDENIED] and ignored it, whatever the file permissions. A mounted folder worked first time:
   
   Code:

   dism /mount-image /imagefile:C:\RepairSource\install.wim /index:1 /mountdir:C:\RepairSource\mount /readonly

   
   
5. Set it as the repair source. This is the registry version of the Group Policy setting "Specify settings for optional component installation and component repair":
   
   Code:

   reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing /v LocalSourcePath /t REG_EXPAND_SZ /d "C:\RepairSource\mount\Windows" /f

   
   
6. Downloaded the latest cumulative update and its checkpoint from the Microsoft Update Catalog into one folder: KB5124010 (4.47 GB) plus checkpoint KB5043080 (509 MB). Then I installed the folder:
   
   Code:

   dism /online /add-package /packagepath:C:\Updates\lcu

   "Processing 1 of 2" fails with 0x80070228 every time. Ignore it: package 2 handles both files. To check the source was picked up, CBS.log should show Addsource called ... Path: C:\RepairSource\mount\Windows with no Failed to add alternate file source after it.
   
   
7. Restarted. The install finished during the restart, and winver showed 26200.9550.

On my PC this alone wasn't quite enough, because I'm on an N edition with the Media Feature Pack. See the next part.

Extra steps for N editions (Media Feature Pack)

With only the Pro N image as a source, I still had 75 media components failing: Media Foundation, Windows Media Player, codecs and portable devices. The Pro N image simply doesn't contain them, and CBS.log said Neither forward delta nor null delta exists, Can't hydrate. Two changes got the update through:

1. I added the Pro image (index 6) as a second source. I exported and mounted it the same way, at C:\RepairSource\mountpro, and set both folders:
   
   Code:

   reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing /v LocalSourcePath /t REG_EXPAND_SZ /d "C:\RepairSource\mount\Windows;C:\RepairSource\mountpro\Windows" /f

2. I removed the Media Feature Pack before installing the update, then restarted:
   
   Code:

   dism /online /remove-capability /capabilityname:Media.MediaFeaturePack~~~~0.0.1.0

With both in place the update staged with zero hydration failures and installed.

Still unsolved: getting the Media Feature Pack back. Re-adding it installs only the 2024 base version (10.0.26100.1). Bringing it up to date needs another pass of the cumulative update, and that kept failing for me on legacy Windows Media Player files (wmp.dll, setup_wm.exe, wmpshell.dll). What got closest was installing the update offline into the mounted Pro image (dism /image:C:\RepairSource\mountpro /add-package ...) and using that as the /source for add-capability. For now I'm leaving it off until next month's update has installed cleanly. If anyone has cracked this part, I'd love to hear how.

Stopping Windows Update re-offering the same update

Even with the update installed, Windows Update kept offering it again. Its log (Get-WindowsUpdateLog) showed:


I fixed two leftovers. Only the second turned out to matter.

1. A stuck 25H2 enablement refresh. Package_for_KB5054156 26100.6717.1.4 was registered but never applied (state 32). Microsoft quietly re-released KB5054156 as revision 6717 through Windows Update only. The .msu you can download is the older 5503, and the cumulative update doesn't contain 6717. I found it in the Windows Update file set for current 25H2 builds as Windows11.0-KB5054156-x64.cab (26,156 bytes, on Microsoft's own update servers). I checked its Microsoft signature and installed it with dism /online /add-package. Worth doing, but dirty stayed True.

2. The re-offer flag — this was the real cause. At every scan Windows Update sends ReofferUpdate=1 to Microsoft's server, which then offers the current update again as a repair. It reads that from:


It was left over from my earlier repair attempts. Windows' servicing stack itself said no repair was needed (AutoRepairNeeded = 0, LCUReoffer = 0 under ...\Component Based Servicing). The key is protected: only TrustedInstaller can write it. So I backed it up with reg export, took ownership temporarily, set ReofferUpdate to 0, and then put the original owner (SYSTEM) and permissions back exactly. The next scan reported dirty=False, and the re-offer was gone.

A warning if you do this: taking ownership of the parent Update key and granting rights recursively can leave Administrators and ALL APPLICATION PACKAGES with full control of the whole tree. Check the permissions afterwards and restore them.

Clean-up and caveats

Once the update was in and the PC had restarted, I removed the mounts and the repair source setting:


If an unmount gets interrupted, dism /cleanup-wim sorts it out. I'm keeping the exported images and the ISO until a couple of monthly updates have installed normally. If the errors come back, the same steps should work again.

A few honest caveats:

• This is one PC. It worked for me, but I can't promise it works for everyone.
• Use an image you can verify. Get the 26100.1742 ISO from a Visual Studio subscription or another source you trust, and check its hash. Windows checks every file it takes from a repair source against its own signed manifests, but don't run that ISO's setup.
• Most of this is low-risk: read-only mounts, a setting you remove afterwards, and DISM installs that roll back cleanly when they fail. The registry flag change is the one step that touches something protected, so back it up first.
• Not proven yet: that next month's update installs through Windows Update normally.

If you're stuck in the same loop, I hope this helps.

Good news, if you want to switch to 26H2 (build 26300.9550) all you need is to install the 26H2 Enablement Package and restart the computer. It is just an Enablement Package, not a full upgrade, so it doesn't check compatibility and it doesn't make any major changes to the system files risking trouble. Moreover, if you change your mind, you can just uninstall it and return to 25H2.

Find it here:


For a standard Intel/AMD CPU system you need the x64 update.