chkdsk

The Microsoft Learn chkdsk reference provides the canonical definition: chkdsk “checks the file system and file system metadata of a volume for logical and physical errors. If used without parameters, chkdsk displays only the status of the volume and doesn’t fix any errors. If used with the /f, /r, /x, or /b parameters, it fixes errors on the volume.”¹

The 1980 MS-DOS origin

The IONOS chkdsk reference describes the historical lineage: “The chkdsk command line tool was included in earlier MS-DOS versions of Microsoft operating systems. From Windows NT 3.1 and higher, chkdsk runs as a 32-bit program that also supports NTFS format disks. From Windows XP and higher, the tool includes a disk scanning feature with a simple graphical interface that uses the disk service in the background but offers only two of the service’s many options.”² The progression:

• MS-DOS 1.0 (1980): original chkdsk for FAT12 floppy disks; simple lost-cluster recovery.
• MS-DOS 2.0+: extended for FAT16 and hard disk support.
• Windows NT 3.1 (1993): rewritten as 32-bit with NTFS support; introduced 5-stage scan.
• Windows XP (2001): graphical interface added via Properties → Tools tab → Check Now.
• Windows Vista (2007): Self-Healing NTFS introduced; transparent runtime corruption detection.
• Windows 8 (2012): /scan and /spotfix parameters added for online scanning of NTFS volumes.
• Windows 10/11/Server 2025: continues with no major architectural changes.

Where chkdsk fits in Windows administration

chkdsk is the primary file system maintenance tool in the Windows ecosystem, but it’s part of a broader set of related utilities:

• chkdsk.exe: the standalone command-line tool documented in this entry.
• autochk.exe: the boot-time variant that runs before Windows fully starts; triggered by the volume dirty bit.
• chkntfs.exe: companion utility for managing the dirty bit and scheduling boot-time chkdsk runs.
• fsutil dirty: direct dirty bit manipulation (set/query) for triggering chkdsk at next boot.
• Repair-Volume PowerShell cmdlet: modern PowerShell equivalent introduced in Windows 8 / Server 2012.
• Disk Properties Tools tab: graphical front-end accessible from File Explorer.

When Windows runs chkdsk automatically

Windows triggers chkdsk runs automatically in several scenarios:

• Volume dirty bit set: any unclean shutdown, file system error detection, or explicit fsutil dirty set causes chkdsk to run at next boot.
• Boot-time scheduling: chkntfs /c schedules chkdsk for the next reboot on a specified volume.
• Self-Healing NTFS findings: if the runtime self-healing process detects issues it cannot fix online, it sets the dirty bit for offline chkdsk.
• System file corruption: Windows Update and SFC may trigger chkdsk to address detected file system inconsistencies.
• USN journal anomalies: certain journal corruption patterns trigger automatic chkdsk scheduling.

Privileges and execution requirements

The Microsoft Learn reference describes the privilege requirement: “Membership in the local Administrators group, or equivalent, is the minimum required to run chkdsk. To open a command prompt window as an administrator, right-click Command prompt in the Start menu, and then select Run as administrator.” Additional execution constraints:

• Cannot run on system drive while Windows runs: the active C: drive cannot be locked; chkdsk schedules itself for next boot instead.
• Cannot run on remote drives: chkdsk operates only on local drives; mapped network drives are unsupported.
• Cannot run on locked drives: open file handles prevent /F mode; /X parameter forces dismount.
• Shadow Copies interference: Volume Shadow Copy enabled volumes may report false errors during chkdsk.

chkdsk has accumulated a substantial parameter set across decades of Windows releases. Understanding which parameters apply to which scenarios is essential for both administration and recovery contexts.

The full syntax

The Microsoft Learn reference documents the canonical syntax: chkdsk [drive[[path]filename]] [/F] [/V] [/R] [/X] [/I] [/C] [/L[:size]] [/B] [/scan] [/spotfix] [/forceofflinefix]. Without parameters, chkdsk runs in read-only mode reporting status without making changes; with any of /F, /R, /X, or /B, it actively modifies the volume.

The repair parameters: /F, /R, /B, /X

Four parameters control destructive (volume-modifying) behavior:

Parameter	Function	Implies	Time impact
/F	Fix logical errors in file system structure	Volume lock	Minutes to hours
/R	Locate bad sectors via surface scan, recover readable data	/F	Hours; per-sector read
/B	Re-evaluate bad clusters list (NTFS only)	/R	Hours; resets $BadClus
/X	Force volume dismount, invalidate open file handles	/F	Same as /F

The online parameters: /scan and /spotfix

Windows 8 introduced two NTFS-specific parameters that allow scanning without taking the volume offline:

• /scan: performs a thorough online scan while the volume remains in use; identifies issues and queues them for offline repair via /spotfix or boot-time chkdsk; safe to run on the system drive.
• /spotfix: performs targeted online fixes for specific corruptions identified by /scan; very fast (seconds rather than hours); only addresses queued issues.
• /forceofflinefix: bypasses online repair entirely; forces all detected defects to be queued for offline repair at next boot.

The typical Windows 8+ workflow: chkdsk C: /scan identifies issues without disruption; chkdsk C: /spotfix applies targeted fixes; if /spotfix can’t resolve the issue, schedule offline chkdsk via boot-time autochk.

The diagnostic parameters: /V, /I, /C, /L

Several parameters control verbosity and scan thoroughness:

• /V: displays filenames as they’re checked (FAT/FAT32) or cleanup messages (NTFS); useful for monitoring progress and debugging.
• /I: NTFS-only; performs less rigorous index entry checking; significantly faster but less thorough.
• /C: NTFS-only; skips checking of cycles in folder structure; faster but less thorough verification.
• /L[:size]: NTFS-only; changes log file size in kilobytes; without :size, displays current log file size.

Common command combinations

Several parameter combinations are commonly used in practice:

• chkdsk D:: read-only diagnostic only; safe for quick investigation.
• chkdsk D: /F: fix logical errors without surface scan; appropriate for clean drives with file system inconsistencies.
• chkdsk D: /F /R: comprehensive check including surface scan; the typical “thorough” run.
• chkdsk D: /F /R /X: same as above plus forced dismount; ensures lock can be acquired.
• chkdsk D: /B: re-evaluate bad clusters; useful when investigating drives with previously-marked bad sectors.
• chkdsk C: /scan: online diagnostic on system drive; safe alternative to scheduled boot-time chkdsk.
• chkdsk C: /spotfix: targeted online fix following /scan results.

SSD-specific behavior

Microsoft Learn notes specific behavior of /R and /B on SSDs: “Marking clusters bad is logical, not physical remapping. As sector reads are faster on SSDs, running the /r and /b parameters complete the process faster due to its physical makeup. There might be cases where on large capacity SSDs where chkdsk might complete its process too quickly.” The implications:

• On SSDs, /R reads every cell to identify problematic ones; faster than HDD due to lack of seek time.
• “Bad cluster” marking is purely logical; the SSD controller continues to manage the underlying NAND independently.
• chkdsk doesn’t trigger SSD garbage collection or wear leveling adjustments.
• For SSD-specific issues (firmware bugs, controller corruption), chkdsk has no effect; vendor utilities required.
• Running /R on SSDs without specific cause is not recommended; it adds wear without significant benefit.

chkdsk on NTFS volumes follows a structured five-stage process when running with /R or /B parameters; without those parameters, only the first three stages run.

The stage breakdown

The AnoopCNair chkdsk reference summarizes the structure: “There are 5 stages of checking the disk… Stage 1 examines the basic file system structure and verifies the files and their records.”³ Each stage targets a specific aspect of NTFS metadata or storage:

Stage	Title	Purpose	Runs with
1	Examining basic file system structure	MFT records, file record verification	All modes
2	Examining file name linkage	Index entries, orphan reconnection	All modes
3	Examining security descriptors	Security descriptors, USN Journal	All modes
4	Looking for bad clusters in user file data	Surface scan of allocated clusters	/R or /B only
5	Looking for bad, free clusters	Surface scan of unallocated clusters	/R or /B only

Stage 1: file record verification

Stage 1 examines the Master File Table (MFT) and verifies each file record. Specifically:

• Reads each MFT record and validates its structure (header signature, record length, attributes).
• Identifies orphan file records (records not properly linked to directory structures).
• Checks for bad file records (corrupted MFT entries that can’t be parsed).
• Reports counts: “X file records processed, Y large file records processed, 0 bad file records processed.”
• Phase duration typically reported in milliseconds to minutes depending on file count.

Stage 2: filename linkage

Stage 2 verifies the relationships between file records and directory index entries:

• Processes index entries in $INDEX_ROOT and $INDEX_ALLOCATION attributes of directories.
• Verifies that each filename properly links to a valid file record.
• Identifies orphan files (file records without proper directory entries) and attempts to reconnect them.
• Files that cannot be reconnected are recovered to “lost and found” (FOUND.000).
• Processes reparse records (junction points, symbolic links, mount points).
• Reports counts: “X index entries processed, Y unindexed files scanned, Z unindexed files recovered to lost and found.”

Stage 3: security descriptors and USN journal

Stage 3 verifies access control metadata:

• Validates each security descriptor (ACL, owner, group, audit information).
• Cleans up unused security descriptors from $Secure file’s $SDS, $SII, and $SDH streams.
• Verifies data attributes are well-formed.
• Performs USN Journal verification (if enabled): validates the change journal’s structure and contents.
• Reports counts: “X data files processed, Y USN bytes processed.”

Stage 4: bad clusters in user file data

Stage 4 (only with /R or /B) performs the surface scan that gives chkdsk /r its long runtime:

• Reads every cluster allocated to user files.
• Identifies physically unreadable clusters via read errors.
• Attempts to relocate readable data from bad clusters to good clusters.
• Marks bad clusters in the $BadClus metafile to prevent future allocation.
• Reports per-file: “Read failure with status 0xc0000185 at offset X for Y bytes” when bad sectors found.
• Failure mode: “The disk does not have enough space to replace bad clusters detected in file X” indicates chkdsk cannot find a working cluster to relocate the data into.
• Phase duration can be hours to days for large drives.

Stage 5: bad and free clusters

Stage 5 (only with /R or /B) extends surface scanning to unallocated space:

• Reads every unallocated cluster on the volume.
• Identifies clusters that are physically unreadable.
• Marks any bad free clusters in $BadClus to prevent future allocation.
• Significantly faster than Stage 4 because no data relocation is required.
• Reports counts: “X free clusters processed, free space verification is complete.”

When chkdsk is interrupted

The Microsoft Learn reference addresses interruption: “Interrupting chkdsk isn’t recommended. However, canceling or interrupting chkdsk shouldn’t leave the volume any more corrupt than it was before chkdsk was run. Running chkdsk again checks and should repair any remaining corruption on the volume.” The behavior:

• Ctrl+C or system shutdown stops chkdsk at the current stage.
• Already-completed stages remain effective; the volume retains any repairs made.
• The volume dirty bit remains set, triggering chkdsk to run again at next boot.
• Running chkdsk again completes any remaining work; doesn’t restart from Stage 1 unless explicitly requested.

FOUND.000 is the hidden recovery directory chkdsk creates to store data fragments that can’t be linked back to the file system structure. Understanding this mechanism helps users recover potentially-valuable data after chkdsk operations.

The FOUND.000 directory convention

The DataNumen chkdsk reference describes the convention: “When CHKDSK encounters corrupted or orphaned data during repairs, it creates a hidden folder named FOUND.000 in the root directory of the scanned drive. If this folder already exists from a previous scan, Windows creates FOUND.001, FOUND.002, and so on. This folder serves as a recovery location where CHKDSK stores file fragments and data clusters that cannot be properly linked to the file system structure. The folder remains hidden by default and only becomes visible when you enable ‘Show hidden files, folders, and drives’ in File Explorer’s View options.”⁴

The .CHK file naming convention

Inside FOUND.000, chkdsk creates files with specific naming patterns:

• FILE0000.CHK, FILE0001.CHK, FILE0002.CHK: data fragments from corrupted files; sequentially numbered.
• DIR0000.CHK, DIR0001.CHK: directory metadata from corrupted folder structures; less common, indicates more severe corruption.
• Each .CHK file may contain: a complete file (rare), fragments of a single file, or mixed fragments from multiple files.
• Original filenames are lost: the directory entries pointing to these files were corrupted, so only the data content survives.
• File extensions don’t match content: all files use .CHK regardless of original type.

The original FAT prompt

The Microsoft Learn FAT chkdsk documentation describes the original behavior on FAT volumes: “Because repairs on FAT file systems usually change a disk’s file allocation table and sometimes cause a loss of data, chkdsk might display a confirmation message similar to the following: 10 lost allocation units found in 3 chains. Convert lost chains to files? If you press Y, Windows saves each lost chain in the root directory as a file with a name in the format File<nnnn>.chk. When chkdsk finishes, you can check these files to see if they contain any data you need. If you press N, Windows fixes the disk, but it doesn’t save the contents of the lost allocation units.”

Recovering data from .CHK files

Recovering data from FOUND.000 files requires manual analysis since the original filenames and types are unknown. The process:

1. Enable hidden file viewing: File Explorer → View → Hidden items checked.
2. Locate FOUND.000: in the root of the scanned drive.
3. Identify file types: use signature analysis tools (TrID, DROID, hex editors) to determine each .CHK file’s actual format.
4. Rename with correct extension: e.g., rename FILE0000.CHK to FILE0000.docx if it’s a Word document.
5. Test file integrity: open with appropriate application; some files may be partial or corrupted.
6. Recover usable files: save successfully-opened files with meaningful names.
7. Discard remainder: after recovery attempts, delete remaining .CHK files and the FOUND.000 directory.

Tools that help with .CHK recovery

Several tools assist with FOUND.000 file analysis:

• TrID (File Identifier): command-line file type identification by signature.
• UnCHK or .CHK File Recovery utilities: automated extension assignment based on signatures.
• Hex editors (HxD, 010 Editor): manual signature inspection at file offset 0.
• File carving tools (PhotoRec, scalpel): can extract embedded files from larger .CHK fragments.
• Specialized data recovery software: often handles .CHK files as part of broader recovery workflow.

When to delete FOUND.000

The FOUND.000 directory should be analyzed before deletion. Considerations:

• If the contents are unfamiliar, attempt recovery before deletion in case important data is hidden in the fragments.
• If recent backups exist and FOUND.000 contains nothing important, deletion is safe.
• If the .CHK files are very small (under 1 KB), they’re likely fragments of system files with no recovery value.
• If the .CHK files are large (multi-MB or GB), they may represent significant user data worth investigating.
• FOUND.000 occupies real disk space; deletion frees that space for normal use.

chkdsk’s relationship with data recovery is complex: it can both help and harm depending on the scenario. Understanding when to run chkdsk and when to avoid it is essential for successful recovery outcomes.

The fundamental data recovery rule

The DataNumen chkdsk reference captures the principle: “For data recovery considerations, decide whether you need the data or can afford to lose it. If recovery is essential, use recovery software before CHKDSK. If the file system is more important than the data, run chkdsk /f /r to restore functionality. Cloning creates a sector-by-sector duplicate of the entire drive including errors, while file transfer copies only accessible files. Clone failing drives before attempting any repairs to preserve recovery options.”⁵

Why chkdsk can harm recovery

chkdsk modifies file system metadata to restore consistency, which can interfere with subsequent recovery:

• MFT modifications: chkdsk may overwrite MFT records that recovery tools could otherwise use to identify deleted files.
• $BadClus updates: marking clusters bad changes the cluster allocation map; recovery tools may interpret data on those clusters as gone.
• Directory index repairs: rebuilding $INDEX_ROOT can lose pointers to deleted files that were still recoverable.
• Orphan file relocation: moving files to FOUND.000 strips original filenames and directory context.
• Surface scan writes: /R reads bad sectors and writes to good ones; this can overwrite areas containing recoverable deleted data.
• Security descriptor cleanup: removes metadata that might be useful for forensic analysis.

The image-first recovery workflow

The standard professional recovery workflow with chkdsk:

1. Stop using the drive: mount it read-only or disconnect to prevent further writes.
2. Image the drive: use ddrescue, HDDSuperClone, or commercial imager to create a sector-level disk image.
3. Run recovery against the image: use specialized recovery software on the image, never the original drive.
4. Recover usable files: save recovered files to a separate destination drive.
5. Validate recovered data: confirm critical files are intact and usable.
6. Optionally run chkdsk on the original drive: only if you want to restore the drive to functional state for reuse.
7. Reformat for reuse: if the drive is to be reused, full format ensures clean state.

When chkdsk is appropriate

Despite the risks, chkdsk has legitimate roles in many scenarios:

• Routine maintenance: periodic chkdsk on healthy drives to catch developing issues early.
• Post-crash recovery: automatic boot-time chkdsk after unclean shutdown to restore file system consistency.
• System drive issues: Windows can’t boot due to file system corruption; chkdsk during recovery boot is the standard fix.
• Confirmed data loss acceptance: data has already been recovered or written off; chkdsk to restore functional drive.
• Fresh drives or new file systems: verifying integrity of newly-formatted volumes.
• Pre-deployment checks: validating drives before putting them into production.

When chkdsk is dangerous

Specific scenarios where chkdsk should be avoided or deferred:

• Failing or marginal drives: /R surface scan stresses already-weak drives, accelerating failure.
• Drives with critical irreplaceable data: any modification risks making recovery harder.
• Drives showing “Drive Not Accessible” or RAW state: chkdsk may convert recoverable RAW partitions into more-damaged states.
• Recently deleted file scenarios: chkdsk modifications can overwrite the metadata recovery tools rely on.
• Drives with mechanical issues: head crashes, motor failures, PCB damage; running chkdsk can cause additional damage.
• BitLocker-encrypted drives in unlocked state: filesystem operations on encrypted volumes have unique failure modes.

The “chkdsk made it worse” scenario

A common consumer recovery case: user runs chkdsk hoping to fix a problem, then discovers files are missing or moved to FOUND.000. Recovery prospects:

• Data in FOUND.000 may be partially recoverable through .CHK file analysis.
• Data overwritten by chkdsk’s repair operations is often unrecoverable.
• Recovery from a chkdsk-modified drive yields fewer files than recovery from the original corrupted state.
• The lesson reinforced by professional recovery: image first, then experiment with chkdsk only on the image or a copy.

Modern alternatives

chkdsk’s role has been supplemented (not replaced) by modern Windows features:

• Self-Healing NTFS (Vista+): automatic detection and repair of common corruption patterns at runtime; reduces dependence on offline chkdsk.
• Repair-Volume PowerShell cmdlet: modern PowerShell wrapper with /scan, /spotfix, and /forceofflinefix equivalents; cleaner interface for scripting.
• Storage Spaces (Win 8+): integrity streams provide automatic corruption detection and self-healing; reduces traditional file system corruption scenarios.
• ReFS (Windows Server): Resilient File System has built-in checksums and automatic repair; designed to make chkdsk-like operations unnecessary.
• Windows Recovery Environment (WinRE): chkdsk available in offline recovery mode for system drives that won’t boot.