The most fragile -- yet critical -- component in any computer is the hard disk. While hard drives have become much more dependable in the past 15 years, accidents still happen, and when they do, it's your data that gets chewed up and spat out like digital bubble gum.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
To complement the increased reliability of hard drives, the file systems used with them have also evolved. In Windows, FAT gave way to FAT32 and now NTFS (New Technology File System) -- or, rather, NTFS went from a server-only piece of exotica to the file system used on the desktop.
But a few things haven't changed, and one of them is the tool used to keep the file system consistent when things go wrong: chkdsk.
What is chkdsk?
Chkdsk's existence is encapsulated in the pronunciation of its name: check disk. When you run chkdsk from an administrator-level command line, it analyzes a particular volume -- hard drive, solid-state drive, removable disk, etc. -- for problems that might indicate an easily-fixed inconsistency or hardcore data corruption.
The most common form of the chkdsk command is:
chkdsk <volume> /f
- <volume> is a drive letter, e.g., C:
- The /f switch tells chkdsk to fix errors and not simply produce a report about the state of the disk, which is what happens if you run chkdsk with the volume name as the only parameter and no other switches.
Note that running without the /f parameter can return incomplete information about the nature of the problems on a disk, as shown in Figure 1.
If you run chkdsk without /f, the problems discovered may need to be fixed before other errors can be repaired. Furthermore, you should always run chkdsk at least one more time to determine if you need to repair anything afterwards the initial fix.
Some of the other commonly used switches for chkdsk include the following:
- /v -- Runs chkdsk in verbose mode. It explains in great detail which actions, if any, are being taken as it runs.
- /x -- Dismounts the volume to be checked before the check is run. If you're checking a nonsystem volume, use this option because it guarantees that the drive will not be accessed by other programs in the system during the check process. If you don't pass this parameter and you try to run chkdsk on a volume that's mounted, you'll be asked if you want to dismount it first. A volume that the system is using, -- such as the drive with the /Windows directory, can't be dismounted. Instead, you'll be asked if you want to run the disk check at the next reboot.
- /r -- Attempts to scan for and recover information from bad sectors on the disk. This option takes a long time to run -- hours on end for large drives. As a result, it should be used only if you want to recover information from a damaged disk that's been taken offline from its host.
- /i and /c -- These two options attempt to speed up checking NTFS volumes by skipping certain indexes and cycles, respectively, within the folder structure.
For a full list of options, type chkdsk /? in the command line.
Note that chkdsk must always be run with elevated privileges. If you try to run it as a nonadministrative user, it will print the following error to the console:
Access Denied as you do not have sufficient privileges. You have to invoke this utility running in elevated mode.
Chkdsk in action
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. This happens if one or more of the volumes in the system has its "dirty bit" set -- a flag on an NTFS volume that indicates a write was pending for that disk. Chkdsk runs for that volume to determine if all is well.
Regardless if chkdsk runs automatically or not, you should always run it on a volume in the following scenarios:
- If applications behave strangely or certain files cannot be read after a blue screen of death (BSOD) or an application crash
- If a disk was unmounted from the system without warning (as when a cable comes unplugged), and it doesn't reliably read when remounted
- If a disk appears to have suffered physical damage. Even if it's readable, it's generally best to inspect it completely if the contents are critical with the /r option.
The end results of any chkdsk operation are written to the application log with the event ID 26214, as shown in Figure 2.
Chkdsk from the Recovery Console
Chkdsk can also run from the Recovery Console in Windows XP. The options in the Recovery Console version of chkdsk are limited to /p, which is the same as /f, and /r.
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.
Chkdsk and self-healing NTFS in Windows 7
Some of the best new features in Windows Vista and Windows 7 were slipped in under the hood when no one was looking. This includes 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.
To that end, Microsoft added BugCheckOnCorrupt to NTFS. This feature does exactly what you think it does: If the system discovers NTFS corruption, it throws a blue screen of death and shuts everything down instead of attempting to spot fix it.
This may sound counterintuitive: Why would you want the system to crash in such a circumstance? But the idea is to stop the system from doing anything that might corrupt data, including attempting a repair, which could do more damage.
Although triggering a bug check may be extreme, it allows you to stop everything and make an image of the disk, or a backup of the most crucial data, before attempting a repair operation with chkdsk.
To turn on BugCheckOnCorrupt, issue the following command from an admin privilege command line:
fsutil behavior set BugcheckOnCorrupt 1
Reboot and then issue the following command, again from an administrative command line, for each drive you want to check:
fsutil repair set <drive name> 0x10
The command fsutil repair query <drive name> determines the repair status for a given drive. To disable BugCheckOnCorrupt for a particular drive, use fsutil repair set <drive name> 0x1; to turn it off completely systemwide, use fsutil behavior set BugCheckOnCorrupt 0.
Remember, you don't have to set BugCheckOnCorrupt unless you have doubts about the quality of your disk hardware.
Chkdsk and BugCheckOnCorrupt are critical utilities for monitoring Windows 7 systems. Knowing how to use them can help you when hardware goes bad.
ABOUT THE AUTHOR
Serdar Yegulalp is editor of the "Windows Power Users Newsletter." Check it out for the latest advice and musings on the world of Windows network administrators.