Go to ...

RSS Feed

DISM: AnalyzeComponentStore and StartComponentCleanup


Among the many Windows 10 facilities that the Deployment Image Servicing and Management (DISM) tool oversees is something called “the component store.” Today’s look at this “Swiss Army Knife” of Windows commands focuses on two specific parameters that work with target images (which may be offline or online) — namely: AnalyzeComponentStore and StartComponentCleanup. The first of these options, AnalyzeComponentStore, examines the component store to access its current state. The second one, StartComponentCleanup, cleans up obsolete items (components) in the component store (defined as “previous versions of updated components” in MS Docs).

A Quick Component Store Primer

The Component Store lives in the WinSxS folder, which usually resides in C:\Windows (or the resolved value for the %windir% symbol, if you prefer a more generic description). According to the MS Docs article “Manage the Component Store,” the “Component Store is used to support the functions needed for the customization and updating of Windows.” That same document presents the following list of how Component Store files may be used in the Windows 10 environment (quoted verbatim):

  • Using Windows Update to install new component versions.
    Keeps systems secure and up-to-date.
  • Enabling or disabling Windows features.
  • Adding roles or features using Server Manager.
  • Moving systems between different Windows Editions.
  • System recovery from corruption or boot failures
  • Uninstalling problematic updates
  • Running programs using side-by-side assemblies

This document also provides a bit of Windows history as it goes on to observe that the Component Store dates back to Windows XP, wherein it was introduced to support so-called “side by side assemblies” (different versions of the same executable and its runtime environment support elements that could be packaged to run in separate by parallel processes).

Starting in Windows Vista, the Component Store acquired the ability to track and service all OS components, including files, directories, registry keys, and services. Specific component versions get grouped together into collections called packages, which is what Windows Update (WU) and DISM use to update Windows itself. All components and packages referenced in a Windows installation, upgrade, or update get processed into the Component Store.

Calculating the size of the Windows Component Store is a complex task, made more challenging by use of elements it stores that are referenced in directories outside the Component Store through a file reference technique called hard linking. This makes files from a component in the store appear inside and outside its confines. In fact, hard linking lets Windows appear to maintain multiple copies of the same file (behind the scenes, there’s only one copy, kept in the Component Store, somewhere in the %windir%\WinSxS folder hierarchy.

Base DISM Syntax: AnalyzeComponentStore and StartComponentCleanup

Both of these DISM parameters appear as part of the Cleanup-Image command option. It is also necessary to identify a target image for analysis or cleanup. This means either using the /Online parameter to target the current running version of Windows, or the /Image parameter to target an offline image by its disk location. The /Online parameter takes no values so you can use it by itself. The /Image parameter requires inclusion of a path specification to a specific Windows image file which may be a .wim, a .vhd, or a .vhdx file. See the MS Docs article “Reduce the Size of the Component Store in an Offline Windows Image” for complete details on the  /Image parameter.

For this article, I’ll concentrate on targeting the current running version of Windows 10 using the /Online parameter. Just remember that you can also target other offline Windows images for these operations using the /Image parameter instead.

Working with AnalyzeComponentStore

Note: DISM runs with equal facility in cmd.exe or PowerShell. For the illustrations here, I’ll use PowerShell. Here’s what the output of Component Store analysis via DISM looks like on a recently-update Windows 10 Build (17134.228 as shown in the screen capture) looks like when analyzed.

DISM.analyzecomponentstore

Arrows on image show callouts for some info items of interest. I’ll talk about cleanup info in the next section.
[Click item for full-sized view.]

As should be obvious, there’s no need to clean up the Component Store unless the recommendation value at the end of this command’s output says “Yes.” If that value is yes, the preceding value will report the number of packages that can be cleaned up. In this case, the size information that precedes these values provides a “before” snapshot for Component Store size prior to a cleanup operation.

Working with StartComponentCleanup

When cleanup is called for — as in the case used for the preceding illustration — you will use the StartComponentCleanup parameter. The next screenshot shows the syntax (and the results) of performing the operation, as indicated by running AnalyzeComponentStore again after it finishes to show the impact on reported size information for the Component Store:

Note that other than progress and completion information, running this DISM command doesn’t produce much output. But by running AnalyzeComponentStore once again after it’s completed its cleanup, we can easily assess the impact on Component Store size. Though StartComponentCleanup doesn’t show us much, it can take some time to complete (the more packages in need of cleanup, the longer it will take to finish). This cleanup took 5 minutes or so, on a Z170 i7 6700 PC with 32 GB RAM and a Samsung 850 NVMe SSD. Sometimes, you may see double progress bars during the StartComponentCleanup operation. As far as I can tell, this indicates some minor issue with progress reporting as this operation gets underway. I’ve noticed this minor and occasional anomaly in this command string’s output since Windows 10 made its debut.

Here are the cleanup results from the system that generated the preceding screen capture:

dism.startcomponentcleanup.results

Notice the reductions in the component store numbers after cleanup, when we also see 0 reclaimable packages and no cleanup recommended.
[Click image for full-sized view.]

What Can StartComponentCleanup Do?

In this particular case, with 5 packages to reclaim, we can see some pretty substantial changes in the WinSxS size information before and after the cleanup operation. Stacking those numbers side by side we see:

WinSxS Size Information: Before & After Cleanup
Before After Delta
Reported Size 9.18 GB 6.58 GB -2.6 GB (28%)
Actual Size 8.90 GB 6.45 GB -2.45 GB (27%)
Shared with Windows 5.68 GB 5.65 GB -0.03 GB (0.5%)
Backups & Disabled Features 2.99 GB 578.5 MB -2.42 GB (81%)
Cache & Temp Data 220.07 MB 217.87 MB -2.2 MB (1%)

That makes for some pretty decent cleanup numbers, especially for the backups and disabled features (as you’d expect). That delta accounts for the vast majority of the overall size reduction (2.42 of 2.6 GB overall). Great stuff!

More Compression with ResetBase

For an extra 10-15% size reduction, you can add the /ResetBase parameter to the /StartComponentCleanup command string. This will further compact the Component Store, but comes with one noteworthy restriction: once you use this parameter, any installed updates may no longer be uninstalled through Windows Update (or related tools, such as the Windows Update MiniTool aka WUMT). This makes most sense for smaller tablets where storage space is often at a high premium. I seldom, if ever, use this parameter myself on ordinary desktop, notebook, or laptop systems. Even my tablets have a minimum of 250 GB SSDs, so I don’t really need it for them, either. YMMV.

When Does StartComponentCleanup Make Sense?

I usually run AnalyzeComponentStore after installing cumulative or other Windows updates. It will tell you if cleanup is recommended or not. But if the number of packages climbs over 3, it’s usually worth doing. Note: a Feature Upgrade resets the Component Store, so there’s no need to investigate things after a Feature Upgrade until the first (set of) Windows Updates come(s) along.

Author: Ed Tittel

Ed Tittel is a 30-plus-year computer industry veteran. He’s a Princeton and multiple University of Texas graduate who’s worked in IT since 1981 when he started his first programming job. Over the past three decades he’s also worked as a manager, technical evangelist, consultant, trainer, and an expert witness. See his professional bio for all the details.

Leave a Reply