Creators Update Image Integrity Gotcha

Tags:
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:
- DISM /online /cleanup-image /checkhealth:
Checks component store integrity, and reports a finding of corruption that is repairable. - 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). - 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.”
9  Comments on this Post
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!
--Ed--
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
The first key is:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageIndex\Microsoft-Windows-TestRoot-and-FlightSigning-Package~31bf3856ad364e35~amd64~~0.0.0.0
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
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.
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 TenForums.com (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.
--Ed--