News Stay informed about the latest enterprise technology news and product updates.

Ouch! SFC and DISM may disagree in Build 10586.17

Every now and then, things happen in Windows-world that defy common sense, not to mention best practices. I’ve become a somewhat obsessive user of the system file checker (SFC) and the deployment image servicing and management (DISM) commands lately checking on the health and well-being of my system files (SFC) and image/component store (DISM). DISM works as sort of a backstop for SFC, so that when you can’t manually repair corruption or issues that the file checker detects, you can use the /restorehealth option in DISM to repair those files programmatically — at least, most of the time.

In the wake of a recent Nvidia driver update (395.06) and the latest Cumulative Update to Windows 10 (KB3116908, for x64 systems, which takes the Build number up to 10586.17) these two tools have fallen out of step with one another. Here’s a screenshot from one of my Nvidia-equipped PCs that shows the mismatch (I understand some AMD/Radeon drivers have also occasionally fallen prey to the same kind of thing, too):


Ordinarily, if one finds problems, so does the other; not this time!

In reading up on this issue (links to two good discussions, one at, the other at the Nvidia forums are also worth following) I learned that there’s a difference between the vendor version of opencl.dll that Nvidia wants to use (which ranges between 110 and 120KB in size, depending on recent driver versions) and the generic version of the same file that Microsoft provides (about 30K in size, which MS seems to insist on finding at the moment, even though best practice is to defer to manufacturer driver versions for that maker’s own hardware). If you look at the CBS log file that SFC produces, you’ll quickly see that all of its “corruption” complaints come from that single file in multiple locations, because it doesn’t match what MS expects to find. Yet DISM reports the component store is OK, as the screencap shows.

I’m not sure exactly what to do next, and have to agree with a recent poster to TenForums that the best strategy is to “…wait for MS to fix their problem.” In other words, “If it ain’t broke, don’t fix it” has to be the watchword here!