It took me several hours to fix the issue because the local component store was corrupted and the computers are accessing a local WSUS server instead of the public update server by Microsoft (and because I use Dism very rarely). For reference and to help other people with the same issue, I will write down a problem description and provide a solution.
Since upgrading to Windows 10 Pro Version 1511 (Build 10586) I have a problem with a corrupted filed opencl.dll in several locations.
I tried sfc.exe /scannow
, but it failed to fix the issue. The error messages are, among others:
2015-12-08 08:50:43, Info CSI 00003c3a Hashes for file member \SystemRoot\WinSxS\wow64_microsoft-windows-r..xwddmdriver-wow64-c_31bf3856ad364e35_10.0.10586.0_none_3dae054b56911c22\opencl.dll do not match actual file [l:10]"opencl.dll" :
Found: {l:32 g2VAunZ6/2J1G3oL7kf9fjInPUA9VYeiJcl9VKgizaY=} Expected: {l:32 9rnAnuwzPjMQA7sW63oNAVhckspIngsqJXKYSUeQ5Do=}
2015-12-08 08:50:43, Info CSI 00003c3b [SR] Cannot repair member file [l:10]"opencl.dll" of microsoft-windows-RemoteFX-clientVM-RemoteFXWDDMDriver-WOW64-C, version 10.0.10586.0, arch Host= amd64 Guest= x86, nonSxS, pkt {l:8 b:31bf3856ad364e35} in the store, hash mismatch
2015-12-08 08:50:43, Info CSI 00003c3c [SR] This component was referenced by [l:125]"Microsoft-Windows-RemoteFX-VM-Setup-Package~31bf3856ad364e35~amd64~~10.0.10586.0.RemoteFX clientVM and UMTS files and regkeys"
2015-12-08 08:50:43, Info CSI 00003c3d Hashes for file member \??\C:\WINDOWS\SysWOW64\opencl.dll do not match actual file [l:10]"opencl.dll" :
Found: {l:32 g2VAunZ6/2J1G3oL7kf9fjInPUA9VYeiJcl9VKgizaY=} Expected: {l:32 9rnAnuwzPjMQA7sW63oNAVhckspIngsqJXKYSUeQ5Do=}
2015-12-08 08:50:43, Info CSI 00003c3e Hashes for file member \SystemRoot\WinSxS\wow64_microsoft-windows-r..xwddmdriver-wow64-c_31bf3856ad364e35_10.0.10586.0_none_3dae054b56911c22\opencl.dll do not match actual file [l:10]"opencl.dll" :
Found: {l:32 g2VAunZ6/2J1G3oL7kf9fjInPUA9VYeiJcl9VKgizaY=} Expected: {l:32 9rnAnuwzPjMQA7sW63oNAVhckspIngsqJXKYSUeQ5Do=}
2015-12-08 08:50:43, Info CSI 00003c3f [SR] Could not reproject corrupted file [l:23 ml:24]"\??\C:\WINDOWS\SysWOW64"\[l:10]"opencl.dll"; source file in store is also corrupted
Okay, so the issue is clear now. Unfortunately, SFC is unable to resolve the corruption because the local component store also got corrupted. Unfortunately, I lost the error messages indicating the component store corruptions.
So I tried Dism /Online /Cleanup-Image /RestoreHealth
to no avail. It fails with error 0x800f081f, indicating another problem with the source files.
2015-12-08 08:57:35, Info CBS Exec: Download qualification evaluation, business scenario: Manual Corruption Repair
2015-12-08 08:57:35, Info CBS Exec: Clients specified using Windows Update.
2015-12-08 08:57:35, Info CBS WU: Update service is not default AU service, skip. URL: https://fe2.update.microsoft.com/v6/, Name: Microsoft Update
2015-12-08 08:57:35, Info CBS WU: Update service is not default AU service, skip. URL: https://fe2.ws.microsoft.com/v6/, Name: Windows Store
2015-12-08 08:57:35, Info CBS WU: Update service is not default AU service, skip. URL: https://fe3.delivery.mp.microsoft.com/, Name: Windows Store (DCat Prod)
2015-12-08 08:57:35, Info CBS WU: WSUS service is the default, URL: (null), Name: Windows Server Update Service
2015-12-08 08:57:35, Info CBS DWLD:Search is done, set download progress to 20 percent.
2015-12-08 08:57:35, Info CBS Nothing to download, unexpected
2015-12-08 08:57:35, Info CBS Failed to collect payload and there is nothing to repair. [HRESULT = 0x800f081f - CBS_E_SOURCE_MISSING]
2015-12-08 08:57:35, Info CBS Failed to repair store. [HRESULT = 0x800f081f - CBS_E_SOURCE_MISSING]
Looking at the error messages, it becomes clear that Windows is set to use our local WSUS server and therefore Dism is unable to retrieve the valid file from the repositories. While I am sure that I could somehow configure WSUS to provide the necessary files, I don't know how and I need a quick fix. (If someone knows how to configure WSUS accordingly, please provide information).
Limiting access to the local storage by adding the paramter /LimitAccess
would be useless as the local component store is also corrupted, as mentioned earlier.
I experienced this issue on two machines. A refresh of Windows 10 did not fix the issue.
To fix this problem, you need to have the ISO of the exact build you have installed.
mkdir C:\WIM
Dism /Mount-Wim /WimFile:D:\sources\install.wim /index:1 /MountDir:C:\WIM /ReadOnly
Dism /Online /Cleanup-Image /RestoreHealth /Source:C:\WIM\Windows /LimitAccess
Dism /Unmount-Wim /MountDir:C:\WIM /Discard rmdir C:\WIM
That should fix the issue.
Edit
As pointed out in the comments, there might be a more direct approach. The TL;DR is, that it did not work for me, hence my more detailed approach. But I am interested if you had any problems with the direct approach. Please comment.
From various forums on the Internet, I've assembled following repair procedure:
MediaCreationTool.exe
toc:\temp\windows.iso
c:\temp\windows.iso
to folderc:\temp\windows
Convert
install.esd
toinstall.wim
Check index and windows version in
.wim
file-
index is used for next Dism command in parameter/Source:wim:path_to_wim:[index]
Restore health windows components from downloaded and converted windows image (wim):
Repair corrupted files:
It will repair corrupted files - success message:
Windows Resource Protection found corrupt files and successfully repaired them.
Check System files again to be sure for succesfull repair:
Success message after scan:
Windows Resource Protection did not find any integrity violations.
An ESD is not an "encrypted" WIM, it is a WIM that has been highly packed/reencoded very differently (with a more complex structure).
A WIM is just "fast" compressed by unbreakable units of 4KB or 16KB, using a fast Huffmann compression. An ESD uses more advanced LZ-based compression without block size limitations. This compresssion does not allow the image to be open in read-write-mode as the compression is global (each file in the archive is no longer compressed separately, multiple logical files can share the actual storage of segments, to reach a mush higher compression level, notably when there are many small files with common headers parts, such as collections of icons, or parts of their digital signature data, copyright notices, HTML headers, embedded scripts and so on).
An SWM is a multipart WIM that has been split in multiple files with smaller sizes with a (rough) maximum size, but it is still writable, and can be stored on multiple DVDs.
CBS providers allow several archiving formats that can be supported by DISM, including WIM, CAB, ZIP, VHD, VHDX, multisession ISOs... But Windows comes with two builtin providers for the WIM and ESD formats (ESD is new to Windows 10, with Windows 8, only the WIM format was supported, but the images were larger)
The ESD format has been tuned for allowing the full multilingual distribution of Windows 10 to fit on a single DVD with less than 3GB...
You can transform an ESD to WIM, but the result will be a much larger file. The inverse conversion is also possible (so that you can read-write in the expanded WIM) to pack it again into a new ESD. Decompressing an ESD to WIM is relatively fast, but compressing a WIM to ESD requires lot of CPU ressources and is much longer (that's why you can't read-write directly into an ESD but you can do that quite easily in a WIM with modest CPU usage).
When you "mount" an ESD with DISM, the first thing it will do is to expand the ESD into a temporary storage and act on it as if it was a WIM, so that you can update files in this local storage. Unmounting it will require two steps: recreating a WIM (quite fast), and then pack it again into an ESD (very slow).
I solved the problem with opengl.dll as follows:
Mount the Windows 10 image.
Dism /Online /Cleanup-Image /RestoreHealth /Source:esd:F:\sources\install.esd\1\Windows\WinSxS\wow64_microsoft-windows-r..xwddmdriver-wow64-c_31bf3856ad364e35_10.0.10586.0_none_3dae054b56911c22\
sfc /scannow
Good luck!
I spent a few days going down these paths and finally found a solution for my situation. I'm running Windows 10 version 1511 Build 10586.545. Here is my progression:
From here, Windows Update started working again.
So in summary, if you're struggling with these errors and nothing seems to work, try disabling the NVIDIA GeForce drivers and then trying some of these steps (or manually copying in a clean version of the DLL).
Due to not having a local copy and for a separate reason unable to download the ISO file (the ISO was not of the Windows 10 type I have installed) There is a hotfix solution here which I used which involves downloading a specialist file called "SFCFix":
Please note that running the SFCFix.exe file without the hotfix ZIP will be a long slow process that achieves very little, you need to run it with the ZIP file drag/drop method, and the result is almost instant.
You should be able to utilize an esd image, per the DISM technet article. An ESD (Electronic Software Delivery) image is simply an encrypted version of a WIM, and also happens to utilize a far better compression algorithm than the WIM format does (generally around 1.5x better compression).
If all one has is an ESD, but would rather use a WIM, you can convert an ESD to WIM with the DISM export command. You can also convert a WIM to ESD by specifying /compress:recovery within export or capture command. Converting one to the other is resource intensive, and because of this, it's recommended to utilize the ESD to WIM script that was written years ago and is available on the MSFN forum. Utilizing the script, only ~50% of system resources are dedicated to the export versus the 90%+ that is generally utilized for the export.
I just went to another Windows 10 Pro x64 machine and copied the opencl.dll file (from the same directory). Then I took ownership of the bad opencl.dll, renamed it to opencl.old, and copied in the new one. Reboot back into safe mode and run sfc /scannow and it comes back good. In my case, this was the ONLY bad file listed in cbs.log ... I can see where it might be better to have sfc work if you have many corrupt files and don't want to patch each individually. But if your problem is just the one dll, then a simple copy seems to work.
It seems that the install image (
install.esd
) from the Creator's Update installation media is incompatible with the DISM method described here. You will get error0x800f081f
no matter which kind of command you type. It also does not help to extract the correctinstall.wim
out of the ESD file. Finally, I even tried mounting the WIM file to no avail as well.See also discussions at https://www.sysnative.com/forums/windows-10-a/22564-dism-error-0x800f081f.html#post179723
Update: The persisting error has nothing to do with the dism command or the wim files. It is due to a package named Microsoft-Windows-TestRoot-and-FlightSigning-Package for which no working sources are available. The files are in C:\Windows\Servicing\Packages and have to be moved away from there. Also, there are two references in the registry which have to be deleted. See the linked sysnative thread for details.