Chkdsk capabilities

CHKDSK (autochk.exe and chkdsk.exe, which share dll's) runs in a few stages (the below is for NTFS volumes, and a bit simplified):

Stage 1 - "Verifying Files". In this stage it examines the Master File Table (MFT). The MFT stores file attributes about each file and directory such as the file name, creation date, time stamps, etc. in File Record Segments (FRS). CHKDSK looks at the FRS's for internal consistency, and also builds two bitmaps (one showing the FRS's, and one showing actual clusters) that it compares to the bitmaps stored within the MFT.

Stage 2 - "Verifying Indexes". In this stage, it looks at the indexes (directories) on the NTFS volume. It checks each of the directories for internal consistency and makes sure that every file and directory in the FRS is contained within a directory. If a file is not in a directory, it is considered "orphaned" and CHKDSK either tries to put it in the folder indicated by the FRS for that file or it puts it in a "found" directory. It also verifies that every file/directory in the directory has a corresponding FRS entry. If the directory references a file or directory that isn't there, it removes that entry.

Stage 3 - "Verifying Security Descriptors". The Security Descriptors (containing security information such as ACL's and Auditing information) are stored in the actual file structure, and in this phase CHKDSK looks at each of these to make sure they are the correct structure and that they are internally consistent.

Stage 4 - "Verifying File Data". This stage occurs only if the /R command was used (or the box was checked from the GUI). In this stage, CHKDSK tries to read every sector on the disk. If /R was specified, it actually already did this stage once for the metadata and file data sectors in earlier stages. If it finds a bad sector, it adds the cluster the sector was in to the list of bad clusters and tries to move the data to a good sector (if it can't, it fills the new cluster with 0xFF).

Stage 5 - "Verifying Free Space". This also occurs only if /R is used. In this stage, CHKDSK tries to read from free sectors and adds bad clusters to the bad cluster list.

Hopefully the above answers your question. More information is available in this KB, this whitepaper, and this guide.

It should also be noted that NTFS has built-in metadata recovery features in the form of the NTFS transaction log. This is a separate process from CHKDSK. If the system turns off unexpectedly or crashes, when Windows starts back up it will do an NTFS Recovery operation using the information in the NTFS log file. This process is detailed in the whitepaper mentioned above in the "NTFS Transaction Log Recoverability" section.

CHKDSK is basically a parallel NTFS implementation (to NTFS.SYS) that concerns itself with "sanity-checking" the MFT and, as necessary, making repairs. I'm not aware of any comprehensive published specification on all the checks and "fixes" that CHKDSK performs on NTFS or FAT volumes. I'd guess that the only comprehensive specification would be the source code to CHKDSK itself. You can probably crib something together from Microsoft documentation, but I doubt you're going to find a technical description of each test or even a list of all the tests.

With respect to the boot sector and backup boot sector (if applicable for the type of filesytem being checked), I don't believe any version of CHKDSK makes any type of "repair" to the boot sector. If you smash your bootsector and lose the offset of the MFT, for example, CHKDSK isn't going to fix that.

The only type of "corruption" that I can say with certainty that CHKDSK can't do anyting about would be corruption within the data extents of the file itself. CHKDSK doesn't do anything with non-metadata information.

There's an old Microsoft whitepaper about CHKDSK available.

Windows 2000 Chkdsk Management