Run SFC Command in Windows 10  

mike ten said:

BTW, I found a file install.esd;
Should I continue with the Dism?

No need since everything currently checks out.

Bree said:

There is one other type of successful repair that SFC can perform that would not appear in that filtered list, one where the file is not corrupt, but its permissions and/or ownership are. As the file does not get replaced it doesn't appear in the log with an [SR] entry. Searching the log for the keyword 'twice' will find them.

Bree, Farvatten,

Thanks for explaining this.

I've altered my CBS extraction to this

Code:

findstr.exe "Warning [SR]" %windir%\Logs\CBS\CBS.log

It returns all [SR] entries and all entries containing Warning.

{I found it necessary to put Warning first in the search terms rather than [SR] to get the FindStr search to operate as an OR search in the expected manner.}

@Brink - I think this might be worth including in Option 5.

Bree - I chose Warning before I noticed you'd gone for twice. I think both are as good as each other for the current case but, for all I know, there are other cases that nobody has reported because none of us have gone looking for them. Warning seems to me to be more likely to appear in those unknown cases.


All the best,
Denis

Farvatten said:

For what it's worth, these "Warning: Overlap: Directory... is owned twice or has its security set twice" appear in all my SFC /scannow's that come back and report clean with:
'Windows Resource Protection did not find any integrity violations.'

Yes.

The reports of owned twice or has its security set twice are made when SFC's manifest sees what it thinks is a difference in permissions even though the permissions are, in effect, the same.
A folder might be set with permissions as shown in the upper part of this diagram but SFC's manifest might be expecting them to be set as shown in the lower part [below the green line]. Or vice versa.

A few Versions ago, SFC used to report these as faults [irreparable ones] and this was discussed in the forum.
We thought, as far as I recall, that the problem was caused by a discrepancy between the SFC manifest & the permission-setting instructions in individual Windows Cumulative updates.
I have not kept a link to any relevant threads but that screenshot of differing-yet-equivalent permissions arrangements is dated 28th July 2019 when I was on Version 1903. I think that must have been when we were discussing the subject here.
Perhaps MS tweaked SFC to stop it calling them faults rather than fix the software configuration problem that this behaviour exposed.


All the best,
Denis

Hi, would it be worth expanding Options 1 and 2 section 3 to illustrate the case for UEFI cases? Thanks.

dalchina said:

Hi, would it be worth expanding Options 1 and 2 section 3 to illustrate the case for UEFI cases? Thanks.