How to Run SFC Scannow to Repair Windows System Files

What sfc /scannow actually does

System File Checker compares each protected system file — the DLLs and executables Windows itself runs from — against the known-good copies held in C:\Windows\WinSxS. When a file on disk differs from the reference copy, SFC replaces it; when the reference copy in the store is itself damaged, SFC reports the file but cannot repair it, which is exactly the situation DISM exists for. The scan needs an elevated console: Win+X → Terminal (Admin). It reads the local disk only, so no internet connection is required.

You reach for SFC when Windows misbehaves in ways that point at its own files: after a failed update, a hard power-off during servicing, or malware removal that left damage behind. The command is completely safe for personal data — it never scans or modifies user profiles, documents or the applications' own folders.

• After a Windows update that fails midway or rolls back again and again
• When BSODs such as CRITICAL_PROCESS_DIED or IRQL_NOT_LESS_OR_EQUAL start without a hardware reason
• After malware removal, to verify the system files survived intact
• When built-in apps, the Start menu or Settings crash on open
• Before an in-place repair upgrade — maybe a 20-minute scan saves the hour-long reinstall
• When DISM or Windows Update itself reports store corruption

Running SFC and reading the result

Open Terminal (Admin) via Win+X or by right-clicking Start, type sfc /scannow and press Enter. The scan shows a percentage and typically finishes in 5–20 minutes — noticeably longer on old HDDs — and the console must stay open until it completes. Four outcomes are possible, and each maps to a distinct next step.

“Windows Resource Protection did not find any integrity violations” means the system files are clean — look elsewhere for the fault. “Found corrupt files and successfully repaired them” is the win: reboot so the repaired files actually get loaded. “Found corrupt files but was unable to fix some of them” points at a damaged component store: run DISM /Online /Cleanup-Image /RestoreHealth, then repeat the SFC pass. “Could not perform the requested operation” almost always means pending servicing operations — reboot and try again.

When SFC fails: DISM first, then repeat

SFC can only be as healthy as the component store it repairs from, so the working ladder is DISM RestoreHealth → sfc /scannow → reboot. The details of every repair land in C:\Windows\Logs\CBS\CBS.log; filter it with findstr /c:[SR] %windir%\Logs\CBS\CBS.log to see only the SFC lines. Useful variants exist for specific cases: sfc /verifyonly runs the comparison without changing anything, and sfc /scanfile=C:\Windows\System32\broken.dll targets a single file.

A word of warning about the store SFC depends on: never delete anything inside C:\Windows\WinSxS by hand, and do not let third-party “cleanup” tools prune it either — a gutted store turns every future SFC run into a report of unfixable corruption. Use the official StartComponentCleanup route instead. Running SFC routinely is pointless: launch it on suspicion and after incidents, not on a schedule.

Questions and Answers

Read next

All articles · FAQ