The component store is corrupt, so every update fails: what WinSxS actually is, and what DISM and SFC really do to it

Something goes wrong with Windows Update, and within about ninety seconds somebody says "run SFC, then run DISM". It is the most repeated advice in Windows administration. It is also, in that order, backwards. And almost nobody saying it can tell you what either tool actually touches.

The problem: every update fails and WinSxS looks enormous

Two complaints arrive together often enough that they feel like one problem.

The first is that updates stop installing. A cumulative update downloads, stages, then rolls back. Enabling an optional feature fails. The error is usually 0x800f081f or 0x800f0922. Nothing in the Windows Update user interface explains why.

The second is a disk-space complaint. Somebody sorts C:\Windows by size in File Explorer and finds a folder called WinSxS using more space than everything else combined. On the machine I used to write this article, Explorer reports 24.81 GB.

Both complaints lead to the same two commands being typed, usually in the wrong order, usually with no idea what they do. So before any command, three questions need answers.

1. What is the component store, and why does an update fail when it is damaged?
2. How big is it really, as opposed to how big Explorer says it is?
3. Which of the DISM switches read, which repair, and which permanently destroy your ability to uninstall an update?

Why it happens: WinSxS is the component store, not a junk drawer

What the component store actually is

Microsoft states the location plainly: the WinSxS folder is "the location for Windows Component Store files", and the component store "is used to support the functions needed for the customization and updating of Windows". It then lists what depends on it.

Read the last two rows again. The store is not only how updates go on. It is also how they come off. That is the single most important thing to understand before you run any cleanup command.

The chain, from trigger to result

Here is the order things happen in. Every arrow is one component handing off to the next.

1. An update package arrives, as a .msu or .cab. Microsoft documents that specific versions of components are collected together into packages, and that packages are what Windows Update and DISM use to update Windows.
2. The package is described by manifest and catalogue files. On a live device these sit as .mum and .cat files under C:\Windows\servicing\Packages. On the machine I checked there were 14,980 of them.
3. The servicing stack reads that metadata. The component-based servicing engine, CBS, decides what needs to change.
4. Component versions are placed into C:\Windows\WinSxS, one directory per component version. That machine had 30,125 of them and 43,198 files under WinSxS\Manifests.
5. The live operating system directories, such as C:\Windows\System32, are pointed at the correct version using NTFS hard links.
6. A reboot commits any change that could not be made while the files were in use.

If step 4 is incomplete, step 5 has nothing to point at, and step 3 refuses to proceed. That is component store corruption in one sentence. The store says a component should exist; the payload for it does not.

Hard links, and why Explorer lies about the size

This is the part that gets WinSxS deleted by people who should know better. A hard link is, in Microsoft's words, "a file system object which allows two files to refer to the same location on disk". One set of bytes, two paths. Explorer counts both paths.

Microsoft gives a worked example. Directory A holds 1.txt, 2.txt and 3.txt. Directory B holds 4.txt. Files 1 and 2 are hard linked together and hold 1 MB. Files 3 and 4 are hard linked together and hold 2 MB. So how big is directory A? Microsoft gives three different correct answers.

Microsoft then says which of the three applies to WinSxS: "The third answer in the directory A example, most closely matches how much extra space is used." Files hard linked to the rest of the system are needed for the system to run, so they should not be counted at all.

You can watch this happen on your own machine. Microsoft's older troubleshooting article uses advapi32.dll as its example, so here is that exact file on a real Windows 11 device.

Genuine run on a Windows 11 device, build 26200.9168. The component-directory hash is redacted only because it is long, not because it is sensitive.

The servicing stack: the code that does the work

Microsoft defines the servicing stack as "the component that installs Windows updates", and says it contains the component-based servicing stack, CBS, which is the underlying component for DISM, System File Checker, changing Windows features or roles, and component repair. All four of those things are the same engine wearing different hats.

Here are the binaries. Every path below was confirmed on a live Windows 11 device rather than copied from another article.

That row about CbsCore.dll deserves a sentence of its own, because it is the neatest possible demonstration of what WinSxS is for. People expect the servicing engine to be a DLL in System32. It is not. It is a component version inside the store, and the running copy is hard linked out of it.

Genuine run, with the component hash redacted for width. This is also why Microsoft ships servicing stack updates separately and occasionally out of band: when the repair engine is the broken part, nothing else can repair it.

How to verify: read the store before you write to it

Every switch in this section only reads. None of them changes anything. Run all of them before you run anything from the next section.

Step 1: get the real size, not the Explorer size

Microsoft documents one command for this, and its output has eight named fields.

That is a genuine run on the device I wrote this on, unedited. Now read it the way Microsoft says to read it.

Microsoft gives an explicit formula for the real overhead: add "Backups and Disabled Features" to "Cache and Temporary Data". Everything else is either shared with running Windows or double-counted.

On my device that arithmetic is 14.79 GB plus 0 bytes, so 14.79 GB of genuine overhead against an apparent 24.81 GB. In Microsoft's own documented example the same arithmetic turns an apparent 4.98 GB into 507.18 MB. Both numbers are real; they measure different things.

Step 2: understand what each /Cleanup-Image switch does

This is where the folklore does real damage, because two of these switches are not reversible. Here is every documented option, with Microsoft's own description.

Step 3: know why CheckHealth and ScanHealth can disagree

This is the single most useful thing in this article, and it comes straight out of the documented wording. /CheckHealth checks whether the image "has been flagged". /ScanHealth "scans the image". Those are different operations, so they can give different answers.

Here is that happening on my device, in one sitting, with nothing changed in between except the scan itself.

Genuine sequence, captured in that order. The practical rule falls out of it directly: never act on /CheckHealth alone. Treat it as a cheap hint that a scan is worth the several minutes, not as a verdict.

Step 4: know what SFC does differently

System File Checker is not a smaller DISM. It works on a different set of files, in a different direction.

Row two is the whole reason the folklore order is wrong. SFC repairs live Windows files by copying good versions out of the component store. If the component store is the damaged thing, SFC is copying from the corruption. It will either report that it could not fix some files, or it will succeed and change nothing that mattered.

Microsoft documents four possible SFC outcomes. Learn them, because three of the four are commonly misread as success.

Step 5: the log files, and exactly what to grep for

Two logs matter, and Microsoft documents both paths.

Microsoft publishes one exact command for extracting the SFC portion of CBS.log. Use it verbatim.

The other line worth knowing is the session marker. Every servicing operation opens and closes one.

Genuine lines with the session identifier redacted. The client name is useful on its own: DISM Package Manager Provider means somebody ran DISM, CbsTask means the scheduled cleanup task, WindowsUpdateAgent means Windows Update.

Step 6: the registry surface

Microsoft documents comparatively little of the servicing registry, so this table separates what is documented from what is merely observable. That distinction matters: an undocumented value can change in any update.

Step 7: Event Viewer, services and scheduled tasks

Microsoft does not publish an event ID reference table for component-based servicing. Saying so is more useful than inventing one. What it does use is a channel, and the events in it are readable and self-describing.

Those three IDs and their exact wording came off my own device, not from a documentation page. Treat them as observed rather than contractual. The reliable reading is the pattern, not the number: an Id 1 that never gets a matching Id 2 for the same KB is a package that started changing state and never arrived.

The service and the task are both documented, and both have a name people get wrong.

Microsoft documents two limits on that task that explain a great deal of confusion. Run automatically, it waits at least 30 days after an updated component is installed before uninstalling previous versions. And "if you choose to run this task, the task will have a 1 hour timeout and may not completely clean up all files."

You can start the task by hand. Microsoft documents both the console route and the command.

1. Open Task Scheduler.
2. Expand the console tree to Task Scheduler Library › Microsoft › Windows › Servicing › StartComponentCleanup.
3. Under Selected Item, click Run.
4. Or, from an elevated prompt, run schtasks.exe /Run /TN "\Microsoft\Windows\Servicing\StartComponentCleanup".

Step 8: the PowerShell equivalents

Everything above has a cmdlet. The DISM module ships in the box, so nothing needs installing.

The fix: the correct order, and the source-file problem

The correct order, from Microsoft's own support article

The folklore says SFC then DISM. Microsoft's support article on using System File Checker says the opposite. Its documented steps run DISM.exe /Online /Cleanup-image /Restorehealth first, and only then sfc /scannow.

The reason is the one from the comparison table above. SFC repairs live Windows files by copying known-good versions out of the component store. DISM repairs the component store. Repair the source of truth first, then repair the files that are restored from it. Doing it the other way round asks SFC to fix Windows using a broken reference.

1. Check for a pending reboot, and reboot if there is one. A servicing change waiting to commit makes every result below unreliable.
2. Run Dism /Online /Cleanup-Image /AnalyzeComponentStore. Read the real size. Note whether cleanup is recommended.
3. Run Dism /Online /Cleanup-Image /ScanHealth. This is the scan. Allow several minutes.
4. If, and only if, the scan reports corruption, run Dism /Online /Cleanup-Image /RestoreHealth. Add /Source and /LimitAccess if Windows Update is not reachable.
5. Now run sfc /scannow. Let it reach 100 percent before closing the window.
6. Reboot if either tool asks for one, then re-run /ScanHealth to confirm.
7. Only after the store is clean, decide separately whether you want /StartComponentCleanup for disk space. Repair and cleanup are different jobs.

The source-file problem

Now the part that makes /RestoreHealth fail in managed environments. Microsoft documents the default clearly: "Windows Update is the default repair source." The repair source is the same source used for Features on Demand, and it is determined by Group Policy.

So on a device that cannot reach Windows Update, because a proxy blocks it, or because WSUS is enforced, or because the device is offline, /RestoreHealth has nowhere to get known-good files from. It fails with a documented error code.

Microsoft documents four kinds of thing you can hand to /Source.

Setting the repair source with Group Policy

Rather than typing /Source on every device, set it once. There is a real GPO for this, and it is the same setting that governs Features on Demand.

1. Open the Local Group Policy Editor (gpedit.msc) or the Group Policy Management Console.
2. Expand Computer Configuration, then Administrative Templates, then select System.
3. Open Specify settings for optional component installation and component repair.
4. Select Enabled.
5. In Alternate source file path, enter a fully qualified path. Microsoft's examples are a share such as \\server_name\share\Win8sxs, or a WIM with an index such as WIM:\\server_name\share\install.wim:3. Separate multiple paths with a semicolon.
6. Optionally tick Never attempt to download payload from Windows Update to block Windows Update entirely. This is the policy equivalent of /LimitAccess.
7. Optionally tick Contact Windows Update directly to download repair content instead of Windows Server Update Services (WSUS). This is the fix for a WSUS-managed fleet that cannot get repair content.
8. Click OK, then run gpupdate /force from an elevated prompt.

The policy writes to three values under HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Servicing: LocalSourcePath, UseWindowsUpdate and RepairContentServerSource. Read them to confirm the policy actually landed.

Setting the same thing from Intune

The policy is ADMX-backed, so it is reachable from Microsoft Intune. Microsoft documents it in the Policy CSP as ADMX_Servicing/Servicing, mapped to the same friendly name as the GPO.

1. Sign in to the Microsoft Intune admin center at intune.microsoft.com.
2. Go to Devices, then Configuration, then Create, then New policy.
3. Set Platform to Windows 10 and later and Profile type to Settings catalog. Click Create.
4. Name the profile, for example Servicing - component repair source. Click Next.
5. Click Add settings and search the picker for optional component installation.
6. Select Specify settings for optional component installation and component repair under the Administrative Templates › System category, then close the picker.
7. Set it to Enabled and fill in the alternate source file path and the two checkboxes exactly as in the GPO steps above.
8. Click Next through Scope tags, assign to a device group, then Create.

If you would rather use a custom OMA-URI profile, Microsoft documents the path.

What about Defender, ASR and WDAC?

Genuinely not applicable, and worth saying so rather than padding the article. Component-based servicing has no Defender surface, no attack surface reduction rule, no exploit protection setting, no WDAC policy and no Endpoint Security profile. Store integrity is enforced by Windows Resource Protection and the servicing stack, and the only thing permitted to write to the store is TrustedInstaller. Nothing in the Endpoint Security blade configures any of it. If a vendor tells you their agent "protects WinSxS", ask which documented interface it uses.

Proof it worked: a real read-only store report

The companion script for this article reports component store health without repairing anything. It runs only the two documented read-only DISM reports, /AnalyzeComponentStore and /CheckHealth, then reads the logs, the service, the scheduled task, the documented registry values and the pending-reboot state. It never runs /RestoreHealth, /StartComponentCleanup, /ResetBase or sfc, and it never writes anything.

It needs no PowerShell module. It refuses to run unelevated, because a partial read that looks healthy is worse than no read at all.

Genuine output from the device this article was researched on, with nothing edited except the section spacing. The remaining sections of the same run read as follows.

Two things in that output are worth pointing at, because both are the kind of finding a naive script would get wrong.

The LastResetBase_UTC line reports "absent" rather than blank. Absent is a real finding here: it means /ResetBase has never completed on this device, so every installed update is still removable. A script that printed an empty field would leave you unable to tell that apart from a failed read.

And the task last result of 0x8007042B is reported as a fact with its hex form, not as an interpretation. Microsoft does not document what the cleanup task returns on a partial run, so the script says what it read and points at the documented one-hour timeout as the likely explanation. That is the honest version. It is also the version that stays correct after the next servicing stack update.

Reading list from the community

Both of these were fetched and read before being cited here, and both are genuinely on this topic.

References

• Manage the Component Store - what the component store is, the documented dependency list, and the hard link explanation with the directory A example.
• Determine the Actual Size of the WinSxS Folder - /AnalyzeComponentStore, all eight report fields, and the overhead formula.
• Clean Up the WinSxS Folder - the StartComponentCleanup scheduled task, the 30 day wait, the one hour timeout, and the /ResetBase warning.
• DISM Operating System Package Servicing Command-Line Options - every /Cleanup-Image switch, and the LastResetBase_UTC registry tip.
• Repair a Windows Image - CheckHealth versus ScanHealth versus RestoreHealth, and the /Source and /LimitAccess guidance.
• Configure a Windows Repair Source - the four source types, the RTM media and patch level constraints, and the Group Policy route.
• DISM Global Options for Command-Line Syntax - the default %WINDIR%\Logs\Dism\dism.log path and the /LogLevel values.
• Repair-WindowsImage (Dism) - the PowerShell equivalents, including -ResetBase and -Defer.
• Servicing stack updates - the definition of the servicing stack and CBS, and what depends on it.
• Policy CSP - ADMX_Servicing - the OMA-URI, the registry key name and the applicability.
• .NET Framework 3.5 installation errors - the documented meanings of 0x800F0906, 0x800F081F, 0x800F0907 and 0x800F0922, and the Group Policy checkbox names.
• Using System File Checker in Windows - the documented order: DISM RestoreHealth first, then sfc /scannow.
• Understanding Component Based Servicing - Microsoft's own background piece on CBS, linked from the servicing stack documentation.
• Get-ComponentStoreHealth.ps1 - the read-only companion script used for the output above.