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 does not fix any errors. If used with the /f, /r, /x, or /b parameters, it fixes errors on the volume.
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 click Run as administrator.
Interrupting chkdsk is not recommended. However, canceling or interrupting chkdsk should not 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.
Chkdsk can be used only for local disks. The command cannot be used with a local drive letter that has been redirected over the network.
Syntax
Parameters
| Parameter | Description |
|---|---|
| Specifies the drive letter (followed by a colon), mount point, or volume name. | |
| [ [ |
]
Remarks
The /i or /c switch reduces the amount of time required to run chkdsk by skipping certain volume checks.
If you want chkdsk to correct disk errors, you can’t have open files on the drive. If files are open, the following error message appears:
If you choose to check the drive the next time you restart the computer, chkdsk checks the drive and corrects errors automatically when you restart the computer. If the drive partition is a boot partition, chkdsk automatically restarts the computer after it checks the drive.
You can also use the chkntfs /c command to schedule the volume to be checked the next time the computer is restarted. Use the fsutil dirty set command to set the volume’s dirty bit (indicating corruption), so that Windows runs chkdsk when the computer is restarted.
You should use chkdsk occasionally on FAT and NTFS file systems to check for disk errors. Chkdsk examines disk space and disk use and provides a status report specific to each file system. The status report shows errors found in the file system. If you run chkdsk without the /f parameter on an active partition, it might report spurious errors because it cannot lock the drive.
Chkdsk corrects logical disk errors only if you specify the /f parameter. Chkdsk must be able to lock the drive to correct errors.
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:
If you press Y, Windows saves each lost chain in the root directory as a file with a name in the format File .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 does not save the contents of the lost allocation units.
If you don’t use the /f parameter, chkdsk displays a message that the file needs to be fixed, but it does not fix any errors.
If you use chkdsk /f* on a very large disk or a disk with a very large number of files (for example, millions of files), chkdsk /f might take a long time to complete.
Use the /r parameter to find physical disk errors in the file system and attempt to recover data from any affected disk sectors.
If you specify the /f parameter, chkdsk displays an error message if there are open files on the disk. If you do not specify the /f parameter and open files exist, chkdsk might report lost allocation units on the disk. This could happen if open files have not yet been recorded in the file allocation table. If chkdsk reports the loss of a large number of allocation units, consider repairing the disk.
Because the Shadow Copies for Shared Folders source volume cannot be locked while Shadow Copies for Shared Folders is enabled, running chkdsk against the source volume might report false errors or cause chkdsk to unexpectedly quit. You can, however, check shadow copies for errors by running chkdsk in Read-only mode (without parameters) to check the Shadow Copies for Shared Folders storage volume.
The chkdsk command, with different parameters, is available from the Recovery Console.
On servers that are infrequently restarted, you may want to use the chkntfs or the fsutil dirty query commands to determine whether the volume’s dirty bit is already set before running chkdsk.
Understanding exit codes
The following table lists the exit codes that chkdsk reports after it has finished.
| Exit code | Description |
|---|---|
| 0 | No errors were found. |
| 1 | Errors were found and fixed. |
| 2 | Performed disk cleanup (such as garbage collection) or did not perform cleanup because /f was not specified. |
| 3 | Could not check the disk, errors could not be fixed, or errors were not fixed because /f was not specified. |
Examples
To check the disk in drive D and have Windows fix errors, type:
If it encounters errors, chkdsk pauses and displays messages. Chkdsk finishes by displaying a report that lists the status of the disk. You cannot open any files on the specified drive until chkdsk finishes.
To check all files on a FAT disk in the current directory for noncontiguous blocks, type:
Chkdsk displays a status report, and then lists the files that match the file specifications that have noncontiguous blocks.
chkdsk aborted corrupt master file list. What do i do?
Replies (4)
Did you stop the chkdsk process while it was running?
Let’s follow these methods and check if it helps.
a) You may try to boot into ‘safe mode with networking’ and check if the issue persists. It will start Windows 7 with a limited set of files and drivers. Startup programs do not run in safe mode, and only the basic drivers needed to start Windows are installed, follow the steps to boot the computer in safe mode:
i. Restart the computer.
ii. Start tapping F8 key.
iii. You will get advanced boot option window.
iv. Select the option “Safe mode”.
b) You may run ‘chkdsk /r’ from command prompt and do not abort the chkdsk process till it gets completed.
i. Click on Start, type ‘cmd’ in start search box.
ii. Right click on ‘cmd.exe’ in the Program list and then select the option Run as administrator.
iii. If you are prompted for an administrator password or for confirmation, type your password, or click Continue.
iv. In the command prompt window, type ‘chkdsk /r’ in the command prompt.
For more information, refer: Check a drive for errors
If ‘Method 1’ doesn’t help, you may perform startup repair and check if you are able to boot to desktop. You will have to boot from the Windows 7 DVD and get to the Win RE (Windows Repair Environment) and choose Startup Repair from the menu.
a. Insert the installation disc.
b. Restart your computer.
c. If prompted, press any key to start Windows from the installation disc.
Note: If your computer is not configured to start from a CD or DVD, check the information that came with your computer. You may need to change your computer’s BIOS settings.
d. Choose your language settings, and then click Next.
e. Click Repair your computer.
f. Select the operating system you want to repair, and then click Next.
g. On the System Recovery Options menu, click Startup Repair. Startup Repair might prompt you to make choices as it tries to fix the problem, and if necessary, it might restart your computer as it makes repairs.
Hope the information helps. Please post back and let us know.
Regards
Debleena S
Microsoft Answers Support Engineer
Windows chkdsk replaced bad cluster — are files now corrupted?
I ran chkdsk on a drive and when it got to stage 4 (verifying file data), this message appeared for some files:
Does this mean that these files are now corrupt? I’m mainly concerned about ISOs and executables. Unfortunately, I don’t have hashes of them so I have nothing to check their integrity against after chkdsk finishes running.
If it’s relevant, this is a mechanical hard drive, a 2TB Western Digital Green.
4 Answers 4
The answer is, it depends. the file was at least in part occupying a bad cluster, which in effect corrupted the file. chkdsk reallocated the sector (pointed that address to a not-bad location on the disk surface) and attempted to copy the contents of the bad cluster to it. there is no guarantee however that the data in the source cluster could be fully recovered to the destination. if it was, your file is intact, but if it wasn’t possible to recover the data completely and accurately, there will have been some corruption.
unfourtunately, without a baseline, there is no way to tell.
Does this mean that these files are now corrupt? The files were corrupt and Windows was able to repair the file Unfortunately, I don’t have hashes of them so I have nothing to check their integrity against after chkdsk finishes running. I’m mainly concerned about ISOs and executables.
You will have to find those checksums depending on the file that chkdisk repaired shouldn’t be hard. In the end corruption of a cluster was detected. You should restore the file from your backup source.
If it’s relevant, this is a mechanical hard drive, a 2TB Western Digital Green.
You should start to backup your data more often so you have something to compare checksums too.
If the file was a system file you should run sfc /scannow to verify the integrity of Windows.
Often, a file is allocated clusters on a disk but is not necessarily storing meaningful data in those clusters. For example:
- Virtual machines which have their disk images preallocated to reserve storage space and avoid fragmentation. Half downloaded files are often preallocated this way too.
- A database which has had records deleted but which has not yet been vacuumed. On a desktop system, «databases» may include mailboxes, instant messenger history, browser bookmarks, password managers, photo catalogs, music libraries, or the Windows registry.
In such a case, the files will usually contain some meaningful clusters, and some clusters which contain unrelated data you have deleted in the past, such as files marked by the filesystem to be overwritten. So, sometimes even if a file is technically corrupt, you may be fortunate that the integrity of the file is not compromised.
However, it would be a good idea to check the integrity of the file with a tool that understands the specific file format, where possible. Such tools exist for most forms of disk image, database and media file.
In a case like this, one could use an hexadecimal editor and search if there is an abnormally long sequence of 00s interrupting an otherwise complex data area. Typically, if at some point you see a multiple of 512 bytes of blank data, starting at a 512 multiple offset relative to the begining of the file (sector boundary), in an area where there should be (seemingly) random characters (if it’s a binary file), or a readable sequence of characters (if it’s a text file), then you can be pretty sure that some corruption has occured.
Of course, for that to be manageable would at least require a least of the bad sectors’ LBAs, it’s not practically possible to check every single file like this. The best course of action if there are bad sectors on a storage unit is to first clone it with a suitable tool (ddrescue is often recommanded), then run CHKDSK or any other tool designed to attempt an in-place repair, which can succeed or fail but will never explicitly report what the actual outcome was. Otherwise, the only reasonable way to detect such errors is to be attentive to any kind of glitch when later reading / playing / running the files that were stored on that device, and then check them with the method indicated above.
