WinSXS corruption (the component store is repairable) is often a tedious task to repair, especially when working on Windows Server 2016 where builtin commands might not be able to fix this out of the box. This guide shows a way that worked in most circumstances to get WinSXS consistent again.
We are regularly checking running operating systems for integrity. One important component on Windows is the side-by-side store (mostly known as WinSXS). Having quite some Windows Server 2016 Servers running, we saw an increasing number of systems with WinSXS corruption with the result component store can be repaired when running dism /online /cleanup-image /scanhealth
When receiving this error (The component store is repairable / Der Komponentenspeicher kann repariert werden), you might be able to repair the side-by-side store directly using dism (dism /online /cleanup-image /restorehealth), even if you're trying to query Windows Update servers. Yet chances are high that it will fail and one of the following errors might be shown:
0x800f081f The source files could not be found. Die Quelldateien wurden nicht gefunden.
0x800706c6 The array bounds are invalid. Die Datenfeldgrenzen sind unzulässig.
In both cases (and there are probably many more), you might try to do two things:
Point to another, similar installation to use as source files
Mount installation media and try to use it as source files
If both options don't work, you can try the following, more manual approach.
Windows Server 2016
Corrupted SXS is seen on several versions of Windows Server. Windows Server 2019 and newer are quite capable of repairing corruptions itself, at least in our observerations. So this guide targets mainly Windows Server 2016, while the procedure also works for newer versions (still, there might be easier ways on newer versions ;-) )
Check out the CBS.log to find missing packages
Regarding the type of error, we skip the DISM.log and open directly CBS.log to search (from bottom up) for either error messages or a summary information.
An error message corresponding to the DISM output might look like on of those two examples:
More important, the Detect and Repair summary looks like this:
The summary tells us, that in the CBS store, quite some manifests are corrupt. Manifests are mostly metadata files (like XML) that describe packages etc.
To find out what packages are affected, just scroll up a little bit and you'll see the detailed list of affected packages:
And this is the point where we'll be starting with our manual approach.
Restore missing packages from windows update
As windows itself is not able to find the source files for these packages, we're going to help a little bit.
In the message you can determine the affected update: Package_2884_for_KB4489889~31bf3856ad364e35~amd64~~10.0.1.6 is contained in update KB4489889.
Download the update package
In order to download the update package manually, we will go to Windows Update Catalog and search for the name of the update (in this case KB4489889).
From the results, select the version that matches your operating system version and edition and click the download button to download the file.
Service stack updates
As updates are now combined more often in SSU (service stack updates) packages, you might not be able to find the matching packages directly and you need to go to Microsoft Update information to see what corresponding SSU package relates to the package you search (in our example above it is KB4485447).
Unpack the package (twice)
Having downloaded the update, you need to unpack it twice:
First, unpack the MSU
Second, unpack CABs within the MSU
To extract the MSU file, we use the builtin expand command:
The extracted files will mostly be cab archives.
So, now we've extracted the MSU archive but not yet our manifests we need. To get these, we need to extract the actual update package (the selected CAB archive in the screenshot above) within our already extract files.
CAB files containe a whole bunch of nested files and directories - so don't worry if this takes a moment, even if the file is rather small.
So, we've extracted our package and are now ready to run DISM again to fix the SXS store.
Run DISM with Source flag
Having our package files in place, we will now run DISM with an explicit location for the source files:
This will take a while but have a quite high chance to fix our issue.
Multiple missing packages
Of course multiple packages might be missing. You might fix this one by one (download, extract, dism, etc.) or you might extract all missing package names at once from the CBS.log, download the packages and extract the CAB archives into the same target directory that will then be used as source for the DISM command.
We use the /LimitAccess flag to avoid windows update lookups for package files in order to speed up the process.
After the repair has completed successfully, remove the downloaded update package and the extracted items and enjoy that you've fixed the SXS store :-)
Certificates are everywhere - sometimes you want to keep them even more secure than just on the filesystem (or operating system store). This guide shows how to create TPM backed certificates on windows.