Problem solve Get help with specific problems with your technologies, process and projects.

Creators Update Image Integrity Gotcha

Over the past weekend, I upgraded 5 installations to Creators Update. Yesterday, I did likewise to my production PC. It is now happily ticking along, running the new release without apparent problems. However, I’ve discovered an interesting issue. Image integrity checks on the new installation using DISM do not always complete successfully. Instead, they may produce a warning that the component store is corrupted but repairable — on some PCs, at least. If the log file didn’t indicate a conspicuous lack of real issues, this might worry me. Given its contents, though, I see this as more of a Creators Update image integrity gotcha than as a real problem. Please, allow me to explain…

Why Say Creators Update Image Integrity Gotcha Rather Than “Problem?”

The following screen capture from PowerShell shows what I’m discussing here in the context of the DISM commands involved:

Creators Update Image Integrity Gotcha

Notice the error persists, even when I try the /restorehealth option pointing to the MSDN ISO file for Win10 1703.
[Click image for full-size view/improved readability]

What you see in the preceding screenshot is the following sequence of commands:

  1. DISM /online /cleanup-image /checkhealth:
    Checks component store integrity, and reports a finding of corruption that is repairable.
  2. DISM /get-wiminfo /wimfile:u:\sources\install.wim
    Reports on the layout of the install.wim file from the 1703 ISO file (downloaded from MSDN on 4/11/2017). It shows that Windows 10 Pro resides in the first segment therein (Index:1) and Windows 10 Home in the second segment (Index:2).
  3. DISM /online /cleanup-image /restorehealth...
    Uses the Install.wim examined in the preceding command as the source for attempted component store repair, but reports that “The source files could not be found.” I received the same error message when initially attempting to repair the image using the ESD file included on the USB Flash drive that the Media Creation Tool built for the actual upgrade. That’s what makes me think this is a Microsoft problem, rather than a real corruption issue.

DISM.log Tells a More Complete Story

The DISM log file reports corruption in a most mysterious fashion, too. It finds a single error, in looking for a driver file. That report appears as follows in the dism.log file (I break up this single long line for readability):

2017-04-12 03:33:16,
Error DISM DISM Driver Manager: PID=19052 TID=16324
Error, file not found 'oem0.inf'. -

A bit of explanation and history may help. The first item as shown provides a time stamp for the log entry. The second line indicates that the problem originates from the DISM Driver Manager. In turn, this tells me the problem is with a device driver rather than a component store entry. The third line provides the information that a driver file named oem0.inf is what’s missing. This is a generic entry for the first item in the Windows DriverStore. DriverStore Explorer tells me this entry is for the Nvidia Sound, video and game controller driver. We’ve seen similar problems show up in previous Windows releases where an Nvidia driver mismatch for the graphics driver caused a similar and equally spurious report of component store corruption.

I did some further checking. Indeed only those PCs that have Version 1703 Build 15063.11 or later show this “corruption” problem. (15063.138 is the most current Build ID for Current Branch Windows 10.) Microsoft has been informed of this issue on the Feedback Hub, so I expect we’ll see it fixed in some upcoming Cumulative Update. And again, that’s why I’ve entitled this blog post “Creators Update Image Integrity Gotcha” rather than “Creators Update Image Integrity Problem.”

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Thanks Ed, for confirming this DISM "can't find source files" problem that I'm also having using 1703 15063.138   Happily giving up trying to solve this problem after reading your blog.  Previously, I had tried everything recommended without any success. I will simply wait for May 2017 Patch Tuesday.  
Noticing also Ed, the "chkdsk /f " no longer works in 1703 15063.138
No scan initiated after restarting and no data in the Event Viewer to be found.  

This is in addition to the DISM.exe no longer working properly.. Thanks Ed for your contribution

I haven't heard a chkdsk failure being reported, nor does it fail for me on my various 1703 PCs. What sort of problems are you experiencing? This may indeed reflect some problem particular to your system, rather than a widespread failure. Please tell me more!


Thanks for your contribution Ed.  I was able to run chkdsk /r in Windows Recovery Environment using the command prompt there.  It took 5 hours to complete but this is normal time for my 2 TB HDD.  But in the normal elevated command prompt, not the WRE, I must first designate the "C" drive as dirty via FSUTIL dirty set C: to activate the chkdsk process.  Without designating C as dirty, restart simply returns to the Windows desktop without running chkdsk /f. 

Some have said that if "C" is clean, chkdsk is not going to run after ordering it in the command prompt.  I question this advice because previously  any time I ordered chkdsk /f it would perform after restarting. 

I clean installed Creators Update via MCT  (complete wipe) but found no difference in DISM performance or the chkdsk /F performance from the elevated command prompt.

SFC /scannow finds no integrity violations so I'm not really worried about any of this.  Should I be?  
Dears, the same problems with DISM!
Version 1703 10563.250
Installed Nvidia card
PS C: \ WINDOWS \ system32> DISM / Online / Cleanup-Image / RestoreHealth /source:M:\Sources\Install.wim:1 / LimitAccess
Deploy Image Servicing and Management tool
Version: 10.0.15063.0
Image Version: 10.0.15063.0
Yu =========================== 87.5% ==================]
Error: 0x800f081f

The source files could not be found.
And your advice is that Microsoft is informed of the warmth of the soul and allows me to hope for a bright future.
Do not find it difficult to lay out the solution to the problem, if this happens.
Thank you
And imho "chkdsk /scan /perf" working faster than  "chkdsk /f".
Here the problem solved:
probably a good idea to export the registry key into a .reg file using File/Export.

The first key is:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageIndex\Microsoft-Windows-TestRoot-and-FlightSigning-Package~31bf3856ad364e35~amd64~~

The 2nd key is:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\Microsoft-Windows-TestRoot-and-FlightSigning-Package~31bf3856ad364e35~amd64~~10.0.15063.0

  • Андрей says:

    For 64-bit systems, you need to delete 4 keys in the registry. 2 keys about which is written in the article, plus 2 exactly the same keys that contain the name WOW64. You also need to delete 4 .cat and .mum files. After that, DISM will work.

  • Cancel

    Yes, this has turned into a real "tempest in a teapot." I'm in agreement with the poster who observed that because sfc /scannow finds no problems, the dism issues are not serious. In fact, ongoing discussion at (the source of the borncity item cited here, and the source of my reporting, too) indicates that the cause of the issue comes from sourceflighting variables associated with the Windows 10 release information itself. Who knows how long MS will take to fix this? Not me, but I've got more important stuff to deal with in the meantime. Thanks to all for their posts, especially Yuri and Andrei.