Problems with DISM

You should run the DISM command first.
DISM /Online /Cleanup-Image /RestoreHealth

Then sfc /scannow

Reason is running DISM first repairs the underlying image that SFC relies on to get repair files from.

If the image has corruption and you run SFC first you are potentially replacing good files with corrupted ones from a bad source (Image).

why not just ignore sfc and run DISM /Online /Cleanup-Image /RestoreHealth /Source:WindowsUpdate

kelper said:

why not just ignore sfc and run DISM /Online /Cleanup-Image /RestoreHealth /Source:WindowsUpdate

Click to expand...

By default DISM /Online /Cleanup-Image /RestoreHealth repairs corrupted system files by checking the Windows image for damage and automatically downloading replacements from Windows Update.

No need for the WU switch as WU is already used by default.

Only time you need to use the source switch is if pointing to install.wim or some other local source.

No, that's not correct. It will use WU, but that is not the default.

kelper said:

No, that's not correct. It will use WU, but that is not the default.

Click to expand...

Yes it is unless you have group policy set to use some other source or use the source switch.




Source

There may be some truth in what you say and we may be at cross purposes. My understanding is this.

DISM /Online /Cleanup-Image /RestoreHealth operates on the online Windows installation and primarily uses the Windows component store (C:\Windows\WinSxS) to check for corruption and repair system files. By default, it will attempt to use Windows Update as a source if it needs replacement files that are missing or corrupted in the component store. If the component store itself is damaged, you can specify an alternate source with the /Source option.

So in short: the component store is always involved; Windows Update is only used if necessary.

The component store is involved because that's what is being scanned for corruption. It can't get replacement files from the component store if that's what is corrupted.

The source for correct files is whatever Features on Demand is configured to use. That's Windows Update by default and if allowed by policy. You can also use a mounted WIM, a shared \Windows folder from a working PC on the network, Windows installation files like you would find in the ISO, etc.

FreeBooter said:

Do you know why we don't execute Dism /Online /Cleanup-Image /RestoreHealth command from recovery environment?

Click to expand...

Because of the /Online switch and you are not inside the windows environment but inside the recovery environment. Normal Windows has not been started. The 2 commands I gave only works if your system has booted with Windows.

In a recovery environment you have to tell where Windows "lives".
(It does not know at that moment. De X-drive is a symbolic link towards the C-drive. With other words X and C are the same.)

You have to alter the DISM command into:
X:\Windows\System32>Dism /Image:C:\ /ScratchDir=C:\Windows\Temp /Cleanup-Image /RestoreHealth

If you leave out the /ScratchDir argument it will complain. (because it's afraid that there in enough space.)

The scratch directory size might be insufficiënt to perform this operation. This can cause unexpected behavior.
Use the /ScratchDir option to point to a folder with sufficient scratch space. The recommended size is at least 1024 Mb.

Click to expand...

It does not matter if you use this option or not. It will not write any files to that location.
But you can see the results in the C:\Windows\Logs\CBS\CBS.log file and C:\Windows\Logs\DISM\dism.log file if you want. (using notepad. Leave out the .exe part) When in the Recovery Environment go to: Solve Problems - Advance options - CommandPrompt and simply execute the mentioned command.

Edit: Just found this out; SFC /Scannow inside a Recovery Environment is untrustworthy. It keeps finding problems. Go to Windows? SFC: No problems. Back again in the Recovery Environment? SFC: Problems. Executing a second time inside the Recovery Environment; It will refuse. There are repairs pending. Go To Windows? SFC: No Problems. Recovery? SFC: Problems. It seems to me that this command is not fit to be executed inside a recovery environment. It always report errors and fixed them. No evidence that it wrote into CBS.log as mentioned. Would avoid executing it.