Match the symptom before changing settings
| What you observe | Where to focus |
|---|---|
| SFC repaired files | Restart and verify the original problem |
| SFC found corruption but could not repair | Run DISM RestoreHealth, then SFC again |
| Windows Resource Protection could not perform operation | Check servicing state and run offline when appropriate |
| Corruption returns repeatedly | Check storage, unsafe tools and malware |
Diagnose System File Checker repair results with evidence first
Run SFC once and preserve its exact final message plus the CBS log location. The important distinction is whether SFC found corruption it could not repair, failed to run, or completed without integrity violations.
Tie SFC to the Windows symptom you are actually troubleshooting. If Windows otherwise works normally, avoid stacking unrelated repair commands just because SFC reports one protected file.
Complete these focused checks: save the complete SFC result; run commands in an elevated Terminal; confirm Windows Update and component source access; tie repair to an actual Windows symptom. Take screenshots or notes before changing firmware, encryption, recovery, driver or power settings. Those records provide a return path if the first repair does not help.
Use current Windows servicing components and matching installation media if DISM needs a source. Do not download replacement system files from unofficial websites.
Back up important files before deeper servicing work, especially if corruption follows crashes or storage errors. Keep BitLocker recovery information available before recovery-environment changes.
Repair the component store first
Run DISM /Online /Cleanup-Image /RestoreHealth and allow it to finish. SFC relies on the component store for healthy replacements.
Read the final SFC message carefully and keep the CBS log location before running another repair. 'Found corrupt files but was unable to fix some of them' is different from SFC failing to run at all.
1Verification checkpoint
- Run SFC after the repair step.
- Read the final message rather than only the progress percentage.
- If the same files remain unrepaired, preserve the CBS evidence.
Run SFC again and verify
Run sfc /scannow after DISM, restart and retest the original Windows feature rather than relying only on the summary.
Run DISM component-store repair before repeating SFC when Windows can still boot normally. SFC depends on healthy repair sources, so repeating SFC alone may produce the same result.
2Verification checkpoint
- Retest the Windows feature that originally failed.
- Confirm the user-visible symptom changed as well as SFC output.
- If only the log changed, keep diagnosing the original problem.
Escalate persistent corruption
Review relevant CBS entries, check storage health and use a supported repair reinstall if protected files remain damaged system-wide.
If DISM needs an alternate source, use media that matches the installed Windows edition, language, architecture, and release as closely as possible. A mismatched source can create new errors.
3Verification checkpoint
- Restart once and run a final integrity check if needed.
- Confirm corruption does not immediately return.
- Recurring corruption should trigger storage and stability checks, not endless SFC loops.
Interpret the result before escalating
If DISM completes successfully and the next SFC pass reports no integrity violations, the component store was likely preventing SFC from completing its repair.
If SFC continues to identify the same files, inspect the relevant CBS entries rather than assuming every reported item is user-visible corruption. Some files may be managed by optional features or servicing state.
If both SFC and DISM fail, the problem has moved beyond a simple system-file repair and may require a repair install, disk-health check, or recovery environment.
Verify the fix and choose the safe escalation
Run SFC once more after the repair path and confirm the final message. Do not judge success only because the command reached 100 percent.
Reproduce the Windows symptom that led you to run SFC in the first place. Clean SFC output is useful, but the actual feature or error should also be retested.
If corruption returns repeatedly, check storage health, unexpected shutdowns, and update failures before continuing to run SFC as a routine fix.
Technical order checked against current Microsoft guidance. Exact controls vary by Windows build, hardware, edition and organization policy.
Frequently asked questions
Should DISM run before SFC?
When repairing component corruption, Microsoft recommends DISM RestoreHealth before running SFC again.
Where are SFC details stored?
SFC writes servicing details to the CBS log; filter only the relevant entries instead of deleting the log.
Why does corruption return?
Storage faults, interrupted updates, malware or unsafe cleanup tools can damage files again.