Corrupted files - DISM or SFC results more accurate?

mikolajek · 16 Nov 2015

I've just built a completely fresh installation of the latest build of Win 10 Pro x64 (10586.3, also referred to as 1511).

I've done the necessary apps installs, software configuration and ended up with running SFC scan, which suggested my 'opencl.dll' library (related to some remote VPN, not nVidia drivers) was corrupted. I've run DISM that wasn't able to repair the issue by itself but when linked to source, it fixed the problem (well, at least it claimed to have fixed it). However SFC scans still end up with presenting the same issue...

I've tried DISM repair multiple times, each time apparently with success, but SFC still returns a hash mismatch for this dll. At the same time DISM integrity scans show no errors.

I've read that DISM is commonly considered a more reliable tool than SFC and SFC can sometimes return false positives when run. However, all discussions I've scanned referred to Windows 7 or 8/8.1 - none of them addressed the issue in Windows 10.

Moreover - I run SFC on my other machine that had been upgraded to Win 10 (from 8.1) some time ago and the same error appeared. Surprisingly here, after running DISM fix, SFC doesn't find any errors! The machine runs Win 10 Pro x64, exactly the same build! The only difference is that this one was upgraded and the other was freshly installed.

Thus, the question is - shall I be bothered by the fact SFC returns an error? Or shall I rather stick to DISM output which say everything is fine?

Kyhi · 16 Nov 2015

I would not worry about the hash mis-match.. if that is the only error sfc is pulling

mikolajek · 16 Nov 2015

Thanks, Kyhi! Yes, that's the only error - occurs twice in the CBS.log, but each time related to the same file (opencl.dll) and it's described as a hash mismatch.

However, it's a super-fresh install, so it would be nice to have it without any errors... Is that even possible with Windows?

That's the part of the output file:

Code:

2015-11-16 19:19:01, Info                  CSI    00004e23 [SR] Repairing 1 components
2015-11-16 19:19:01, Info                  CSI    00004e24 [SR] Beginning Verify and Repair transaction
2015-11-16 19:19:01, Info                  CSI    00004e26 [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-11-16 19:19:01, Info                  CSI    00004e29 [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-11-16 19:19:01, Info                  CSI    00004e2a [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-11-16 19:19:01, Info                  CSI    00004e2d [SR] Could not reproject corrupted file [l:23 ml:24]"\??\C:\Windows\SysWOW64"\[l:10]"opencl.dll"; source file in store is also corrupted
2015-11-16 19:19:01, Info                  CSI    00004e2f [SR] Repair complete

topgundcp · 16 Nov 2015

If you wish, you can try this:
Solved Corrupt files on 3 computers after upgrading to TH2 - Windows 10 Forums

mikolajek · 16 Nov 2015

Thank you, topgundcp! Apparently a miracle has happened

and it... worked!!! Kudos for you!

I can't tell if that's the particular image you proposed or anything else (as I did the trick with mounting files from the original installation media, created with the media creation tool - no luck though

), but the successful outcome is the most important!

Out of curiosity and for future reference - are you able to comment about the reason behind this? I mean that files extracted from this particular image work while the ones extracted from the original installation media (ESD USB stick) fail? Since the build is the same, I'd say the file source should make no difference...

topgundcp · 16 Nov 2015

They are not the same. The one downloaded from Media Creation Tool (install.esd) is in compressed format and cannot be mounted with DISM.

Ache · 18 Nov 2015

There is no point to restore opencl.dll because it will be overwritten again by NVIDIA driver installation, so this error will return back.

In details:

The correct fix will be to remove wrongly installed and activated by Microsoft wow64_microsoft-windows-r..xwddmdriver-wow64-c_31bf3856ad364e35_10.0.10586.0_none_3dae054b56911c22 directory (Microsoft RemoteFX Display driver, 32bit part, which contains opencl.dll with reduced functionality, which overwrites correct Nvidia/ATI/Intel \SysWoW64\opencl.dll on upgrade or attempt of DISM recover from install.wim) from WinSxS (64bit counterpart is in amd64_rdvgwddmdx11.inf_31bf3856ad364e35_10.0.10586 .0_none_5fcf2a87752df0d7 directory, but is inactive and does no harm). But I know no tool for correct selective remove or deactivate of specific directory from WinSxS. Since \SysWoW64\opencl.dll is hardlink to WinSxS one, attempt to install Nvidia/ATI/Intel driver corrupts two Microsoft opencl.dlls at once (so sfc /scannow fails to recover), and attempt to recover WinSxS one from install.wim damages Nvidia/ATI/Intel display driver's opencl.dll from other hand.