chkdsk in Windows: what each switch does, and when not to run it

Most of what administrators know about chkdsk was true in 2005. Run it with /f /r, reboot, watch a progress percentage for four hours, hope. On a modern NTFS volume that ritual is usually the wrong move, and on a large disk it is an outage you chose to have.

Since Windows 8 and Windows Server 2012, NTFS separates finding corruption from fixing it. A volume can be scanned online, while it is mounted and in use, and only the repairs that genuinely need the volume offline are queued for later. The offline window then takes seconds instead of hours, because the scan has already been done.

What follows is which switch to reach for, what each one really implies, and when running chkdsk is the thing that turns a degraded disk into a dead one.

Applies to: Windows 10 / 11 and Windows Server 2016 / 2019 / 2022 / 2025, NTFS volumes

Quick answer

Scan online first. Only if the scan reports something do you need anything else, and even then /spotfix is usually enough.

rem Online scan, volume stays mounted and in use
chkdsk C: /scan

rem If the scan found repairable damage: a short offline fix, seconds not hours
chkdsk C: /spotfix

rem Check the dirty bit without running anything at all
fsutil dirty query C:

All three need an elevated prompt. /scan changes nothing and is safe on a production volume during business hours.

What chkdsk does

chkdsk verifies the file system metadata: the master file table, the directory index, the security descriptors, the free space bitmap. It also, with the right switch, reads every sector to find media that no longer returns data. Those are two very different jobs with very different costs, and the switches blur the line between them.

Practical examples

1. Check a production volume without downtime

The problem: The Application log on SRV-FILE01 shows NTFS warnings and you need to know whether the volume is actually damaged. Nobody will approve a maintenance window on a hunch.

The solution: /scan runs against a mounted, in-use volume. It reports what it finds and queues anything that needs an offline fix, without touching the data.

rem Online scan; safe during business hours
chkdsk D: /scan

rem Same scan, allowed to use more CPU and I/O so it finishes faster.
rem Use this out of hours, not at 10:00 on a busy file server.
chkdsk D: /scan /perf

The type of the file system is NTFS.

Stage 1: Examining basic file system structure ...
  262144 file records processed.
Stage 2: Examining file name linkage ...
  339968 index entries processed.
Stage 3: Examining security descriptors ...
Windows has scanned the file system and found no problems.
No further action is required.

2. Apply the repairs the scan queued

The problem: The scan found corruption. The old answer is a full offline chkdsk /f, which on a multi-terabyte volume means hours of unavailability.

The solution: /spotfix applies only the repairs already identified. The offline time is proportional to the number of problems, not to the size of the disk.

rem Applies queued repairs; typically seconds on a data volume
chkdsk D: /spotfix

rem Confirm the volume is no longer marked dirty afterwards
fsutil dirty query D:

On the boot volume, /spotfix cannot run while Windows is using it, so it is scheduled for the next restart. The restart is still short, because the scan work is already done.

3. A data volume you can take offline

The problem: A backup volume is behaving oddly and you have a window to work in. There is no reason to be careful about uptime here.

The solution: /x dismounts the volume and includes the functionality of /f. Any open handle to the volume is invalidated, so stop the services that use it first.

rem Stop whatever holds the volume open before dismounting it
sc stop "Backup Exec Agent Browser"

rem /x dismounts and fixes; /f is implied
chkdsk E: /x

rem The exit code is scriptable: 0 clean, 1 fixed, 2 cleanup, 3 could not fix
echo Exit code: %errorlevel%

4. The boot volume, and cancelling a scheduled check

The problem: A server is rebooting into a disk check that nobody scheduled deliberately, and the maintenance window is disappearing into it.

The solution: The check runs because the volume is marked dirty, or because a check has been scheduled. Both are readable and both can be changed. This is chkntfs territory rather than chkdsk, and the two are usually confused.

rem Is the volume dirty, or is a check merely scheduled?
chkntfs C:

rem Exclude the volume from the boot-time check without clearing the dirty bit
chkntfs /x C:

rem Put everything back to the default behaviour
chkntfs /d

5. Suspected bad sectors

The problem: Read errors in the event log, a disk that clicks, or SMART warnings. The instinct is chkdsk /r.

The solution: Image the disk first, then decide. /r reads every sector on the volume, which on a failing drive is exactly the workload most likely to finish it off before you have a copy of the data.

rem Only after the data is safely copied elsewhere
chkdsk E: /r

Hidden gems

The exit code is the scriptable part. 0 means no errors, 1 means errors were found and fixed, 2 means cleanup was performed or skipped because /f was absent, and 3 means the disk could not be checked or the errors were not fixed. A monitoring script that reads %errorlevel% after a nightly /scan is worth more than a person remembering to look.

NTFS repairs itself constantly. Self-healing NTFS fixes many kinds of corruption in the background without any command being run. That is why volumes that would once have needed a monthly check now go years without one, and why a scheduled monthly chkdsk /f is a habit rather than a maintenance policy.

Progress percentages lie on large volumes. The stages are not equal in length and the percentage restarts at each one. A run that appears stuck at 10 percent in stage 4 is usually reading sectors, not hung. Judge it by disk activity, not by the number.

The output does not disappear at reboot. A boot-time check writes its report to the Application log under the Wininit source. An online scan writes under the Chkdsk source. That is where to look when the console scrolled past before anyone read it.

/i and /c trade completeness for time. They skip index verification detail and directory cycle checking. On a very large volume with a hard deadline they turn an impossible run into a possible one, at the cost of the checks most likely to catch a subtle problem. Use them deliberately, not by default.

PowerShell equivalent

Repair-Volume maps onto the same three modes and returns a status string rather than console text, which makes it the better choice inside a script.

# Online scan, the equivalent of chkdsk /scan
Repair-Volume -DriveLetter D -Scan

# Apply queued repairs, the equivalent of chkdsk /spotfix
Repair-Volume -DriveLetter D -SpotFix

# Full offline scan and repair, the equivalent of /offlinescanandfix
Repair-Volume -DriveLetter E -OfflineScanAndFix

# Scan every fixed NTFS volume and report anything that is not clean
Get-Volume | Where-Object { $_.DriveType -eq 'Fixed' -and $_.FileSystemType -eq 'NTFS' } |
    ForEach-Object {
        $r = Repair-Volume -DriveLetter $_.DriveLetter -Scan
        if ($r -ne 'NoErrorsFound') { "$($_.DriveLetter): $r" }
    }

Where this matters

• After an unclean shutdown. A power loss on a busy file server marks the volume dirty. An online scan answers the question before the next reboot turns into a surprise outage.
• NTFS warnings in the event log. The event says corruption was detected. /scan says whether it still exists, because self-healing may already have dealt with it.
• Before extending a volume. Growing a volume with metadata corruption present is how a recoverable problem becomes an unrecoverable one.
• Virtual machine disks. On a VM the underlying storage is already protected. Long surface scans with /r mostly punish the storage array for no benefit.
• Before decommissioning. A clean scan on the source volume is cheap evidence that a migration copied intact data rather than propagating corruption.

Tips and limitations

• Every mode needs an elevated prompt. Without it chkdsk runs read-only and cannot fix anything, which looks like success and is not.
• /scan, /spotfix, /i, /c, /b and /l are NTFS only. On FAT or exFAT they are rejected.
• chkdsk repairs the file system, not the files. A recovered fragment lands in found.000 as a .chk file, which is rarely useful. Backups are the recovery plan; this is not one.
• It cannot lock the boot volume, so /f there always schedules for the next restart. Answering yes to that prompt on a production server is a decision about a reboot, not about a command.
• Deduplicated volumes and Storage Spaces have their own repair paths. Run the platform’s own health check before reaching for chkdsk.

Official documentation

• chkdsk | Microsoft Learn
• Repair-Volume | Microsoft Learn

Related tools

• Windows Event Log Analyzer: for finding the NTFS and Wininit entries that say what a check actually reported.
• ROBOCOPY Command Builder: builds the copy that gets the data off a suspect disk before anything is repaired.

Related guides

• chkntfs in Windows: control the boot-time disk check: the dirty bit, and how to stop a check you did not schedule.
• sfc /scannow in Windows: what it does, when it works, and when it doesn’t: the same question for system files rather than the file system.
• DISM in Windows: repair the Windows image when SFC can’t: the layer underneath sfc.
• DISKPART: practical guide for sysadmins: volume and partition work once the file system is known good.