As I work with a new Windows version, I have a strong tendency to go haring off after internals info to better understand how things work. Recently, I’ve had great fun digging into the volume shadow copy files and behavior under Win10TP. Somewhat less fun have been my attempts to figure out why the “Deployment Image Servicing and Management” tool, aka DISM, reports that both Windows 10 Technical Preview plain-vanilla and enterprise versions suffer from repairable corruption in their component stores, but neither are fixable using the command’s various /RestoreHealth options. The following screenshot tells the story in a single capture, which I’ll explain further below:
The symptoms look simple, but the fix provides impossible to perform.
Here’s what’s involved in the two commands shown, and what else I tried in my attempts to remedy the apparent defect reported:
1. The first DISM command simply inspects the running Windows image (that’s why /online is included), and checks its overall health and well-being.
2. The second DISM command attempts to repair any outstanding issues it finds in the component store (which resides in %windir%\winsxs, that often impenetrable repository for large and mysterious Windows OS component files).
3. To perform its repairs, DISM must have access to a known good working Windows image file (usually in the .wim format) so as to grab replacements for any damaged or corrupted items it might find. Alas, all my /RestoreHealth attempts produce the same error message, which indicates that the program can’t find the image file it needs to make repairs.
4. DISM supports a /LimitAccess option that prevents the utility from turning to Windows Update to find a working image (this is useful in environments where the Internet is not available, where access is purposely restricted, or when problems present and difficulties in accessing WU must be ruled out, as may be the case here). Turning this option on (or leaving it off, as by default) made no different.
5. DISM supports a /Source option that enables the command to target a specific set of source files. I downloaded the only Win10 TP ISO for build 9879 that’s currently available — namely, for the Enterprise version, through the MS TechNet Evaluation Center — mounted the ISO as a drive on my test system, and pointed the /Source option at the \Sources directory in that collection of files. No joy there, either, alas.
In short, nothing I tried let me fix the problem that /ScanHealth was reporting, despite access to all of what should have been the right stuff for either version of the Technical Preview, Build 9879. I am reluctantly forced to conclude that something in this Build is sufficiently wonky to prevent the utility from working as it should, and can only look forward to finding it fixed in some future build. I’ve reported the issue to MS via the “Windows Feedback” app, in hopes that their superior investigative talents and image analysis tools will help them to figure out how to link up the right sources to the repair utility to put the fix in. As is so often the case in a preview situation, it is interesting to see and learn from how such things unfold.