DISM Cleans Up After Windows Update
As Windows 10 garners updates, superseded components can accumulate in the Windows Component Store (aka WinSxS). You can use the Deployment Image Servicing and Management (DISM) command to clean such things up. This is useful, not just for one-at-a-time grooming of Windows images in everyday use. It’s also a good idea to use this capability on canonical images used for enterprise deployment. So, whenever you update an image, you can use DISM to check if if cleanup is needed. If it is, you’ll be pleased to understand that DISM cleans up after Windows Update easily and happily. That said, the cleanup process can take some time to complete so be patient.
When Is DISM Cleans Up After Windows Update Necessary?
Good question! And, as it happens DISM itself can tell you if cleanup is needed or not. Here’s how it’s done for online images. (For offline images see this MS article “Reduce the Size of the Component Store in an Offline Windows Image.” In general, it requires targeting a specific offline image.) The AnalyzeComponentStore option provides the necessary information, as shown here:
If the number of reclaimable packages is greater than zero (top red arrow), the cleanup recommendation will always be “Yes” (bottom red arrow).
[Click Image for Full-Sized View.]
This DISM command also provides other useful information as well. Note that it shows the size of the WinSxS folder (the Component Store) in Explorer, and also the actual on-disk size. The latter item includes the sum of the Shared with Windows, Backups and Disabled Features, and Cache and Temporary Data Items. The former includes additional disk space reported to Windows Explorer because of hard links in WinSxS files. This can be useful info to keep track of, too, all by itself.
Performing Component Store Cleanup
The actual syntax for cleanup is pretty simple and straightforward, too, and comes with an interesting twist. This appears in the next screenshot with usable DISM command syntax. Note that DISM reports progress in two bars, rather than one. I’ve noticed that it seems to restart its progress count on a separate bar as soon as it encounters the first package in need of reclamation. I’ve seen this number as low as under 10 percent (as shown below), but I just saw it as high as 92% on the other machine that prompted this blog post (not shown).
And remember, because this cleanup involves copying over the entire component store, while removing the reclaimable packages, this takes some time to complete. It took over 4 minutes on my i7 Skylake production PC with a 6.38 GB WinSxS folder. That stretched over 12 minutes on my older, slower Lenovo T520 laptop with a 9.8 GB WinSxS folder.
After the cleanup is complete, you can assess its impact on the Component Store by repeating the AnalyzeComponentStore directive. For the T520 used for the preceding screenshots, the post-cleanup size is 6.7 GB (actual) and 6.81 GB (Explorer). The original values were 9.8 and 10.25 GB respectively. That means savings of 3.1 GB (actual) and 3.44 GB (reported in Explorer). Not bad, for purging 3 packages!