Windows Repair Command Builder

Build the right SFC, DISM and chkdsk commands — in the order that actually works

Windows is misbehaving, something suggested you run sfc /scannow, and it came back with “Windows Resource Protection found corrupt files but was unable to fix some of them.” That message is the reason this page exists. SFC repairs damaged system files by copying known-good versions out of the local component store — so when the component store itself is damaged, SFC has nothing to copy from and fails. DISM is what repairs the store. Run them in the wrong order and you get a scan that finds problems it cannot fix; run them in the right order and the second attempt usually succeeds.

Pick a task, set the options that apply, and the builder gives you the exact command text to copy into an elevated prompt. It builds commands; it does not run anything, and nothing you type leaves the browser.

The four tasks it builds

That is the full extent of it. The builder does not emit sfc /scanfile, sfc /verifyonly, offline /offbootdir repairs, DISM /Cleanup-Image /StartComponentCleanup, or chkdsk /x, /b and the other less common switches. It covers the repair sequence people actually need and leaves the specialist flags to the documentation.

The order, and why it is not arbitrary

Take the full-repair output apart:

• DISM /Online /Cleanup-Image /RestoreHealth — /Online means “the running Windows installation” rather than a mounted offline image. /RestoreHealth scans the component store for corruption and repairs what it finds, pulling replacement files over Windows Update by default. This is the step that takes the longest, and its progress counter routinely sits at the same percentage for a long stretch; it is usually working, not stuck.
• sfc /scannow — scans all protected system files and replaces damaged ones from the (now repaired) component store. Running this after DISM is what turns the earlier “unable to fix” result into a successful repair.
• chkdsk C: /f /r — a different layer entirely. SFC and DISM deal with file contents; chkdsk deals with the filesystem structure and the physical disk underneath it. It goes last because it is the slowest and because it needs a reboot on the system drive.

Every command here requires an elevated prompt — right-click Command Prompt, Windows Terminal or PowerShell and choose Run as administrator. Without elevation, SFC reports that it must be run from an elevated command prompt and DISM refuses outright.

One practical note on the full-repair output: the comment lines start with REM, which is a cmd.exe convention. Paste the whole block into Command Prompt and the comments are ignored as intended; paste it into PowerShell and each REM line produces a “term is not recognized” error before the real commands run. The commands themselves work identically in both shells — only the comment lines are cmd-specific.

Choosing the DISM operation

If you are diagnosing rather than fixing, ScanHealth answers “is the store damaged?” without changing anything. If you already know something is wrong, skip straight to RestoreHealth — it does the scan itself.

Repairing without Windows Update: the /Source flag

RestoreHealth’s default behaviour is to fetch replacement files from Windows Update. That fails on a machine with no internet, on a network where Windows Update is blocked by policy, or when the update client is itself the thing that is broken — and it is a common cause of DISM error 0x800f081f, “the source files could not be found”.

Fill in the repair-source field and the builder switches to:

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

Two parts do the work. /Source: points at known-good files — typically install.wim from a mounted Windows ISO or USB installer, with :1 selecting the image index inside the WIM. /LimitAccess, which the builder adds automatically whenever you supply a source, tells DISM not to contact Windows Update at all. Without it, DISM may still try the network first and you will wait for that attempt to fail before your local source is used.

Two things to get right: the source media must match the installed Windows edition and build reasonably closely, and if your installer ships install.esd rather than install.wim, you will need to convert or export it to a WIM before DISM can use it as a source.

chkdsk: what /f and /r really mean

The two checkboxes are independent in the builder, so you can emit chkdsk C:, chkdsk C: /f, chkdsk C: /r, or chkdsk C: /f /r. Whatever you type in the drive box is reduced to a single letter and uppercased, so d:, D and d:\ all produce chkdsk D:.

• No flags — a read-only check. It reports problems and fixes nothing. Safe to run any time, and the right first move when you are not yet sure the disk is involved.
• /f — fix filesystem errors: lost clusters, cross-linked files, a damaged master file table. This is the flag that repairs the structure.
• /r — locate bad sectors and recover readable information. /r implies the work of /f, and it reads the entire surface of the volume, which is why the builder warns you about it: on a large disk it can run for hours, and on a drive that is already failing, that sustained full-surface read can be the thing that finishes it off. Back up first, then run it.

Any repairing run needs exclusive access to the volume, which is impossible on the drive Windows is running from. You will be asked whether to schedule the check for the next restart — answer Y, then reboot. The check runs before Windows loads, which is also why its output scrolls past on the boot screen rather than appearing in your prompt. The full-repair task includes a comment reminding you of exactly this, because a scheduled chkdsk that nobody reboots for simply never runs.

Which task fits which symptom

The distinction driving that table is worth internalising: SFC and DISM answer “are the Windows files the right files?”, while chkdsk answers “is the volume holding them intact?”. Symptoms that follow a bad update or a half-finished install belong to the first pair. Symptoms that follow a power cut, an unclean shutdown, or an ageing disk belong to chkdsk. Running all three is never wrong, only slow.

Reading the results afterwards

SFC’s console output is a single summary line. The detail is written to the CBS log at C:\Windows\Logs\CBS\CBS.log, where every SFC entry is tagged [SR]. Microsoft’s documented way to extract just those entries into a readable file is:

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

That command is not produced by the builder — it is the follow-up step, and it is worth knowing because it turns “some files could not be repaired” into a list of the specific files, each with a verdict such as “cannot repair member file”. With filenames in hand you can decide whether the damage matters. DISM keeps its own log at C:\Windows\Logs\DISM\dism.log, which is where to look when a RestoreHealth run reports an error code rather than an outcome.

Three outcomes and what each means: “did not find any integrity violations” — the protected files are intact, and your problem is elsewhere. “found corrupt files and successfully repaired them” — reboot, then re-run sfc /scannow to confirm it now comes back clean. “found corrupt files but was unable to fix some of them” — run DISM RestoreHealth, then SFC again; if it still fails after that, the CBS log tells you which files, and an in-place upgrade repair install is the usual next step.

When this sequence is the wrong tool

SFC and DISM only touch Windows’ own protected files and its component store. They do not repair third-party applications, user data, driver configuration, or registry damage outside the servicing stack — and they will not fix a machine whose real problem is a failing SSD, bad memory, or an update that installed correctly but behaves badly. If chkdsk keeps finding new bad sectors on every run, you are not looking at a filesystem problem you can repair; you are looking at hardware to replace, and every additional full-surface scan is time spent not copying the data off.