Free CBS.log reader
sfc found corrupt files
and won't say which.
CBSDoctor lists every component file your CBS.log names — unrepairable, repaired and hash-mismatched — with the owning package, version, architecture and line number for each. It reads logs up to 32 MB line by line, and the recipe below turns a bigger one into a stream, so nothing is skipped for size.
- Read in your browser; your file is never uploaded
- No account, cookies, analytics or ads
- Free — donations only
“Details are included in the CBS.Log”
sfc /scannow finishes and says: Windows Resource Protection found corrupt files but was unable to fix some of them. Details are included in the CBS.Log. Windows has told you there is damage and declined to say what.
The details really are in there. Microsoft's own guidance is to open a text file that routinely runs to hundreds of megabytes and search for [SR] — which is accurate advice and a poor experience, since Notepad struggles and the matching lines wrap across several rows.
This page reads the whole log as a stream and lists every [SR] line that names a file, with its owning component, version, architecture and line number — plus every HRESULT, every session boundary and the build identity the log states.
Turn a huge CBS.log into a 300 KB extract
Microsoft's own extraction recipe turns the log into something small. Run this in an elevated Command Prompt:
findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log >"%userprofile%\Desktop\sfcdetails.txt"
That writes sfcdetails.txt to your desktop with the resource-protection lines only. Drop that instead — it is accepted here and carries the file names.
The full log is still worth uploading if you can: it also contains the HRESULTs, the package references and the session boundaries, which the filtered extract drops.
What the [SR] lines record
| Line in your log | What it records |
|---|---|
| [SR] Cannot repair member file [l:N]'name' of COMPONENT, version V, arch A | The scan could not restore this file from the component store. The line gives you the file, the owning component, and the exact version — which is what any repair source has to match. |
| [SR] Repairing corrupted file / Repaired file | A file that was restored. Most logs contain both this and the line above. |
| [SR] Could not reproject corrupted file | The store had the payload but the file could not be written into place. A different line from “cannot repair”, and worth distinguishing. |
| Hashes for file member ... do not match | A file on disk differs from what the store expects. Damage produces this line — and so does a deliberate replacement by other software. The log records the difference, not the reason. |
| [SR] This component was referenced by [l:N]'PACKAGE' | Which package owns the component. Collected and counted, because the package set is what a repair source has to contain. |
| [SR] Verifying N components | The scan's scope. |
| [HRESULT = 0x800f081f] | Source files were not found. Shown with its count and first line number. |
| [HRESULT = 0x800f0831] | A package could not be opened from the store. |
The CBS.log lines worth finding, and what each records
Microsoft’s own guidance for this file is to search it for [SR]. These are the lines that search is looking for. Each one below is extracted here with its line number.
| What you will see in the file | What it records |
|---|---|
[SR] Cannot repair member fileCSI [SR] Cannot repair member file [l:12]'user32.dll' of Microsoft-Windows-User32, version 10.0.19041.1 | The line that matters most: one component file sfc could not fix, named, with its owning package and version. [l:12] is the length of the name that follows, not a line number. |
Hashes for file memberCSI Hashes for file member \SystemRoot\WinSxS\amd64_user32\user32.dll do not match actual file | The full line reads Hashes for file member <path> do not match actual file — the path sits in the middle, which is why searching the sentence Hashes for file member do not match as one phrase finds nothing. It is a statement about a comparison, and a legitimately modified file produces the same line as a damaged one. |
0x800f081fCSI Repair failed with 0x800f081f | The source needed for the repair was not found. This is the code that makes the DISM /RestoreHealth /Source: step necessary, and why the source has to match your exact build. |
0x800f0831CBS Failed to find a matching package with 0x800f0831 | A specific update package is missing from the store, so the repair could not find a known-good copy to work from. |
Build, edition and architecture, from the log itself
Component version strings such as 10.0.26100.1 state the build. Package names carry edition wording. The arch field on each member line states the architecture.
All three are extracted and shown with the evidence they came from, because they are what any repair source has to match — and because a report that guessed them would send you after the wrong image.
This is read from your log, not from your running system. If the log is old, the identity is the identity at the time it was written.
Why a long log is fine
The log is read one line at a time and only bounded summaries are kept: counters, and up to 800 entries per category, so a log at the 32 MB limit costs a few megabytes of working memory and no temporary file is ever written. Past that limit, use the extract above — it holds every [SR] line the report reads anyway.
The coverage figure at the end of the report tells you how many lines were read, how many matched the CBS line form, and lists the ones that did not, with samples — so “we read all of it” is a number you can check rather than a claim you have to take on faith.
Frequently asked questions
It found no [SR] lines in my log. Why?
CBS.log covers all servicing work, not only resource-protection scans, and it rotates into CbsPersist_*.cab archives as it grows. Your scan may be in one of those archives. The report says this plainly rather than showing an empty result.
Can it open CbsPersist_*.cab?
Not in this version. Those are MSZIP cabinets and reading them is a separate piece of work; it is listed as a limit in every report rather than quietly ignored.
Does a hash mismatch mean a file is damaged?
It means the file differs from what the component store expects. Deliberate replacements by other software produce the same line. The log records the difference and nothing about its origin, so neither does this page.
Will it tell me the DISM command to run?
It gives you the facts that command needs — build, edition, architecture and the affected packages — quoted from your log with line numbers. It does not assert that running any particular command will fix your machine.
Is a big CBS.log really parsed in memory?
Yes, line by line inside your own browser. Nothing is uploaded and nothing is written to disk at any point.