Chkdsk analyzes the physical structure of your hard disk to make ensure it is healthy. It can repair problems related to bad sectors, lost clusters, and directory errors. These types of errors can be caused by System crashes or freezes, power glitches, and bad shutdowns from incorrectly turning off a computer.
Also, physically bumping a computer can cause the head that reads the disk to hit the surface and damage sectors. Once this type of error occurs, it can end up creating more errors, so a regularly scheduled disk check is part of good system maintenance.
Chkdsk can also serve as an early warning that a hard drive is deteriorating. Disks will gradually wear out and sectors may become bad. It is also possible to clone an old drive to a new drive if you do so before it develops any permanent bad sectors. Cloning will preserve your Windows installation, with all your programs, data and customizations. It is possible to force-clone a hard drive with bad sectors, but initially, it may not work any better than it did on the bad drive. The good news is that you may be able to run a Startup Repair to get the drive bootable again.
If chkdsk is needed, it will usually run automatically. For example, if your system crashes or its power is interrupted, chkdsk may run the next time the system boots. But regardless if “chkdsk” runs automatically or not, you should always run it on a volume in the following scenarios:
To run “chkdsk”, you need to run it as an Administrator. Also, 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. Rerunning “chkdsk” checks and will attempt to repair any remaining corruption on the drive.
If you want “chkdsk” to correct disk errors, you cannot have open files on the drive. If files are open, the following error message appears: “Chkdsk cannot run because the volume is in use by another process. Would you like to schedule this volume to be checked the next time the system.”
Once Windows has fully loaded, bring up another Command Prompt and enter chkdsk c: /f . Reply Y when asked if you want this to happen on the next boot. This should take you through 3 stages of the “chkdsk” scan and will unset that dirty bit. This can take 10 minutes or so depending on the size of your hard drive, and the numbers of errors it has to correct.”
Once booted back to Windows, open another Command Prompt and query the dirty bit again by entering “fsutil dirty query c:” and Windows should confirm that the dirty bit is no longer set on that drive.
You will have a choice to scan only, scan for and attempt to fix errors, scan for and attempt recovery of bad sectors, or scan for and attempt to fix errors and recovery of bad sectors.
Depending on the size of your drive, this might take well over an hour. For best results, don’t attempt to use your computer for any other tasks while it is checking for file system errors and bad sectors.
NOTE: The end results of any chkdsk operation run from within Windows are written to the application log with the event ID 26214.
Chkdsk can also be run from an elevated Command Prompt within Windows using chkdsk /r. Elevated means running as an administrator.
If you select repairs for a drive that is in use (for example, the partition that contains Windows), you’ll be prompted to reschedule the check for the next time you restart your computer. Type “y” and press “Enter“
Chkdsk can also be run from the Recovery Console in Windows XP or the Startup Repair feature in Vista and Windows 7. The options in the Recovery Console version of chkdsk are limited to /p, which is the same as /f, and /r. It is virtually the same as running chkdsk from the command prompt within Windows, but without being in Windows.
Running chkdsk from the Recovery Console is one way to determine if the system volume has been damaged, especially if the system was unexpectedly shut down and you didn’t have an opportunity to schedule a chkdsk operation beforehand.
Note that running chkdsk from the Recovery Console doesn’t log the output to the application log, since the appropriate services aren’t running.
Vista and Windows 7 includes a Self-Healing NTFS, a feature that improves how errors detected by the file subsystem would be isolated, scrubbed and repaired in the background. As a result of this feature, Chkdsk needs to run less often.
A possible downside of self-healing NTFS is that the spot checks can silently delete data without the user’s knowledge. Personally, I think this would happen only if you’re dealing with flaky disk hardware, but it’s possible to not know about flaky disk hardware until after something bad occurs.