Fixing Corrupted System Files on Windows with SFC and DISM

Unexplained crashes, missing functionality, or errors referencing missing or invalid system files point at corrupted Windows system files — sfc and DISM are the two built-in tools for finding and fixing this, and understanding how they relate to each other matters more than treating them as interchangeable.

Step 1: run System File Checker first

sfc /scannow

Run this from an elevated Command Prompt or PowerShell. sfc compares your actual system files against Windows’ own known-good cached versions, replacing any that don’t match.

Step 2: read the result carefully

"Windows Resource Protection did not find any integrity violations."
  → system files are fine; the problem is elsewhere

"Windows Resource Protection found corrupt files and
 successfully repaired them."
  → fixed; restart and verify the original problem is gone

"Windows Resource Protection found corrupt files but was
 unable to fix some of them."
  → this is where DISM comes in

Step 3: if sfc couldn’t fix everything, run DISM to repair the underlying image

DISM /Online /Cleanup-Image /RestoreHealth

This is the key relationship to understand: sfc repairs files using a local cache of known-good versions, but if that local cache is itself corrupted, sfc has nothing valid to restore from. DISM repairs the underlying Windows image (the source sfc draws its known-good files from) using Windows Update as a source by default — fixing the cache that sfc depends on.

Step 4: run sfc again after DISM completes

sfc /scannow

With a repaired underlying image, running sfc a second time can now succeed at fixing files it couldn’t repair on the first pass, since its reference cache is no longer corrupted.

Step 5: if DISM can’t reach Windows Update, point it at a local Windows image

DISM /Online /Cleanup-Image /RestoreHealth /Source:D:\sources\install.wim /LimitAccess

Useful on a machine without reliable internet access, or where Windows Update itself is part of what’s not working correctly — pointing DISM at a Windows installation ISO’s install.wim file as an alternative source achieves the same repair without needing Windows Update.

Step 6: check the CBS log for details on what was actually found

findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log > sfcdetails.txt

For understanding exactly which files were flagged and what happened to them, rather than just the summary message sfc prints to the console.

Step 7: reboot and confirm the original problem is actually resolved

System file corruption repairs don’t always take full effect until after a restart — confirm the specific symptom that prompted this whole investigation is actually gone, rather than assuming a clean sfc result alone means the underlying problem is fixed.

Why running DISM before a second sfc pass is the sequence that actually works

Running sfc repeatedly without ever running DISM will not fix files when the root cause is a corrupted local repair cache — no matter how many times you run it, sfc can’t restore from a reference it doesn’t have a valid copy of. This exact sequence — sfc, then DISM if needed, then sfc again — reflects the actual dependency between the two tools, rather than being an arbitrary order to follow.

Checking image health before attempting a repair

DISM /Online /Cleanup-Image /ScanHealth

Before committing to a full /RestoreHealth repair pass (which downloads data and takes real time), /ScanHealth performs a more thorough check than the faster /CheckHealth flag and reports specifically whether the image is flagged as repairable — worth running first to confirm corruption actually exists and is addressable via this path, rather than jumping straight into a repair attempt for a problem that might have an entirely different root cause DISM was never going to fix.

Why sfc alone sometimes reports success but the original symptom persists

A clean sfc /scannow result confirms system files matched their expected known-good state at the time of the scan — it does not mean every possible cause of system misbehavior has been addressed, since plenty of Windows problems (driver issues, corrupted user-level application data, registry misconfiguration outside what sfc covers, hardware problems) have nothing to do with core system file integrity at all. Treating a clean sfc/DISM result as ruling out file corruption specifically, rather than as proof the original symptom’s root cause has been found, keeps the troubleshooting scope accurate — a clean result is useful negative information, directing further investigation elsewhere, not necessarily a dead end.

Running both tools proactively, not only reactively

Because corruption can accumulate silently — a failing sector affecting a rarely-accessed system file, an interrupted update leaving a partial write — running sfc /scannow and DISM /Online /Cleanup-Image /ScanHealth periodically on an important machine, rather than only after symptoms already appear, can catch and fix corruption before it manifests as a visible problem at all. This is a reasonable addition to routine maintenance for a production or otherwise critical machine, considerably cheaper than diagnosing a mysterious failure after the fact once corruption has already caused a visible, disruptive symptom.

Related:

Sources: