How to repair Windows system files after repeated BSODs with SFC and DISM

Windows keeps its core in two related places. The first is the set of protected system files that are actually in use (in C:\Windows and Program Files). The second is the component store — the WinSxS and servicing folders that hold the "known good" reference versions and spare component copies. SFC works on the first; DISM works on the second. Understanding that split is the whole game, because it explains both the correct order and the tools' limits.

The sequence that follows from that is short: check the store, repair the store if needed, then verify and repair the in-use files, restart, and confirm the crashes stopped. The table below lays it out so you can see the logic before you run anything.

The diagram below shows the flow at a glance: a crash leads to an integrity check, a store repair where needed, a file verification, and then an interpretation that tells you whether to celebrate or to keep diagnosing.

The System File Checker is a built-in Windows utility that audits the operating system's own files. When you run sfc /scannow, it walks through the set of protected system files — the ones Windows marks as protected — and compares each one against a known-good reference. If a file it checks doesn't match its reference, SFC replaces it with the correct version. That's the entire job, and it's a well-scoped one.

The reference SFC compares against comes from two places: cached copies and the component store (the same store DISM repairs, covered next). The word "protected" is doing real work here. SFC does not look at your personal files, and it does not look at driver files, firmware, or most third-party software. It's specifically about the core OS files that, when damaged, tend to produce exactly the instability behind repeated blue screens. That's why it's a sensible early check: it's fast, it's safe, and it answers one specific question — "are the protected system files intact?"

There are a few other SFC switches worth knowing. /verifyonly does the same scan but only reports — it never changes anything. /scanonce defers the scan to the next restart. For a live machine, though, /scannow is the one you want, because it both checks and repairs in a single pass while you're booted.

DISM — Deployment Image Servicing and Management — is a broader tool for servicing Windows images, both the running one and offline images. For this task the operation that matters is /RestoreHealth run against the online image. It scans the component store (the C:\Windows\WinSxS folder and the servicing directory) for corruption and, when it finds it, replaces the damaged components with healthy ones.

When the local store is damaged beyond what it can fix from its own backups, DISM reaches out for clean components. By default it uses Windows Update as that source; you can also point it at a local install image. This is the layer underneath SFC: DISM makes sure the "known good" reference material is actually good, so that when SFC runs afterwards it is comparing against — and copying from — correct files rather than a damaged set.

The cleanest way to think about it is a two-level repair. Level one is the individual files you use every day (SFC's territory). Level two is the library of reference versions that level one draws from (DISM's territory). If level two is damaged, fixing level one is like replacing a torn page in a book using a torn copy of the book as your reference — the repair inherits the damage. DISM fixes the reference book first.

The simplest way to hold the difference: SFC repairs files; DISM repairs the store that SFC depends on. SFC's job is narrow and specific — check the protected files in use and fix the ones that are wrong. DISM's job is deeper — make sure the component store, the source of truth for those files, is itself healthy. They touch different things, which is why running both (in order) is more powerful than running either alone.

They're complementary because they operate at different layers. A damaged in-use file with a healthy store is exactly what SFC fixes. A damaged store is exactly what SFC cannot fix and DISM can. So the practical rule is: SFC is the first check, and DISM is the fix for when SFC's reference is the problem. If you only ever run one and it's SFC, you'll occasionally hit a wall that only DISM can clear — and vice versa, running DISM alone fixes the store but leaves the already-damaged in-use files unrepaired.

Notice what neither tool does: neither inspects drivers, and neither touches hardware. That boundary is why these two are a "system integrity" pair, not a general "fix my PC" pair, and it's the boundary you'll lean on heavily in the later sections on what these tools can't do.

The recommended order is DISM /RestoreHealth first, then sfc /scannow — with one important nuance. If you're only doing a first check and SFC reports everything is fine, you've answered the question and you may not need DISM at all. DISM-first becomes essential when SFC has already told you it found corruption it couldn't repair, or when you have a reason to suspect the component store specifically. In those cases, SFC's failure is a symptom of the store, not the files.

Why the order matters: SFC needs healthy reference files to do its job. If you run SFC while the store is damaged, it may report failures that are actually the store's fault, and you'd be misreading the result as "my system is unfixable." Running DISM first removes that ambiguity: after DISM, any SFC result reflects the state of your actual files, not a broken reference. The order converts a confusing failure into a meaningful answer.

"Wrong order" in practice looks like this: run SFC, see "could not repair," conclude the OS is damaged beyond repair, and reinstall — when the real fix was a single DISM pass that would have made SFC succeed. The sequence exists to remove exactly that trap, so you don't throw away a working (if damaged) installation when a short repair would have saved it.

Both tools need an elevated (Administrator) prompt. On Windows 10/11, click Start, type cmd or PowerShell, choose Run as administrator, and confirm the prompt. An unelevated prompt will let the commands start but they'll report that the operation couldn't be performed — a confusing result that has nothing to do with your system's actual health, and it's one of the most common "false failures" people report.

Here are the two core commands. DISM /RestoreHealth is the operation that modifies the image; sfc /scannow modifies files. Neither touches your personal data — they only affect protected Windows components. Run DISM first, let it finish, then run SFC, then restart.

It's worth distinguishing read-only commands from modifying ones before you run anything. DISM's /CheckHealth and /ScanHealth, and SFC's /verifyonly, only read — they tell you the state without changing it. /RestoreHealth and /scannow make changes. If you're unsure whether there's a problem at all, start with a read-only check to see; you can always decide to repair afterwards.

There are two "good" SFC outcomes, and they mean different things. "No integrity violations found" means every protected file SFC checked matched its reference — the protected files are intact. "Found corrupt files and successfully repaired them" means SFC found damaged files and replaced them with correct versions; this is the outcome that most often corresponds to a genuine fix.

The crucial thing about "no violations" is what it does and doesn't prove. It proves the protected files are intact. It does not prove your machine is healthy — drivers, hardware, memory, and non-protected software are all outside SFC's view. So a clean scan is a useful elimination, not a diagnosis. It lets you stop looking at the OS image and start looking elsewhere, but it doesn't tell you where "elsewhere" is.

If SFC repaired files, the honest next step is to restart and actually use the machine to see whether the crashes stopped. If they did, the damaged files were very likely the cause and you're done. If they didn't, the repair was still valid — you fixed real damage — but that damage wasn't the cause of your crashes, and you move to the other suspects. Either way, the result moves you forward.

"Found corrupt files but some could not be repaired" is the outcome that points at the component store. SFC found damage but the reference copy it needed to fix it was itself bad, so it couldn't complete. The standard response is to run DISM /RestoreHealth to fix the store, then run SFC again. Very often the second SFC pass then succeeds, because its reference is finally healthy.

A second, less common outcome is "The requested operation could not be performed." That usually isn't about corruption at all — it's that SFC couldn't run or finish, most often because the prompt wasn't elevated or the operation was blocked. Confirm you're an administrator and retry; if it persists on a normal boot, try running it from Safe Mode, where fewer components are loaded and fewer things can interfere.

Don't mistake "couldn't repair" for "my Windows is broken beyond repair." In the vast majority of cases it means the reference was damaged, and DISM is the fix. Reinstalling at this stage is usually solving a reference problem with a sledgehammer.

When SFC finds something it can't fix, the detail lives in the Component Based Servicing log — CBS.log — at C:\Windows\Logs\CBS\CBS.log. It's a large, time-ordered file, so the trick is to look at the section that matches the time you ran the scan, not the whole thing. Opening the log is read-only; it changes nothing on your system.

In an elevated prompt you can open it in Notepad: notepad %windir%\Logs\CBS\CBS.log. Once open, search (Ctrl+F) for lines around "Failed", "could not repair", and "corrupt". The entries that matter are the ones that name a specific file that couldn't be restored and, where present, the source SFC tried to use. If the failures reference the component store or a missing source, that confirms the store is the problem (→ DISM, or offline repair). If they reference specific damaged files with no available source, you may need to supply a local source or consider a repair install.

Treat the log as a "which files, and why" reference rather than a verdict. It tells you what failed and where SFC looked for the fix, which is exactly the information you need to choose between DISM, a local source, or offline repair. It doesn't tell you what originally caused the corruption — that's the role of the broader BSOD diagnosis.

DISM has three online Cleanup-Image operations, and they're commonly confused. /CheckHealth is a fast, read-only check that tells you whether the store has corruption — but it doesn't do a full scan; it's a quick "is there a problem?" probe. /ScanHealth does the full, read-only scan for corruption (slower, and still no repair). /RestoreHealth is the only one that actually repairs, and the only one that modifies the image.

Which to use: if you just want to know quickly whether the store is damaged, /CheckHealth. If you want a thorough read-only assessment before deciding to change anything, /ScanHealth. If you want the fix, /RestoreHealth. Most people go straight to /RestoreHealth, which is fine — it checks and repairs in one pass. The read-only variants are useful when you want a diagnosis before you commit to a change, or when you're on a machine you'd rather not modify yet.

The most common DISM failure is a source problem: the operation starts but can't finish because it couldn't obtain healthy components. This shows up as a failure with a source-related message. The two typical roots are: Windows Update (the default source) is itself broken or unreachable, or the store is damaged too far for the local backups to cover. A "repair failed" from DISM is usually "I couldn't get the parts," not "your system is hopeless."

Three responses, in order of preference. First, confirm you have a network connection and that Windows Update can actually work — if Update is broken, /RestoreHealth often fails too, and the fix is to repair Update first. Second, you can supply your own source: a Windows install image (the install.wim from official media) using the /Source and /LimitAccess options. Third, if online repair keeps failing, offline repair from the recovery environment (the next section) is the robust fallback.

If all three paths fail and the store is genuinely beyond repair online, that's a strong signal to move to offline repair or, as a last resort, a clean install — but only after you've backed up your data and ruled out the simpler causes. A DISM failure is a checkpoint, not a dead end.

DISM /RestoreHealth relies on a source for clean components, and by default that source is Windows Update. This creates a subtle dependency: the components that make Windows Update work are themselves part of the component store. So a machine with a badly damaged store can have a broken Windows Update, which then makes DISM unable to fetch the repair components it needs. A genuine chicken-and-egg problem, and one that trips up a lot of "DISM says source unavailable" situations.

Breaking the loop: if /RestoreHealth fails with a source error, either repair Windows Update first (the built-in Update troubleshooter and the standard Update-component repair steps usually do it), or give DISM a local source so it doesn't need Update at all. Once Update is working again, DISM can use it as its source and the normal online repair works.

The practical takeaway: when DISM and Windows Update both look broken, they often are broken together, and a local source (or offline repair) is the cleanest way around it. Recognizing this dependency saves you from repeatedly retrying an online repair that can't possibly succeed until the underlying source is fixed.

Safe Mode loads Windows with a minimal set of drivers and services. It's the right environment for SFC and DISM in a specific situation: when the system is unstable enough that a normal boot can't hold, or when you want to make sure a third-party driver or startup item isn't interfering with the repair. The commands are identical — you just run them from an elevated prompt that you opened while in Safe Mode.

Safe Mode doesn't change what the tools do; it changes the environment they run in. Fewer things are loaded, so fewer things can get in the way, and the read you get is cleaner. There's a diagnostic bonus too: if a normal boot is crashy but Safe Mode is stable, that itself is a clue that a third-party driver or app is involved — because those don't load in Safe Mode. Running the integrity checks from the stable Safe Mode environment gives you a more trustworthy result.

Getting into Safe Mode — and what to do if even Safe Mode won't hold — is covered in the crash-loop guide, which walks through Startup Settings, Safe Mode with Networking, and the recovery paths. If you're here because the machine won't stay on normally, that's the page to read first, then come back and run these tools from the stable environment.

Windows BSOD crash loop: how to reach Safe Mode and break the restart cycle.

When Windows won't boot at all, you can't run SFC or DISM from the normal OS. Instead you boot from Windows install media (or the built-in recovery) into the Windows Recovery Environment (WinRE) and run the offline forms of the tools against your Windows installation. The commands are different, and there's one trap you must avoid.

How to find the right letter: in an elevated WinRE prompt, type dir and step through the volumes, or use diskpart then list volume, until you find the volume that contains Windows, Program Files, and Users. That's your Windows partition. The offline commands below use D: as an example — replace it with your actual letter.

After the offline repair, restart into Windows and run an online sfc /scannow to confirm the files are intact now that you're booted. Then address the original cause of the boot failure — most often a bad update, which you can uninstall once you can get to the desktop. The recovery and update-removal paths are in the crash-loop and recent-changes guides linked below.

CHKDSK checks a different layer entirely: the disk volume and the file system (NTFS) on it, not the Windows image. It looks for file-system errors, bad sectors, and logical volume problems. SFC and DISM look at the OS files and the component store. They answer different questions, and mixing them up leads to the classic mistake of "I ran every repair tool and nothing changed" while the actual problem — a failing drive — was never tested.

Why it matters: a failing disk can cause both CHKDSK errors and blue screens. If CHKDSK reports disk errors, that's a hardware signal that no amount of SFC/DISM will fix — it points at the drive, not the OS. Conversely, a clean CHKDSK with a damaged component store is a software problem that SFC/DISM can address. The two tools together let you separate "the OS is damaged" from "the disk is dying," which are very different repairs.

Can your SSD or hard drive cause a BSOD? How to check Windows storage problems.

Sometimes — and it's worth being precise about when. SFC and DISM fix a blue screen when the crash is caused by damaged protected system files or a damaged component store; some system-integrity and critical-process stop codes fit this pattern. If that's the cause, the repair directly addresses it, and the crashes stop. In those cases you didn't just run a tool, you fixed the root cause.

They do not fix a blue screen when the cause is a driver, hardware, memory, or non-protected software. A driver can crash the kernel while every protected file SFC checks is perfectly intact — a "clean" SFC does not clear the driver. Hardware (RAM, disk, GPU) is completely outside these tools. So a successful repair is evidence about the OS image, not a verdict on the machine. This is the single most important limitation to keep in mind as you read the results.

The honest framing: SFC and DISM are an elimination step. They tell you "the core OS files are fine (or are fixed now)," which lets you stop looking at the OS image and start looking at the other, more common causes of recurring crashes. That's genuinely valuable — ruling a whole category out — but it's not the same as having found the cause.

If SFC and DISM both come back clean (or repaired and stable once) and the blue screens continue, you've done something genuinely useful: you've ruled out damaged core system files. Now the search moves to the causes these tools can't see, and you should stop re-running the integrity checks expecting a different answer — a clean result is a clean result.

The usual next suspects, in rough order of likelihood: a driver (especially one that changed recently, or the one named in your crash dump), memory (run a memory test), storage (disk health and CHKDSK), and heat/power. The crash dump is often the fastest pointer here — if the same module appears across multiple crashes, that's a strong lead even when the OS files check out.

This is where the wider BSOD series takes over. Each of these causes has its own diagnostic, and the decision framework at the end of this page routes you to the right one. The point of getting a clean SFC/DISM result isn't to be stuck — it's to know, with confidence, that the answer is in the driver/hardware layer rather than the OS image.

The whole process as tickable items, in order. Your progress is saved in this browser, so you can work through it across several reboots. It deliberately includes the "did it actually help?" and "now check the other causes" steps, because confirming the fix — and knowing when to move on — is where most people get stuck.

Every command from this guide in one place, filterable by type. "Read-only" commands only inspect; "modifying" commands change the system. Copy any of them directly. The offline entries are templates — replace the drive letters with your actual ones before running.

Pick the message you actually saw and this will explain what it means and what to do next. It's the same interpretation as the tables above, but interactive, so you can check your exact output without scrolling.

Answer a few questions and this will route you to the right next step — whether that's confirming the fix, repairing a non-booting Windows, or moving on to the driver/hardware causes that system-file repair can't reach.

This guide is one part of the BSOD series. Work back to the pillar for the full picture, or jump to the cause that a clean SFC/DISM result points you toward.