Solved repair the systems DISM

@garlin I removed them and currently have no issues except RestoreHealth taking an hour to find nothing wrong.

This is Gemini's response to my Question: Where are Corruption Errors Tracked in the Registry.

In Windows 11, component and system servicing corruption errors are managed by the Component-Based Servicing (CBS) engine and tracked across specific registry keys, cache structures, and log files.

1. Where Corruption Errors Are Tracked in the Registry​

Windows tracks component servicing states under the primary key:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing
Within this key, corruption details and package states reside in several specific subkeys:

• Package State tracking (...\Component Based Servicing\Packages):
  Each installed update, Feature-on-Demand, or package has its own key. Corruption often manifests when the CurrentState value is left in an incomplete or mismatched transition state (e.g., stuck in InstallPending or Staging state instead of Installed).
• Applicability & Evaluation Cache (...\Component Based Servicing\ApplicabilityEvaluationCache):
  Holds cached evaluation metadata for Windows updates. Stale or corrupt registry entries here can cause servicing failures.
• Reboot/Pending State tracking (...\Component Based Servicing\RebootPending or SessionsPending):
  Tracks unfinished operations that failed mid-execution.
• Side-by-Side Component Store Metadata (HKLM\COMPONENTS):
  This registry hive (stored physically in C:\Windows\System32\config\COMPONENTS) stores the manifest maps for the Component Store (WinSxS). Corrupted component mappings or missing manifests are registered here.

Beyond the Registry: Log Files​

While flags and package states are stored in the registry, specific details about missing files or corrupted manifests are written directly to log files:

• C:\Windows\Logs\CBS\CBS.log (Full servicing and repair details logged by CBS and SFC).
• C:\Windows\Logs\DISM\dism.log (Execution log for DISM servicing operations).

2. Does DISM Update the Status if it Runs Clean?​

Yes. DISM actively updates both system status records and registry flags when run cleanly:

1. Clearing Pending/Failed Flags: When DISM /Online /Cleanup-Image /RestoreHealth completes successfully, DISM clears repair flags and resolves stale component transaction states in the registry.
2. Updating the Component Store State: Successful repairs refresh the component metadata in HKLM\COMPONENTS and update the status of repaired package manifests.
3. Health Check Flags: Running /ScanHealth or /CheckHealth queries the servicing state. If DISM repairs the underlying issues, subsequent runs of /CheckHealth will report:
   

   "No component store corruption detected."

   Click to expand...

4. Log Verification: DISM writes a summary entry to CBS.log reporting total detected corruptions vs. total repaired corruptions (e.g., Total Detected Corruption: X, Total Repaired Corruption: X).

How to Verify the Repair​

To confirm that DISM successfully cleared corruption flags, run the quick health check in Terminal or Command Prompt (Admin):
DOS

dism /online /cleanup-image /checkhealth

To verify that active system files are also clean, follow up DISM with the System File Checker:
DOS

sfc /scannow

• Success Verification: SFC should output "Windows Resource Protection did not find any integrity violations" or "found corrupt files and successfully repaired them."

Now sure what use this information is, looking at those registry keys it sure doesn't seem that anyone but Microsoft is going to fix any corruption there.

gunrunnerjohn said:

Now sure what use this information is, looking at those registry keys it sure doesn't seem that anyone but Microsoft is going to fix any corruption there.

Click to expand...

If you run DISM /Online /Cleanup-Image /CheckHealth those are the registry keys Windows checks to verify if you have any corruption in your component store...

Dism /Online / Cleanup-Image /RestoreHealth will change the registry flags if it manages to correct all your problems.

Asus272 said:

If you run DISM /Online /Cleanup-Image /CheckHealth those are the registry keys Windows checks to verify if you have any corruption in your component store...

Click to expand...

I got that, but I still don't see how I'd ever track down what is causing the issues.

A thought did occur to me, I wonder if you could transplant the keys from and identical version installation that doesn't have any DISM errors? One would presume they'd have to be pretty similar.

i have also found this to fix a corrupt Component Store. this is the link

Reset Windows Update components
Run each one in a Administrator Command Prompt, one line at a time ..

net stop wuauserv

Click to expand...

net stop cryptsvc

Click to expand...

net stop bits

Click to expand...

net stop msiserver

Click to expand...

ren C:\Windows\SoftwareDistribution SoftwareDistribution.old

Click to expand...

ren C:\Windows\System32\catroot2 catroot2.old

Click to expand...

net start wuauserv

Click to expand...

net start cryptsvc

Click to expand...

net start bits

Click to expand...

net start msiserver

Click to expand...

best of luck Steve ..

XxXxX said:

i have also found this to fix a corrupt Component Store. this is the link

Fix Corrupted Component Store.md

GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

Reset Windows Update components
Run each one in a Administrator Command Prompt, one line at a time ..












best of luck Steve ..

Click to expand...

Why one at a time????

XxXxX said:

i have also found this to fix a corrupt Component Store. this is the link

Fix Corrupted Component Store.md

GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

Click to expand...

These are the normal (and long institutionalized) instructions to stop WU and clear any queued updates which are uninstallable.
They won't fix DISM errors for metadata...

XxXxX said:

i have also found this to fix a corrupt Component Store. this is the link

Fix Corrupted Component Store.md

GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

Reset Windows Update components
Run each one in a Administrator Command Prompt, one line at a time ..

best of luck Steve ..

Click to expand...

I doubt that's going to fix anything. If you look at the page referenced, it's pretty clear they're trying to fix the component store, but many of us have long since concluded that the component store is fine and it's something in the registry that is really the problem. That same page says this is the "final" solution if all else fails, I've tried this several times.

I believe them, it fixed every corrupted file, but it's not the component store files that are corrupted!



I see that @garlin beat me to it.

@kelper Have you looked in this log? Does it say anything useful?

1. Log Verification: DISM writes a summary entry to CBS.log reporting total detected corruptions vs. total repaired corruptions (e.g., Total Detected Corruption: X, Total Repaired Corruption: X).

Yes. No.

kelper said:

Yes. No.

Click to expand...

That's what I expected....

kelper said:
But RestoreHealth still took an hour.

KevTech said:

Because it depends on your internet speed to download files.

The slower your connection speed the longer it will take.

Click to expand...

Not exactly. If you want to download a 274Mb file it would not take 5 min. (1) to (slower speed) one hour to download,

The problem is the Microsoft upload server. It is sending that 274Mb in chunks. (0% - 100%) You can see the slow progress inside the CBS.log.

One download takes 5 min. (1) Then Windows is asking the upload server for a retry. (because something is wrong??) and start a second time. The upload server is not uploading anything because it just had send that file already. It is saying "You got it already I am not uploading it a second time!!" After that second failed retry Windows is going ahead with download#1 and fixes nothing because nothing is broken. ScanHealth already found nothing wrong. (Not always true!!! After an successful update a number of FileFlags are corrupted)

The exact time that takes RestoreHealth during it's Checking-fase is just long as ScanHealth it took to check your system. (4 min. (1))
After the download fase RestoreHeath enters the fixing fase and repairs mostly nothing exept corrupted FileFlags.
In total (1) it takes 4 min. plus 2x 5 min. 14 Min. in total. This is all caused by the CBS-bug introduced when they changed the CBS-engine with 26x00.8655)
It always suspects that there is something wrong after the Checking-fase.
That issue is still present with anything above 26x00.8655. Reported this already to MS only to fall onto deaf ears....

And this is all because the Checker assumes corruption. At this point in the CBS.log

Repr: Staged package check completes
Repr: No payload missing but suspected file flag corruption detected, continuing to acquire CIX for RepairStagedFileFlags.
Exec: Download qualification evaluation, business scenario: Manual Corruption Repair
Exec: Clients specified using Windows Update.
FC: Calling Download on WUClient Acquirer
FC: FCAcquirerWUClient: Calling WindowsUpdateDownloadFromUUP
FC: FCAcquirerWUClient: WULib Mode Complete: [0]
FLOW: Entering stage: Download

Click to expand...

(1) In my case. I have a 1Gb connection.