DISM /RestoreHealth Fails with Error 0x800f0915 on Windows 11 Insider Build 10.0.26200

Question

DISM /RestoreHealth Fails with Error 0x800f0915 on Windows 11 Insider Build 10.0.26200

Krish Mathur 40

Hello,

I am experiencing a persistent failure when trying to run the DISM repair tool on my system. The process reaches 100% and then terminates with Error: 0x800f0915 ("The repair content could not be found").

Here are my specific system details and the troubleshooting steps I have already attempted:

System Environment:

OS Build: Windows 11 Insider Preview / Development Build (Version 10.0.26200)
Architecture: x64bit
Hardware: 13th Gen Intel(R) Core(TM) i5-13450HX (2.40 GHz)

The Problem: Initially, I attempted an offline repair using a local source image path (/Source:wim:D:\sources\install.wim /LimitAccess). This failed because the tool environment (10.0.26100) detected a build mismatch against the host OS payload (10.0.26200).

However, switching to the standard online command over a stable internet connection yields the exact same failure at 100% progression: DISM.exe /Online /Cleanup-image /Restorehealth -> Error 0x800f0915

Steps Already Taken (That Did Not Work):

Switched from local source patching to standard cloud-connected online recovery.
Fully reset the Windows Update cache by stopping wuauserv, bits, cryptsvc, and renaming the SoftwareDistribution and catroot2 directories.
Attempted to deploy the local components using alternative indexing, but the component store appears deadlocked.

My dism.log shows routine background servicing actions initialized properly by applications like directxdatabaseupdater.exe and cleanmgr.exe, but any attempt to verify or heal the image component store fails natively.

Are there any known blocks or specific cab update packages causing this deployment engine mismatch on Build 26200? Any guidance on how to force-clear this component deadlock without performing a destructive clean install would be highly appreciated.

Thank you!

0 comments

2 answers

Your answer

Answer 1

Johnny55 5,150 Volunteer Moderator

Have you tried the offline from ISO using appropriate source

DISM /Offline /Cleanup-Image /RestoreHealth /source:WIM:D:\Sources\Install.wim:2 /LimitAccess

Krish Mathur 40 Reputation points

2026-08-29T11:16:05.51+00:00

Hi,

No I've not used the specific command that you mentioned. But I've used this one

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

what's the difference?
Johnny55 5,150 Reputation points Volunteer Moderator

2026-08-30T01:16:10.4366667+00:00

You use this command from an Install USB drive and change the appropriate letters for Drive and Install source version
Krish Mathur 40 Reputation points

2026-08-30T18:28:44.2366667+00:00

Hi @Johnny55 I've not tried this method. I'll give it a try! Can you guide me through it?

Answer 2

Alex-L 12,555 Microsoft External Staff Moderator

Hi Krish Mathur

Based on the troubleshooting you've already completed, I would not expect another Windows Update reset or a repeat of /RestoreHealth to provide new information.

Since you're on an Insider build (26200), could you check whether the DISM log or CBS log contains entries such as:

CBS_E_REPAIR_CONTENT_MISSING
Failed to resolve package
specific package identities or version numbers that DISM is attempting to source

The missing package identity is usually the key clue to determine whether this is component store corruption or a servicing-source mismatch.

If you can share the relevant error lines (with any personal information removed), that may help narrow down whether this is a known build-specific servicing issue or something unique to the system.

Krish Mathur 40 Reputation points

2026-08-24T06:55:50.7+00:00
Hi,

I checked both the DISM.log and CBS.log.

CBS_E_REPAIR_CONTENT_MISSING: I don't see this exact string, although DISM reports 0x800f0915 (“The repair content could not be found anywhere”).

Failed to resolve package: I don't see this exact message.

CBS.log does contain specific package identities and versions. Notably, Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.8973.1.36, Package_for_ServicingStack_9156~31bf3856ad364e35~amd64~~26100.9156.1.0, and Package_for_KB5054156~31bf3856ad364e35~amd64~~26100.6717.1.4. It also reports Package_for_KB3025096~31bf3856ad364e35~amd64~~6.4.1.0 failing with CBS_E_INVALID_PACKAGE (0x800f0805), with the x86 equivalent showing the same error.
Alex-L 12,555 Reputation points Microsoft External Staff Moderator

2026-08-25T14:07:56.6233333+00:00

Hi Krish Mathur

The new CBS.log details appear to shift the focus away from a simple "repair content missing" scenario. While the 26100 package versions listed are expected on Build 26200, the more notable finding is Package_for_KB3025096 returning CBS_E_INVALID_PACKAGE (0x800f0805) for both amd64 and x86 variants. That suggests CBS is identifying at least one package as invalid or corrupted within the component store. The next step would be to determine whether the 0x800f0915 failure occurs immediately after those package validation errors or whether additional CBS errors follow. Could you share several log entries before and after the CBS_E_INVALID_PACKAGE messages (with any personal information removed)? That may help identify whether a specific package registration or servicing issue is blocking DISM rather than a missing repair source.
Krish Mathur 40 Reputation points

2026-08-25T17:29:03.9566667+00:00
Hi,

I checked both the CBS.log and DISM.log for the relevant servicing operations.

In CBS.log, Package_for_KB3025096 is consistently failing package opening/validation with CBS_E_INVALID_PACKAGE (0x800f0805) for both architectures:

2026-08-24 09:56:26, Info CBS InternalOpenPackage failed for Package_for_KB3025096~31bf3856ad364e35~amd64~~6.4.1.0 [HRESULT = 0x800f0805 - CBS_E_INVALID_PACKAGE] 2026-08-24 09:56:26, Info CBS Failed to internally open package. [HRESULT = 0x800f0805 - CBS_E_INVALID_PACKAGE] 2026-08-24 09:56:26, Info CBS Failed to create open package. [HRESULT = 0x800f0805 - CBS_E_INVALID_PACKAGE] 2026-08-24 09:56:26, Info CBS Failed to OpenPackage using worker session [HRESULT = 0x800f0805]

Immediately afterward, CBS clears the CSI cache and starts another logging/servicing session. The x86 package then produces the same sequence:

2026-08-24 09:56:26, Info CBS InternalOpenPackage failed for Package_for_KB3025096~31bf3856ad364e35~x86~~6.4.1.0 [HRESULT = 0x800f0805 - CBS_E_INVALID_PACKAGE] 2026-08-24 09:56:26, Info CBS Failed to internally open package. [HRESULT = 0x800f0805 - CBS_E_INVALID_PACKAGE] 2026-08-24 09:56:26, Info CBS Failed to create open package. [HRESULT = 0x800f0805 - CBS_E_INVALID_PACKAGE] 2026-08-24 09:56:26, Info CBS Failed to OpenPackage using worker session [HRESULT = 0x800f0805]

The same amd64/x86 Package_for_KB3025096 failures occur again at 12:01:53. After the failures, CBS continues processing Windows Update packages such as Mapping_Package_for_KB3089226 and Package_for_KB3064238; there is no 0x800f0915 immediately following the invalid-package messages.

In DISM.log, the 0x800f0915 failure occurs during separate /RestoreHealth attempts. For example, on August 23, DISM first reports:

2026-08-23 19:42:44, Warning DISM CBS AddSource failed with HRESULT=0x8007010b!

and approximately 90 seconds later:

2026-08-23 19:44:15, Error DISM Error in operation: The repair content could not be found anywhere. (CBS HRESULT=0x800f0915) 2026-08-23 19:44:15, Error DISM Failed finalizing changes. - CDISMPackageManager::Internal_Finalize(hr:0x800f0915) 2026-08-23 19:44:15, Error DISM The repair content could not be found anywhere. The image may be corrupted. 2026-08-23 19:44:15, Error DISM Failed processing package changes with session options - CDISMPackageManager::Internal_ProcessChangesWithOptions(hr:0x800f0915) 2026-08-23 19:44:15, Error DISM Failed processing package changes with session option CbsSessionOptionRepairStoreCorruption - CDISMPackageManager::RestoreHealth(hr:0x800f0915)

The same pattern occurs in subsequent attempts: CBS AddSource fails with 0x8007010b, followed later by 0x800f0915.

Therefore, based on these two logs, the Package_for_KB3025096 CBS_E_INVALID_PACKAGE errors appear to be a separate servicing/package-registration issue rather than an error immediately preceding the 0x800f0915 failure. The DISM 0x800f0915 failures are associated with the inability to obtain repair content, and in the attempts where a source was being added, CBS AddSource itself returned 0x8007010b.

The Package_for_KB3025096 errors are still significant because CBS cannot open the package for either amd64 or x86, but I don't see evidence in these logs that the 0x800f0915 occurs directly because of that package validation failure.

Lmk if you want me to share the whole log files for both DISM and CBS, if you require further information I couldn't provide.
Alex-L 12,555 Reputation points Microsoft External Staff Moderator

2026-08-28T07:41:18.14+00:00
Hi Krish Mathur

Thanks for digging into the logs. Based on the evidence you've shared, I agree that the Package_for_KB3025096 CBS_E_INVALID_PACKAGE (0x800f0805) entries appear to be a separate servicing/package-registration issue rather than the direct trigger for the 0x800f0915 failure.

The more significant pattern is:

CBS AddSource failed with HRESULT=0x8007010b

DISM RestoreHealth failed with 0x800f0915

Since the invalid-package errors are not immediately followed by 0x800f0915, and CBS continues processing other packages afterward, the logs suggest that DISM is failing when attempting to add or access the repair source rather than when validating Package_for_KB3025096.

At this point, the most useful additional information would be:

The exact DISM /RestoreHealth command(s) used.

The AddSource log entry showing the source path being passed to CBS.

Whether the source is install.wim or install.esd, and the image index used.

That should help determine whether this is a source-resolution issue, an Insider build servicing problem, or corruption that the available repair source cannot satisfy.
Krish Mathur 40 Reputation points

2026-08-28T17:57:32.34+00:00

Hi @Alex-L ,

I checked the DISM.log for those details.

The relevant /RestoreHealth command was:

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

The same command appears in multiple attempts with only capitalization differences. The source is therefore confirmed as install.wim, located at D:\sources\install.wim.

The log does not show an explicit image index being specified, so I can't determine the WIM index from the log alone.

For the AddSource failure, the relevant entry is:

CBS AddSource failed with HRESULT=0x8007010b!

This is followed later by:

The repair content could not be found anywhere. (CBS HRESULT=0x800f0915)

The same sequence occurs in another attempt as well. The DISM log does not expose a separate, more detailed CBS source path beyond the D:\sources\install.wim path from the command line.

As from other sources and answers on the internet, I had tried downloading a Windows 11 iso and tried to fix the issues from install.wim in that iso file.