Creators Update Image Integrity Gotcha

Ed Tittel Profile: Ed Tittel

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:

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'. -
CDriverManager::OpenPackageByFile(hr:0x80070002)

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.”

Comment     RSS Feed     Email a friend