Windows maintains a piece of metadata for each volume called the "dirty bit." The dirty bit is a flag that tells the system if there are still pending changes to be written to the volume. If the system is shut down before the system's write cache is written out to disk, for instance, the dirty bit will remain set, and on the next reboot the computer will notice this and automatically run AUTOCHK.EXE (a version of CHKDSK) to determine if there is a data corruption problem.
Sometimes the dirty bit may be set spuriously, when in fact there is no cause for alarm. A crash can sometimes cause the dirty bit to be set when there was no data pending to be written, provoking a disk check the next time the system is rebooted. This in turn can cause a disk check to run persistently at each reboot, even when the dirty bit has not been set. If a disk check is running at each reboot regardless of whether or not the system was shut down cleanly, then the problem is no longer the dirty bit per se, but rather the way AUTOCHK.EXE has been configured to run at startup.
There are a few ways to manually override this. The first is to run CHKDSK /F on the drive in question; if it runs successfully, the AUTOCHK.EXE command is cleared and the system will no longer be checked at each reboot. Another way to do it is to edit the Registry directly and remove the AUTOCHK command. To do this, navigate to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession Manager in the Registry and look for a REG_MULTI_SZ value with the name BootExecute. Set the value of BootExecute to a null value. This will prevent AUTOCHK from running on next reboot.
On the whole, it's safest to first attempt to use CHKDSK /F on the drive that is being repeatedly checked at startup. Editing BootExecute should only be done if CHKDSK doesn't seem to be working. Running CHKDSK also has the added bonus of manually clearing the dirty bit.
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 -- and please share your thoughts as well!
This was first published in June 2004