SFC found corrupt files after Windows update - never had any before

I am wondering if this is a false result and there are not really any corrupted files.


My computer (Windows 7 x64) is about 2 years old, and has been a very clean computer. I update my image periodically with minimal applications on the image (Microsoft office, Chrome are only extra programs on the image) each time. My latest image is from late November of this year (updated to that point.)

I run SFC /scannow periodically just to monitor my system to see if any problems. I usually run it after Windows update. I had run it just yesterday as a periodic check, and no integrity violation were found. Today, after a fairly large Windows update (1 Internet Explorer update, 6 X64-based Systems updates, 1 Malicious Software tool for December 2014, 1 X64 security update, and 5 Microsoft Office updates), I ran sfc /scannow and it stated: Windows Resource Protection found corrupt files but was unable to fix some (or all) of them

Again, this was the first time I ever did not have the "Windows did not find any integrity violations" results and I do sfc /scannow at least once a month.

I extracted the CBS.log results with findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log >"%userprofile%\Desktop\sfcdetails.txt"

It states:

2014-12-10 11:36:12, Info CSI 00000009 [SR] Verifying 100 (0x0000000000000064) components
2014-12-10 11:36:12, Info CSI 0000000a [SR] Beginning Verify and Repair transaction
2014-12-10 11:36:12, Info CSI 0000000c [SR] Verify complete

and repeats that (I assume - I did not count them) 100 times with the 3rd column changing each line but everything else is the same each time these three lines repeat (for example, no specific file is ever listed)

Then after all those (0x000..0064) 3 lines are repeated, it states only 1 time:

2014-12-10 11:38:53, Info CSI 00000309 [SR] Verifying 90 (0x000000000000005a) components
2014-12-10 11:38:53, Info CSI 0000030a [SR] Beginning Verify and Repair transaction
2014-12-10 11:38:54, Info CSI 0000030c [SR] Verify complete

Then after that single (0x000..005a) listing the sfcdetails.txt results end with:

2014-12-10 11:38:54, Info CSI 0000030d [SR] Repairing 0 components
2014-12-10 11:38:54, Info CSI 0000030e [SR] Beginning Verify and Repair transaction
2014-12-10 11:38:54, Info CSI 00000310 [SR] Repair complete


To me these results seem strange. On a past computer, which would have corrupted systems files from time to time, the same process above would usually list the exact file and whether it was repaired or not for each repair attempt. The above never list a single file and it states it is repairing 0 components as if it did not even try to repair anything.

Please note, I checked my drive (an SSD), and memory. No problems were found with either. So, I am pretty sure no system hardware is causing the Windows Update to corrupt files.

Any ideas?

Also, I want to add:

I did narrow it down to the WIndows Update causing these results.

I refreshed my latest image from 11-22-14. After getting back into the refreshed computer. I ran sfc /scannow and it reported Windows did not find any integrity violations.

I then ran Windows update, which install the same updates, I listed above. I then restarted my computer as the update suggested.

I then ran sfc /scannow and it found: Windows Resource Protection found corrupt files but was unable to fix some (or all) of them

I then extracted the cbs.log file and the results sfcdetails.txt seemed the same as before as described above. Note: I forgot to save the sfcdetails.txt file before I did a refresh of my image to compare verbatim but it seems exactly the same.

Has anyone else ran sfc /scannow since the Windows 7 update yesterday/today? I am wondering if the update is doing this for others.

Pauly said:

Have you tried rebooting and re-running sfc scan, can sometimes take up to three scans to fix all problems
Generally it only needs three goes if you are suffering boot issues but worth a try

Twice (same results.) ANd just did a third (same results.)

But I do not think SFC scan is doing anything as far as repairing because the sfcdetails.txt shows no repair attempt on any file (no file is every listed anywhere in the results), and the sfcdetails.txt ends with the following below, and that is the only time sfcdetails.txt ever states anything about repairing (in the Repairing 0 components is the only time the word "repairing" is in sfcdetails.txt.)

2014-12-10 11:38:54, Info CSI 0000030d [SR] Repairing 0 components
2014-12-10 11:38:54, Info CSI 0000030e [SR] Beginning Verify and Repair transaction
2014-12-10 11:38:54, Info CSI 00000310 [SR] Repair complete

This is why I am wondering if this is some kind of WIndows Update bug and there are not really any corrupted system files.

Urthboundmisfit said:

nine9s said:

Has anyone else ran sfc /scannow since the Windows 7 update yesterday/today? I am wondering if the update is doing this for others.

My system is clean as a whistle, but after reading your posts I ran sfc /scannow & got same results...
investigating further.
Attachment 342729

Thank you for checking. Sorry it is happening to you, but I take it is a good news because it means I do not have an isolated problem, and it adds to evidence this is a false result from some Windows Update bug I assume. I guess I am the canary in coal mine on this, as I doubt many people run an sfc scan after every Windows Update as I do.

Did you extract sfcdetails from your cbs.log file? If so, is it same as mine as far as never listing a single corrupt file and not trying to repair anything?

Urthboundmisfit said:

...I think it has to do with "C:\Windows\winsxs\Temp\PendingRenames": This folder contained over 2000 items shortly after running the sfc /scannow command. I vaguely remember reading about a bug in Win 7's sfc "scavenge" process which sometimes does not clean up after itself resulting in "Windows Resource Protection found corrupt files but was unable" message.

Looking for link...

My "C:\Windows\winsxs\Temp\PendingRenames" has 1792 files.

And when was checking it. I noticed I have no PendingDeletes folder at the same location (I am not sure if there should be one or not - perhaps that is part of problem.)

I browsed through the cbs.log file, and for each one of those summarized sfcdetails.txt listing no file is listed as being repaired. Instead it keeps listing that it is "move file" in the pendingdelete folder.

Also, the word "repairing" is only listed twice in my entire cbs.log file and both times it states repairing 0 components. I assume this means the sfc scan did not attempt to repair anything which implies it really found nothing corrupted, no?