Windows 10: Corrupted files - DISM or SFC results more accurate?

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... *Sad

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. *Huh

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. *Mad

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?

:)

 

(Solved) Windows 10 pictures File Explorer crashes immediately after "working on it" message

sfc indicates corruption, but your dism screenshot doesn't show the final result of running the command. If dism says it fixed corrupt files then run sfc again to check.

 

Had update error code 0xc0000005 when windows tries to update to latest version of 10.

Looks like there some serious damage to system files. What were the results of DISM? Often DISM corrects those corrupt files which SFC cannot.

 

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

 

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? *Wink

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[/quote]

 

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

 

Thank you, topgundcp! Apparently a miracle has happened *Wink 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 *Sad), 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...

 

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

 

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.