For months now, one of my test PCs has claimed something remarkable. It’s a Lenovo ThinkPad X380 Yoga (8th-gen i7, 16 GB RAM, 1 TB NVMe SSD). It’s a working reclaimable packages mystery, as you can see in the lead-in graphic. Note please: it shows 13 (!) reclaimable packages in the component store. But they never go away…
Why Is There a Working Reclaimable Packages Mystery?
Gosh, I wish I knew. But it’s got me learning more about DISM and the Windows Component Store (WinSxS) than I’ve known before. In particular, I’ve been digging into DISM’s /Get-Packages capability, to look into the contents of WinSxS to see what is — and apparently isn’t — going on in there.
Reading about the output of the /format:table directive, I see that the state column can produce a range of values. These include the following, as mined from Learn.Microsoft.Com by Copilot (quoted verbatim):
NotPresent: The package is not present in the image. It has not been installed or added to the image.
UninstallPending: The package has been marked for uninstallation, but the process is not complete. There are some additional steps that need to be performed before the package is fully removed from the image.
Staged: The package has been added to the image, but it is not active. It can be activated by using the
Removed: The package has been removed from the image, but some metadata about it remains. This allows the package to be reinstalled if needed.
Installed: The package is installed and active in the image. It can be deactivated by using the
InstallPending: The package has been marked for installation, but the process is not complete. There are some additional steps that need to be performed before the package is fully installed and activated in the image.
Superseded: The package has been replaced by a newer version of the same package or a different package that provides the same functionality. The superseded package is still present in the image, but it is not active.
PartiallyInstalled: The package has been partially installed in the image, but some components or files are missing or corrupted. This may cause errors or malfunctions in the package or its dependencies.
Digging Deeper Into the Mystery…
As I understand it, the dism /online /cleanup-image /startcomponentcleanup command will remove at least some of the packages in the “Superseded” state from the WinSxS. So I fired up the following command to look into the component store on another test machine. It reports 4 reclaimable packages via DISM, and inspection of the /format:tables output from that PC via Notepad++ reports 106 instances of the term “Superseded” in that text file.
Next, I run the afore-cited “cleanup” command. This takes a few minutes to complete. When I run /analyzecomponentstore again, the number of reclaimable packages is zero (0). So I generate new /format:table output, and open it in Notepad++ again. This time, a search on “Superseded” produces 0 hits. My theory is that the cleanup flushes these items out of the WinSxS, and this data seems to confirm that.
And Now, Back to the X380 Yoga
Here’s where things get interesting. Even though /analyzecomponentstore is reporting 13 reclaimable packages, the /format:table output from that PC includes no instances of “Superseded” in its contents. Somehow, DISM is seeing something that I can’t see via this lens into the WinSxS contents. Therein lies the mystery.
I’ll keep digging and see what else I can learn. Stay tuned! This could get interesting — at least if you, like me, find this kind of thing engaging.