Fleet-wide CBS component store corruption after replacing inbox curl.exe — LCU finalization blocked, UBR stuck (Windows 11 25H2 / 26200)
ENVIRONMENT:
- Windows 11 25H2, build 26200
- ~7,600 endpoints, globally distributed
- Managed via ManageEngine Endpoint Central
- Windows Update blocked via registry, redirected to internal WSUS (no direct internet egress on clients)
WHAT HAPPENED:
Some time ago I ran a custom PowerShell script (attached) across part of the fleet to replace the inbox curl.exe with a newer build downloaded from curl.se, to remediate curl CVEs. The script also touched WinSxS / servicing paths.
I now have a large number of machines where the latest LCU will not finalize. Symptoms:
- Registry/kernel UBR is stuck on an old build (e.g. 26200.6899, last KB KB5087051), while CBS reports a newer RollupFix (26100.8457) as Installed.
- cmd /c ver confirms the running kernel is the OLD build, not the one CBS claims is installed.
- Files in System32\drivers are still on the old 6899 version — the new LCU payload was never projected.
- No pending packages: Get-WindowsPackage -Online shows nothing in InstallPending.
- No reboot pending, no PendingFileRenameOperations.
SFC RESULT:
SFC found corrupt files but was unable to fix some of them.
CBS.log shows only curl.exe:
[SR] Cannot repair member file 'curl.exe' of Curl, version 10.0.26100.4768, hash mismatch
[SR] Could not reproject corrupted file curl.exe; source file in store is also corrupted
Both the live file AND the WinSxS store copy of curl.exe are the third-party 8.x build, so neither matches the manifest hash.
DISM RESULT:
DISM /Online /Cleanup-Image /ScanHealth --> "The component store is repairable."
DISM /Online /Cleanup-Image /RestoreHealth --> Error 0x800f0915 "The repair content could not be found anywhere."
WHAT I'VE ALREADY TRIED (all failed):
- RestoreHealth with /LimitAccess — fails, no matching source.
- RestoreHealth /Source: from a 25H2 ISO — the install.wim is build 26100, not 26200, so it's rejected as a source.
- Extracting curl.exe from the KB5089549 MSU / its WIM — DISM still reports 0x800f0915; the express LCU payload isn't usable as standalone repair content.
- Manually replacing curl.exe in System32, SysWOW64, AND the WinSxS folder from a "clean" machine — SFC still reports the same hash mismatch because the store manifest/catalog binding isn't updated by a manual copy.
- StartComponentCleanup /ResetBase — succeeds, but doesn't fix the curl mismatch or advance UBR.
- RestoreHealth over the internet — not possible, clients are blocked from Microsoft Update and only reach internal WSUS.
WHAT DOES WORK:
A full in-place upgrade repair using a 26200 ISO, run locally on the machine (setup.exe /auto upgrade), rebuilds the store, advances UBR, and clears the corruption.
THE PROBLEMS I NEED HELP WITH:
1. Is there any way to repair the CBS store / re-establish the correct curl.exe manifest hash offline, without a full in-place upgrade, given that clients have no internet access and the only ISO I have is build 26100 (the 26200 install.wim apparently doesn't exist as standalone media since 25H2 is enablement-based)?
2. The in-place repair works but does NOT scale to 7,600 globally-distributed machines: pushing the 8GB media via ManageEngine saturates the server, ~80% of machines lack free disk space, and some hit BSOD mid-upgrade.
3. Is there a known method to obtain valid 26200-family repair source content (the correct curl.exe + driver payloads) that DISM /Source: will accept offline?
Has anyone recovered from third-party replacement of an inbox component at fleet scale without re-imaging or full in-place upgrade on every device? Any way to get DISM to accept a targeted offline source for just the affected package?
Script that caused it is attached for reference.
Thanks.
ENVIRONMENT:
- Windows 11 25H2, build 26200
- ~7,600 endpoints, globally distributed
- Managed via ManageEngine Endpoint Central
- Windows Update blocked via registry, redirected to internal WSUS (no direct internet egress on clients)
WHAT HAPPENED:
Some time ago I ran a custom PowerShell script (attached) across part of the fleet to replace the inbox curl.exe with a newer build downloaded from curl.se, to remediate curl CVEs. The script also touched WinSxS / servicing paths.
I now have a large number of machines where the latest LCU will not finalize. Symptoms:
- Registry/kernel UBR is stuck on an old build (e.g. 26200.6899, last KB KB5087051), while CBS reports a newer RollupFix (26100.8457) as Installed.
- cmd /c ver confirms the running kernel is the OLD build, not the one CBS claims is installed.
- Files in System32\drivers are still on the old 6899 version — the new LCU payload was never projected.
- No pending packages: Get-WindowsPackage -Online shows nothing in InstallPending.
- No reboot pending, no PendingFileRenameOperations.
SFC RESULT:
SFC found corrupt files but was unable to fix some of them.
CBS.log shows only curl.exe:
[SR] Cannot repair member file 'curl.exe' of Curl, version 10.0.26100.4768, hash mismatch
[SR] Could not reproject corrupted file curl.exe; source file in store is also corrupted
Both the live file AND the WinSxS store copy of curl.exe are the third-party 8.x build, so neither matches the manifest hash.
DISM RESULT:
DISM /Online /Cleanup-Image /ScanHealth --> "The component store is repairable."
DISM /Online /Cleanup-Image /RestoreHealth --> Error 0x800f0915 "The repair content could not be found anywhere."
WHAT I'VE ALREADY TRIED (all failed):
- RestoreHealth with /LimitAccess — fails, no matching source.
- RestoreHealth /Source: from a 25H2 ISO — the install.wim is build 26100, not 26200, so it's rejected as a source.
- Extracting curl.exe from the KB5089549 MSU / its WIM — DISM still reports 0x800f0915; the express LCU payload isn't usable as standalone repair content.
- Manually replacing curl.exe in System32, SysWOW64, AND the WinSxS folder from a "clean" machine — SFC still reports the same hash mismatch because the store manifest/catalog binding isn't updated by a manual copy.
- StartComponentCleanup /ResetBase — succeeds, but doesn't fix the curl mismatch or advance UBR.
- RestoreHealth over the internet — not possible, clients are blocked from Microsoft Update and only reach internal WSUS.
WHAT DOES WORK:
A full in-place upgrade repair using a 26200 ISO, run locally on the machine (setup.exe /auto upgrade), rebuilds the store, advances UBR, and clears the corruption.
THE PROBLEMS I NEED HELP WITH:
1. Is there any way to repair the CBS store / re-establish the correct curl.exe manifest hash offline, without a full in-place upgrade, given that clients have no internet access and the only ISO I have is build 26100 (the 26200 install.wim apparently doesn't exist as standalone media since 25H2 is enablement-based)?
2. The in-place repair works but does NOT scale to 7,600 globally-distributed machines: pushing the 8GB media via ManageEngine saturates the server, ~80% of machines lack free disk space, and some hit BSOD mid-upgrade.
3. Is there a known method to obtain valid 26200-family repair source content (the correct curl.exe + driver payloads) that DISM /Source: will accept offline?
Has anyone recovered from third-party replacement of an inbox component at fleet scale without re-imaging or full in-place upgrade on every device? Any way to get DISM to accept a targeted offline source for just the affected package?
Script that caused it is attached for reference.
Thanks.
My Computer
At a glance
windows 11 25H2
- OS
- windows 11 25H2
