SFC, DISM, and CHKDSK are all Windows repair tools, but they repair different layers.

SFC checks protected Windows system files.

DISM checks and repairs the Windows image and component store used to service the operating system.

CHKDSK checks the file system and disk-volume metadata for logical or physical errors.

The current CompTIA A+ Core 2 exam expects technicians to choose troubleshooting tools based on the symptom. Running all three commands without understanding the failure layer wastes time and can increase risk on unhealthy storage.

Use SFC for protected Windows system files

System File Checker verifies protected Windows system files.

The most common command is:

SFC /scannow

SFC compares protected files with the expected Windows versions and replaces damaged or incorrect copies where possible.

Use SFC when symptoms suggest Windows system-file corruption, such as:

• built-in Windows components fail
• system DLLs are damaged
• Windows features behave incorrectly
• a servicing or update problem may have replaced system files
• error messages point to protected files

SFC is not a general hard-drive repair tool.

It is focused on Windows protected files.

SFC still depends on healthy Windows component data

SFC needs healthy Windows components from which to restore protected files.

If the Windows component store is damaged, SFC can report that it found corruption but could not repair everything.

That is when DISM becomes relevant.

A common repair sequence for a running Windows installation is:

1. repair the Windows image/component store with DISM
2. run SFC again

This is not a rule that SFC must always come second.

If you suspect a small protected-file issue, SFC is a reasonable first check.

The point is to understand the dependency.

Use DISM for the Windows image and component store

Deployment Image Servicing and Management, or DISM, can service both online and offline Windows images.

For a running Windows installation, common health commands include:

DISM /Online /Cleanup-Image /CheckHealth

DISM /Online /Cleanup-Image /ScanHealth

DISM /Online /Cleanup-Image /RestoreHealth

CheckHealth checks whether corruption has already been flagged.

ScanHealth performs a more extensive corruption scan.

RestoreHealth attempts to repair the image.

Microsoft documentation notes that DISM can use Windows Update or another configured repair source to obtain healthy components.

DISM is especially useful when servicing is broken

Consider DISM when:

• Windows Update repeatedly fails with component corruption
• optional Windows features cannot be enabled
• SFC cannot repair protected files
• the component store is suspected
• an offline Windows image needs repair

DISM is not a replacement for SFC.

DISM repairs the broader Windows image and servicing store.

SFC verifies and repairs protected operating-system files.

They operate at related but different layers.

Use CHKDSK for file-system and volume errors

CHKDSK checks the file system and file-system metadata on a volume.

Microsoft documents that CHKDSK without repair parameters reports the volume status.

Repair parameters include options such as:

• /f — fix file-system errors
• /r — locate bad sectors and recover readable information where possible
• /x — force a dismount when required

CHKDSK is appropriate when symptoms point to:

• file-system corruption
• directory errors
• volume dirty state
• unreadable files
• storage-related event-log errors
• problems after unsafe shutdown
• possible bad sectors on applicable media

It does not repair the Windows component store.

Be careful with CHKDSK on failing hardware

If a drive is physically failing, aggressive repair work can increase stress.

Before running long repair operations on a drive showing signs such as:

• SMART failure
• repeated disconnects
• severe read errors
• unusual HDD noises
• rapidly increasing bad sectors

protect the data first.

The highest priority may be:

1. stop unnecessary writes
2. back up or image the drive
3. replace failing storage
4. restore data to healthy storage

CHKDSK can fix file-system structures.

It cannot make failing hardware reliable.

Choose the tool from the symptom

Windows component fails, but disk seems healthy Start with SFC.

SFC cannot repair files or Windows servicing is damaged Use DISM to repair the component store, then run SFC again.

Volume reports file-system errors or files are unreadable Use CHKDSK after considering hardware health and backup.

PC will not boot Enter Windows Recovery Environment and determine whether startup, system files, storage, or hardware is the actual failure before choosing a repair command.

The tool should follow the diagnosis.

The three utilities are often mentioned together because they appear in Windows troubleshooting, but they operate on different structures. SFC validates protected operating-system files against known-good copies. DISM services and repairs the Windows image and component store that Windows servicing depends on. CHKDSK examines the logical file system and, with selected options, can check for bad sectors and recover readable information. Running all three automatically on every problem hides the distinction the technician needs to understand.

For an online Windows installation, DISM commonly uses the servicing stack and can obtain repair content from Windows Update unless a different source is specified. That dependency matters in restricted or damaged environments. If Windows Update is unavailable, an administrator may need a compatible repair source. A failed RestoreHealth operation should lead to source and log investigation rather than endless retries.

SFC results also need interpretation. A clean scan means protected system files matched expected versions; it does not prove the registry, third-party applications, drivers, disk hardware, or user data are healthy. If SFC reports files it cannot repair, repairing the underlying component store with DISM and then running SFC again can make sense because SFC needs a trustworthy source for replacement files.

CHKDSK deserves extra caution on a drive that shows physical-failure symptoms. File-system repair writes metadata, and /r adds a surface scan that can create heavy I/O on a weak disk. If the drive is clicking, disappearing from firmware, reporting serious SMART warnings, or repeatedly corrupting data, prioritize backup or imaging and hardware replacement. Logical repair cannot make failing NAND, a bad controller, or damaged media reliable.

Offline repair changes the command context. In WinRE or Windows PE, the installed Windows volume may not use the same drive letter it has during normal startup. Confirm the correct volume and Windows directory before using offline SFC, DISM, or CHKDSK commands. A technically correct command aimed at the wrong volume is still the wrong repair.

Offline repair is possible

SFC and DISM can operate against offline Windows installations using the appropriate parameters.

This is useful when Windows cannot boot normally but WinRE or external recovery media can access the installation.

Offline repair requires careful identification of:

• Windows partition
• boot partition
• repair source
• drive letters in the recovery environment

Drive letters can differ inside WinRE.

Do not assume the Windows installation is always C:.

Verify the volume before running destructive or repair commands.

Logs help when repair fails

Windows repair tools produce diagnostic information.

SFC records details through the CBS logging system.

DISM has its own logging.

CHKDSK results can be viewed through Windows event logs or command output depending on how it was run.

If a repair command fails repeatedly, inspect the logs rather than running the same command indefinitely.

Repeated failure can point to:

• wrong repair source
• component-store corruption
• disk errors
• permission issue
• unsupported offline path
• damaged hardware

Logs turn a vague “repair failed” message into a specific next step.

Command success should always be followed by symptom validation. If DISM completes successfully but Windows Update still fails, the problem may be policy, network reachability, a third-party filter, or a servicing issue not fixed by the component-store repair. If SFC reports no integrity violations but the application still crashes, investigate the application, driver, profile, or dependencies instead of assuming Windows system files are the cause. If CHKDSK reports a clean file system while the drive intermittently disappears, return to hardware diagnostics.

This distinction prevents a common support mistake: treating a familiar repair command as proof of root cause. These tools report on the structures they inspect. They do not replace event logs, storage diagnostics, update history, or a careful reproduction of the original failure. The technician should be able to explain why a command was chosen and what its result proves.

Match the repair tool to the damaged layer

For a Windows system that still boots:

1. Confirm recent backups.
2. Check storage health if symptoms suggest disk problems.
3. Run SFC when protected system files are suspected.
4. Run DISM when component-store corruption is suspected or SFC cannot repair.
5. Run SFC again after successful DISM repair if needed.
6. Use CHKDSK for file-system/volume problems.
7. Reboot and retest.
8. Review logs when errors remain.

Choose the repair utility from the evidence: system-file corruption points toward SFC, component-store problems toward DISM, and file-system or volume errors toward CHKDSK. If hardware is failing, software repair is not the root fix. Before any repair, confirm whether the user has a current backup and whether the system is stable enough to continue. Repair operations can expose latent storage failures, and a technician should not discover the only copy of important data is on a failing disk after beginning a write-intensive recovery. On business systems, change control or escalation may also be required before offline repair or reboot.