The Windows Deployment Image Servicing and Management (DISM) command is a veritable “Swiss Army Knife” for working on Windows OSes and images. There’s so much to say, in fact, that Kari and I plan to publish a long, long series of articles on it. After we get enough such bits and pieces to attain critical mass, we’ll bundle them all up into a regularly-updated eBook whose working title is The BIG BOOK of DISM. Stay tuned for more details here at Win10.guru. We want to make this a good general-purpose reference and resource, but we also want to include lots of examples, so that people can see and understand how to use this powerful command and its many different features and functions. Some of its syntax can get tricky. That is the most important reason to include lots of illustrations and examples, in fact. This will come up in some detail in the second article in this series “Using Restorehealth to Repair a Windows Image.”
What’s the Difference Between Scanhealth and Checkhealth
DISM supports a /cleanup-image parameter that includes the ability to scan, check, and restore the health of a specific Windows target image. You can try this out for yourself with the following commands that will operate on the Windows 10 image you currently have running. For this post, let’s look at two different commands that can check the health of an image. To use either or both of them, you’ll want to launch an administrative Command Prompt or PowerShell session.
dism /online /cleanup-image /checkhealth dism /online /cleanup-image /scanhealth
A Matter of Time, Scope and Depth of Coverage
If you take a look at this PowerShell session output, you’ll be able to grasp the difference between Checkhealth and Scanhealth immediately. Note the difference in elapsed time between the two commands, each of which makes some kind of assessment of the health of a Windows image, based on the contents of the component store:
Checkhealth takes less than 10 seconds to complete; Scanhealth runs for almost two minutes! That tells us a lot.
If you look at the timestamps, you can see that it took less than 7 seconds for the Checkhealth option to complete. It took less than 1 minute and 51 seconds for Scanhealth to do its thing. That’s 7 versus 111 seconds, respectively (a 1:15.85 ratio): a pretty big difference. What’s going on here?
Digging into the reference material, it’s possible to understand what makes them so different. The Checkhealth command simply checks existing logs to see if any Windows processes have reported errors when trying to run items from the Windows component store. This command is only looking for already existing errors, and completes very quickly. Scanhealth actually checks each item in the component store, calculates a hash value for the current file and compares it to a stored hash value for a known, good, working version of that file that Microsoft routinely calculates as part of its release and integrity management processes. Scanhealth also writes a log file while it chunks through the items in the component store, too. That’s why it takes so much longer for Scanhealth to complete: it’s actually doing quite a bit more. If you look at performance monitor or other tools that report on real-time CPU and storage resource consumption you will see a big difference between the amount of activity involved in completing Checkhealth versus Scanhealth as well. To learn more about these arguments to DISM /cleanup-image, please consult the MS documentation “Repair a Windows Image” or the TenForums tutorial “How to Repair Windows 10 Image Using DISM.”
Why Use Checkhealth When There’s Scanhealth Available?
That’s a good question, but it has a very good answer. If you use Checkhealth, it will tell you if it finds any errors. It will also tell you if a Windows image is healthy, repairable, or non-repairable. If it’s healthy, you don’t need to use Scanhealth and you’re done in just a few seconds. If it’s repairable, running Scanhealth will tell you what needs to be repaired if you want to expend the time and effort necessary to review the CBS.log file that DISM writes by default to %windir%/Logs/CBS. Note: CBS is short for component-based servicing, which is what DISM is really doing with the component store behind the scenes. If an image is reported as non-repairable, Microsoft recommends that “you should discard the image and start again” (short words for a time-consuming and sometimes difficult process). If an image is repairable, you can use the Restorehealth option to effect repairs. This is a big enough topic to warrant its own article, and will be the subject of the next item in this series.
On the other hand, it’s always possible that something may be off about a Windows image that hasn’t provoked an error log entry for Checkhealth to find. If a Windows installation is misbehaving, and Checkhealth finds nothing amiss, it may then make sense to run Scanhealth anyway to force an item-by-item check of the component store. I’d reserve this for a fallback maneuver in the event that Checkhealth finds nothing, but Windows continues to veer off the rails. I’m sure you know what I mean…
Calling All Feedback
We’d like to get your input and reactions to this series of articles. You can post comments to any of the posts here at Win10.Guru.
Here are some of the other topics we already know we want to include in this DISM series:
- Backing up device drivers using DISM
- Adding device drivers to a Windows image using DISM
- Changing the Post-Upgrade Rollback Interval using DISM
- Adding Packages to a Windows image using DISM
- Update an offline Windows image using DISM
- Compacting Windows installations using DISM
- Capture WIM and FFU images for backup and deployment using DISM
- Deploy Windows using DISM
We’re especially interested in your suggestions for additional DISM parameters and arguments you’d like to see covered. But we’re grateful if you simply want to tell us what you think of any single post, or the collection, in terms of what’s missing, what you may not have understood, where you could benefit from more discussion, details, or examples, or other ways we could improve upon this coverage. So please: tell us what you think! Thanks in advance for that. We hope you’ll be active and vocal in your participation in this project.
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.