• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

How to permanently disable Disk Check / Remove dirty bit that runs chkdsk upon reboot

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.
I ran across this topic doing a Google search (I know its old). There is a very good reason to disable chkdsk from running automatically. A few years ago, I had a computer which had 2 ATA Controllers. Over time, I removed/added drives, and at some point decided to move one of my data HDs to the other ATA controller. When I booted, I canceled past chkdsk and I was able to access all the data on the drive just fine. But, at some point the computer rebooted for some reason. When I turned on my monitor, I found chkdsk running saying that it was fixing corrupt data. Unfortunately, I was too late, somehow chkdsk thought everything on the HD was corrupted and in trying to automatically fix it had not only destroyed 90% of my files, but rendered most of them unrecoverable (with even the most powerful recovery software).

Recently, I temporarily moved an external (I had it in a USB Case) data drive to the internal ATA-133 controller and this has caused me concern that chkdsk might accidentally destroy the contents of that drive should the computer reboot unexpectedly [and I'm not present to cancel past chkdsk].
 
Thank you for resurrecting this thread. In April of 2007 I was on the verge of discovering the solution:


Date: Fri, 27 Apr 2007 16:30:01 -0700
Subject: RE: How can automatic running of chkdsk be permanently disabled?

Write a shutdown script that writes the correct reg entry. Put in a 5 sec
wait box with 'stop chkdsk? Y/N' defaulting to no. This script is set in the
Group Policy (gpedit.msc)
--
Mark L. Ferguson


But

A. I didn't know how and where to write a script.
B. I often use Superfast Shutdown and Superfast Reboot (http://www.xp-smoker.com/freeware.html)

which bypass scripts.

Code:
c627627   	
View profile
	 More options Apr 27 2007, 7:05 pm
Newsgroups: microsoft.public.windowsxp.help_and_support
From: c627627 <[email protected]>
Date: 27 Apr 2007 16:05:03 -0700
Local: Fri, Apr 27 2007 7:05 pm
Subject: How can automatic running of chkdsk be permanently disabled? (I know it shouldn't be)
Reply to author | Forward | Print | Individual message | Show original | Report this message | Find messages by this author
...but I have a specific reason for wanting to disable automatic
running of chkdsk (it sometimes runs after improper reboot, etc...) I
understand that this shouldn't be done on most systems used by average
users.

This can be done if I go to
HKEY_LOCAL_MACHINE \ SYSTEM \ CURRENTCONTROLSET \ CONTROL \ Session
Manager \

and change the value of BootExecute to
autocheck autochk /k:cdefghijklmnopqstuwxyz*

However the value changes "itself" after a while to
autocheck autochk /k:cdefghijklmnopqstuwxyz*
autocheck autochk *

(the autocheck autochk * is added which causes chkdsk to run after a
dirty bit is detected...)

Therefore this is a temporary, not a permanent solution to the
question.
Note that Chkntfs only temporarily disables Disk Check, not
permanently which is what I wish to do.

I also have a second followup question:
The dirty bit that XP sets, how is it removed from (all FAT32) system
if I boot into Windows 9x/Me on another partition? By that I mean the
dirty bit that "says" the volume is dirty and needs to be checked.

So if you have several partitions, is this info only on the Windows XP
partition...?

I understand that  the bit that XP sets is removed when it determines
that the file system is free of corruption but can it be removed
manually

· from within Windows XP (NTFS and FAT32.)

· from within Windows 9x/Me (provided no NTFS partitions exist of
course.)

· from a DOS boot up floppy (provided no NTFS partitions exist of
course.)

I reimage all the time so I have no need for unwanted disc scans.
(Lengthy) scans usually don't find any problems. Whatever it is that
they do to remove the dirty bit after finishing, can it be
'simulated,' so that if the dirty bit is set, it can actually be
removed (in theory) without a full scan?

I'm asking out of curiosity, I understand how important scanning can be...
 
If someone can post a step by step script creation process, that would help people.
 
I don't know how to permanently disable chkdsk, and I don't know how to remove the dirty bit (which is how I found this thread in the first place), but we do have a method by which we keep chkdsk from running automatically. It's a solution for our Win2K and Win2K3 servers, but I think it would translate to XP as well.

First of all I should say that I work in an IT department for the top Data Recovery company in the world. People who tell you not to disable chkdsk are just being lazy with their responses. It is easy to imagine any number of legitimate reasons to disable any application. If you want to do it, you should be able to do it. Agredon is not the only one who has had chkdsk ruin a drive. We have had several servers run chkdsk to "fix" errors. Working for a data recovery company has its benefits and we have always been able to recover our data. That being said, it is a very timely process, and our data recovery engineers are always annoyed when it happens because it is generally a lot quicker and easier for them to fix a corrupted disk that chkdsk hasn't already "fixed". Our data recovery engineers have instructed us to disable chkdsk, so we had to come up with some way of doing that.

Ours is a low tech solution. I should also say that it is only semi-permanent. When the dirty bit is set, chkdsk will run on the next reboot. But if you look closely, it's not chkdsk that runs but autochk.exe which then calls chkdsk.

We use Altiris to run a batch script to delete all instances of autochk.exe on our servers. It can be a bit tricky to find all of the instances, but once you've gotten rid of it, you shouldn't have any more chkdsk on startup problems. The dirty bit will still be there, and you will just see Windows try to start autochk, but then it will immediately error out saying it can't find autochk, and will continue the boot process. The benefit is that you will know when your server has a dirty bit set if you are watching it boot, but you will be able to decide what you want to do about it instead of M$ deciding for you.

The reason this fix is only semi-permanent is that sometimes autochk will reappear. This usually happens after a service pack, but can happen after minor updates as well. We just run the Altiris job every few months or so.

The limitation of the fix is that it only keeps chkdsk from running on a reboot. As a side note, we still get it running from time to time on our Microsoft Clustered File Servers. Sometimes when we fail a cluster instance over to its other node chkdsk will start running. You will see chkdsk running in task manager, and the disk resource will not come online until the disk is done with its chkdsk. You can just kill chkdsk in this instance and the disk should come online. In order to stop this happening use the cluster command

> cluster.exe res "<DiskResourceName>" /priv Skipchkdsk=1

Read about it here:
http://support.microsoft.com/kb/223023/en-us

If it helps, this is the batch file that we run to disable autochk:

Code:
REM You can use this code to delete autochk.exe from your machine 

REM The next snippet runs a dir command to find all the locations of autochk.exe on
REM the machine. The /s switch runs it recursively on all directories below C:\WINDOWS
REM The two greater than symbols create a file in the root of C: called autochk.txt
REM and redirect the output to this file.
dir c:\WINDOWS\autochk.exe /s >> C:\autochk.txt

REM This snippet reads the text file created in the previous step and finds the
REM string, "Directory", then prints any line containing the string and inserts the
REM output into a new file called "autonew.txt"
type C:\autochk.txt | find /i "Directory" >> C:\autonew.txt

REM This snippet reads each line in autonew.txt taking the first word (token)
REM after the third delimiter (in this case, a space) in each line.  It then uses
REM that token to delete the autocheck.exe in each directory.  Hopefully
REM that makes a little sense.  If it doesn't you can try reading the help for this
REM command.  Just type "for /?" at a command prompt.
for /f "tokens=3 delims= " %%i in (autonew.txt) do del %%i\autochk.exe

REM Finally, this snippet deletes the two files that it created to do the work with.
del c:\autochk.txt
del c:\autonew.txt
 
Last edited:
Thank you for posting cate0012. I learned the hard way never to apply any "updates" without drive imaging my operating system partition so your solution could be made permanent if it were applied prior to creation of every new drive image backup.

Whats is the concept of a "dirty bit," what does it mean and once set, why can it not be removed by accessing the drive from another operating system? Is it part of the registry or is it something that's set on the drive itself?


Is that batch file for cluster servers only?

I'm trying to decipher what the batch file means to see if this can be used on a home machine.
 
Yes you are right. This could be made pseudo-permanent if you removed all the instances of autochk from your machine before you took the image. Just make sure to re-run the script every time you apply major updates to your machine and then re-image when you are sure that it is still clean.

A "dirty bit" is the way that NTFS volumes are marked by the file system for an automatic chkdsk on the next reboot. It is set automatically when the file system thinks there is a problem with the volume. You can check whether a volume is marked dirty or not by using the chkntfs utility.

Just type in the following at a command prompt:

Code:
chkntfs C:

The output on my machine happens to be:
The type of the file system is NTFS.
C: is not dirty.


You can also use chkntfs to reset the dirty bit to keep chkdsk from running on your machine at bootup. That's useful when you need it, but there is a twofold problem with chkntfs. In the first place, some people (I'm one of them) can't be bothered to run chkntfs to see if the dirty bit is set every time they reboot their machines. Secondly, sometimes the dirty bit gets set as a result of an improper shutdown. Because you already need to be booted to run chkntfs, you won't be able to check the volume before autochk calls chkdsk.

That's where the batchfile to remove autochk comes in handy.

You can read more about chkntfs, autochk, chkdsk and the dirty bit here.

In answer to your question, the batch file contained in the code snippet in my last post is not only for clusters. I haven't tried it on all versions of Windows, but all the commands are standard dos commands. I would think it would be compatible all the way back to MS-DOS.

The lines that begin with REM are comments and I use them to clarify what the next bit of code does. I'll edit the original post to add more detail about what each command does, but rest assured that you could use it on a home machine as well as a server. If you want to see what it does run each command manually at a command prompt and check to see what's happening. For instance if you open the command prompt and run the command "dir C:\WINDOWS\autochk.exe /s >> C:\autochk.txt", you should be able to check the root of your C: drive for a file called "autochk.txt". Open it up and you will see something like the following:

Code:
 Volume in drive C is SYSTEM
 Volume Serial Number is C4D6-30E5

 Directory of C:\WINDOWS\$NtServicePackUninstall$

03/08/2004  23:56           588,800 autochk.exe
               1 File(s)        588,800 bytes

 Directory of C:\WINDOWS\ServicePackFiles\i386

14/04/2008  00:12           588,800 autochk.exe
               1 File(s)        588,800 bytes

 Directory of C:\WINDOWS\system32

14/04/2008  00:12           588,800 autochk.exe
               1 File(s)        588,800 bytes

     Total Files Listed:
               3 File(s)      1,766,400 bytes
               0 Dir(s)   1,449,893,888 bytes free

That file just tells you all of the locations below C:\WINDOWS and its subfolders that contain a file called "autochk.exe". The next bit of code uses that file to parse out the directories that contain the file.

Once you're happy that each of the steps is working the way you want them to, you can copy the entire script into notepad, and save it as "delautochk.bat". Make sure to change the "Save as type:" dropdown menu to "All Files" before you save it. Otherwise the OS won't know it's executable. And sorry if the instructions I'm including are too basic. I don't know what your skill level is with this stuff, but it's more for other people who might stumble upon the forum in the future.

Hope that helps!
 
Last edited:
Useful info, much obliged.
cate0012 said:
And sorry if the instructions I'm including are too basic.
Once upon a time before PCs, I bought a Commodore 64 for my cousin. I wrote clear instructions and it didn't work, and it didn't work... Turns out my instructions failed to mention that you need to press [Enter] after each line. :santa:

So yeah when I post here, I try to post so people like that who come here can use the info.


What do you think about Post #22 of this thread. Does that not take care of the problem for almost everyone? (The reason I can't use it is because I use Superfast shutdown/reboot that just resets the machine bypassing everything including what's written in post #22).

Could you tell me how to also write the script mentioned in that post, just for my information?
 
Because you already need to be booted to run chkntfs, you won't be able to check the volume before autochk calls chkdsk.
In my example of a multi boot system, I can boot into Windows 98/Me where it is easily and permanently disabled.

So if you boot into another operating system, what's the command that you type in DOS to remove the dirty bit so that when you reboot into Windows XP, the scan doesn't start.
 
Regarding your question about disabling from a separate OS (Post #29):
I don't know how you would do this. I can only tell you what you would need in order to make it work. You would first need an OS with a "driver" installed that would allow you to mount, read and write to NTFS volumes. Windows98 & Me do not do this. You could try running 'chkntfs /x C: D:' but I doubt the app will run on Win98/Me in the first place (you will have to copy it over to your 98 box), and in the second place, it wouldn't be able to read your NTFS drive, so that even if it could run you'd be stopped there. I have Macs at home that can read NTFS by default, but not write. There are, however, some Linux drivers for NTFS. Google is your friend. Next you would need a program that runs on your alternate OS that would allow you to read and write to the HKey Local Machine registry hive. I know that this is possible, because I use a utility by a guy called 'PNordahl' that does this exact thing when you forget what the local admin password is on your NT/2000/XP/2003 workstation. Once you've found an app like this, you would open the HKLM hive and change the registry key 'HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute'. (Read the rest of this post for more specific instructions.) Then you would reboot back into WinXP and see that everything is working.

EDIT: Now that I'm thinking about it, you may be able to do all this through Mr. Nordahl's app. I haven't tried it, but I'm pretty sure you have the option to write to the registry. You could give it a try. I'll include a link, but if it goes stale, search google for 'PNordahl Password Recovery'. Here's the current link:http://home.eunet.no/pnordahl/ntpasswd/ Download the bootdisk iso and burn to CD-ROM. It's easier than booting to a floppy and WAY faster. Again, I think it's a lot more work than is necessary. The easiest thing for us was just to remove the application autochk.exe from our machines. See my explanation in post #25 and #27 if you want to do that.

Regarding post #22:
While writing a shutdown script to run via GP seems pretty easy, I don't think it would solve the problem for everyone. First of all, not everyone (I would venture to say less than 5%, and that's probably generous) runs a Windows 2000 or higher domain at home. I used to do it, but it was because I’m in IT, and a Windows administrator, and I did it to help me get better at my job. I have Macs at home now, so I don't still do it. I do have Windows virtual machines, but they are all in workgroups. Most home users are like this. When you run things via GP, you are typically in a windows domain environment, in fact, I don't know of any other way to use Group Policy.

I checked to see if you could run shutdown scripts without GP, but I couldn't find the analogous setting in the Local Policy editor. So if you were going to use a shutdown script, you would probably just want to do it manually, with a batch file that you run just before you are about to shutdown. However, group policies are just a collection of registry keys. Some of them can be "tattooed" (called so because they are permanent, and stick with a machine through reboot), but most of them are written under keys that get overwritten each time the machine refreshes its GP. I'm not inclined to find that information out because I don't think it will be that useful, but if someone wanted to do it, here's what one would have to do (This assumes you are running a Windows 2000 or 2003 domain, and in the case of 2000, have installed the GPMC. This also assumes that all your drives have letters assigned and are not mount points. If you have mount points you will have to add them to the script yourself because I have no way of knowing what they might be.):

1. Download and install ‘Process Monitor’ from Microsoft (written by Sysinternals until M$ bought them out). It’s free.
2. Set up a filter to look for registry keys with the string ‘autochk’. Refer to the app's documentation for how to do this.
3. Start Process monitor using your new filter.
4. Create a new txt file on your desktop (or wherever else you want and have access to).
5. Rename the file to ‘disablechkdsk.bat’ (Yes, you are sure you want to change the extension.)
6. Copy the following snippet of code into your batch file. Save it.
Code:
REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" /v BootExecute /t REG_MULTI_SZ /d "autocheck autochk /k:abcdefghijklmnopqrstuvwxyz *" /f

7. Open the Group Policy Management Console and create a test GPO.
8. Edit the new GPO.
9. Go to: Computer Configuration > Windows Settings > Scripts (Startup/Shutdown).
10. Right click on Shutdown. Choose ‘Properties’.
11. Click the ‘Add’ button.
12. Browse to the location of the file you created in step 1 and select the file. Click ‘OK’ twice to get back to your policy.
13. Create a test OU on your domain.
14. Apply the policy to this test OU.
15. Move a test machine into this OU.
16. Go to your machine, open a command prompt and run: ‘gpupdate /Force’.
17. Watch Process Monitor for the reg key that changes.
18. If it’s a key that has the word ‘Policy’ or ‘Policies’ in it, you’re out of luck. Not being in a domain, this key will get erased every time you boot up. If you don’t see that word, you might be able to apply that reg key to a machine that is in a workgroup and get it to run a script at shutdown.

Well that’s all I got. Like I said, probably not very useful to do that. It would be more of an academic exercise. It would be much easier to just run the batch file that you create in step 1 every time you shutdown. That would also let you get around your fast shutdown application as well, because you would be running the program before you tell your computer to shutdown.

If you have any questions, I’ll check back in a couple of days to see if I can answer them.
 
Last edited:
Just a quick note before reading your post in further detail: I have my current Windows XP on FAT32 so that it can be accesible from Windows 98/Me and I ordered my next system last night (Nehalem) and it'll be an XP/Vista multi boot on NTFS both.

I assume you can access XP/Vista partitions one from the other on NTFS.
 
Code:
REM You can use this code to delete autochk.exe from your machine 

REM The next snippet runs a dir command to find all the locations of autochk.exe on
REM the machine. The /s switch runs it recursively on all directories below C:\WINDOWS
REM The two greater than symbols create a file in the root of C: called autochk.txt
REM and redirect the output to this file.
dir c:\WINDOWS\autochk.exe /s >> C:\autochk.txt

REM This snippet reads the text file created in the previous step and finds the
REM string, "Directory", then prints any line containing the string and inserts the
REM output into a new file called "autonew.txt"
type C:\autochk.txt | find /i "Directory" >> C:\autonew.txt

REM This snippet reads each line in autonew.txt taking the first word (token)
REM after the third delimiter (in this case, a space) in each line.  It then uses
REM that token to delete the autocheck.exe in each directory.  Hopefully
REM that makes a little sense.  If it doesn't you can try reading the help for this
REM command.  Just type "for /?" at a command prompt.
for /f "tokens=3 delims= " %%i in (autonew.txt) do del %%i\autochk.exe

REM Finally, this snippet deletes the two files that it created to do the work with.
del c:\autochk.txt
del c:\autonew.txt

There is a bug in your (impressive) batch file. You have all instances of autochk.txt hardcoded to C:\, except for the FOR command. This means that if the batch file is saved anywhere other than C:\ (like I did), it fails. So,

for /f "tokens=3 delims= " %%i in (autonew.txt) do del %%i\autochk.exe

should be changed to

for /f "tokens=3 delims= " %%i in (c:\autonew.txt) do del %%i\autochk.exe



Thank you for the information you've taken the time to post here, it's helped me considerably.
 
hi, old thread but i want to add a comment. i m still looking for autochk on windows 7 and i havent tried modifying autocheck autochk * yet.

in case startup chkdsk ends with an apparent empty HDD (or non formated hdd). You can use any linux distro and probably you will be abble to recover all your data. It also works when you cannot access a partition from windows. you start your linux live cd and try to see if it can read the hdd or partition, and if it can see all your files, copy them to another partition or hdd. for recovering it as it was, i have no idea.
i just saw windows 7 trying to do a chkdsk for consistency and i m scared. it already deleted me an entire hdd with another windows and, i m not sure, but i think few weeks ago it apparently deleted me a full usb stick...
 
Welcome to the forums. This is a five year old thread now.

More likely than not, pulling out the USB stick w/o ejecting it first by clicking on the eject button next to the system clock caused the loss of data on your USB stick.


While it's unlikely that it will delete all data from a hard drive, in case of catastrophic failure, yes - recovery chances are better if no modifications to the drive are made whatsoever...

But this doesn't happen very often so checking the disk for errors is usually a good thing every once in a while.
 
Where dirty bit is located..

Hi friends,

I know that this topic is a little old, but now this (reset the dirty bit) can be done.
All you need is a hex editor in a live cd (or so) that have the ability to change bits on disk drives.
All the steps needed is in https://www.raymond.cc/blog/manually-reset-or-clear-dirty-bit-in-windows-without-chkdsk/.

Note that on FAT32/16 will be easier because the offset of the bit is always the same. But in NTFS you will need to search for the correct string depending on the OS you are running (win8 have the string a little different of win7 and win xp). It will be in different offsets for each ntfs volume.

Resetting the dirty bit to 00 again will make autochk.exe not scan the drive on startup, but that is not a permanent solution to disable the autochk, because the dirty bit can always be set back. I'm posting that only for curiosity purposes of "where dirty bit is"...

Hope that helped..
 
Hi and welcome to the forums!

I suppose the question is, if the dirty bit is there, and the solution is only temporary then instead of booting from the Live CD and running a Hex Editor and searching for the string... the Dirty Bit _can_ be temporarily changed from inside Windows as outlined below. What is the difference between doing that and flipping the string using a Hex Editor from outside Windows?

Either way, after all this time, I think it's safe to conclude in 2014 now that the only permanent way is to run a script each and every time just before proper shut down (and this of course doesn't help in case of improper shutdown.)


But here's the inside Windows disabling, is there a downside to this when compared to Live CD Hex? :

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager
Double click on BootExecute on the right side of the screen
change the value from default
autocheck autochk *
to:
autocheck autochk /k:cdefgh*


Where it says
/k:cdefgh*

that means drives c,d,e,f,g,h (you can substitute drive letters if you wish)



EDIT: Reading my own post from ten years ago, it appears that you could actually do this on operating systems prior to Windows XP and then it was impossible to permanently turn off mandatory chkdsk scandisk starting with the release of Windows XP.
 
Last edited:
Hi and welcome to the forums!

I suppose the question is, if the dirty bit is there, and the solution is only temporary then instead of booting from the Live CD and running a Hex Editor and searching for the string... the Dirty Bit _can_ be temporarily changed from inside Windows as outlined below. What is the difference between doing that and flipping the string using a Hex Editor from outside Windows?

Either way, after all this time, I think it's safe to conclude in 2014 now that the only permanent way is to run a script each and every time just before proper shut down (and this of course doesn't help in case of improper shutdown.)


But here's the inside Windows disabling, is there a downside to this when compared to Live CD Hex? :

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager
Double click on BootExecute on the right side of the screen
change the value from default
autocheck autochk *
to:
autocheck autochk /k:cdefgh*


Where it says
/k:cdefgh*

that means drives c,d,e,f,g,h (you can substitute drive letters if you wish)



EDIT: Reading my own post from ten years ago, it appears that you could actually do this on operating systems prior to Windows XP and then it was impossible to permanently turn off mandatory chkdsk scandisk starting with the release of Windows XP.

Thx..

As I said before.. Its only for curiosity purpose.. I cant find a reason to do that. By the way, using chkntfs /x cdefgh only includes a /k:cdefgh in the autocheck registry key. In this way windows will IGNORE the dirty bit of the volume even if it is set, but the dirty bit will still be there. My english is not so good.. but what I'm trying to explain is that using a /k in the autocheck registry key won't do nothing with the dirty bit itself (If it was set, will continue set... If it was zero, will continue too).

Its appears that windows don't let you change the bit to zero again (at least with system running), so I believe all solutions you will find has to be made outside windows.

A lot of work to nothing.. No downside comparing "/k" solution with that...
But If you could run a .bat (or something like this) with the ability to change the right bit just before windows begin to start, then you have a forever permanent solution... (don't ask me how to make this.. It will be hard and dangerous work, since if the command change the wrong bit you can have big trouble).

Anyway will be easier make a script that make the BootExecute registry key set with /k command. I think the improper shutdown problem would be avoided if you run this script not only just before shutdown, but every hour or so, forcing the value be exactly what you want all the time.

PS: I can't figure out why microsoft didn't put a function to reset the dirty bit in the fsutil command.. this would facilitate the task a lot...
 
Yes. That makes sense. Removing the dirty bit is better than ignoring it.
 
Back