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

[c627627]

I've been asking this question every once in a while for the past few years, no answer yet, it's 2005, let's try again :)

First of all,
• I understand that this "shouldn't be done," thank you :)
• Quick Googled Microsoft Docs solution is only temporary not permanent.


It's easy to disable Scandisk from running automatically at start up on Windows 98/Me, but I've been trying for years (for the last five years) to find a way to do that in Windows XP that would stick.

I manually scan the drive and do an image restore all the time so I have no need for automatic Disk Check (chkdsk) in Windows XP if it the power goes out. Here's the temporary trick:

Start Menu > Run... > Regedt32.exe
Go to
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:cdef*


Where it says
/k:cdef*

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


but autocheck autochk * returns every once in a while, re-enabling Disk Check (chkdsk).

The closest idea I had is to to find a way to assign a Read-Only attribute to just the
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ BootExecute

and no other subkey.


Can this be done?



Question 2: I have a dual boot XP/Me, if I boot into Me, how do I remove the dirty bit from the drive that's causing XP to run chkdsk because the power went out and the computer wasn't shut down 'properly'?


By the way for those that are interested:
98/Me doesn't reset itself, it's easy there:

To disable Scandisk from running automatically at start up on Windows 98/Me:

1. Start Menu > Run...
2. type
Msconfig
then click on OK
3. Click on Advanced... button
4. Check "Disable Scandisk after bad shutdown option"
5. OK, OK, then click Yes to restart the computer.


Would be much obliged if anyone could figure this out, even if the answer is "it's impossible, Windows XP is setup that way..."

[Avg]

Does this happen very often to you to the point to be annoying?

[c627627]

Ha, many-a-thread over the years was filled with questions exactly like yours -- but no suggestions of a solution :( I guess I shouldn't have said 'when the power goes out' rather, 'when the system is reset improperly...'

...and yes.

(Usually I first get multiple lists of reasons why this shouldn't be done... :( )

[Avg]

I just wanted to know cause it doesn't really bother me when it happens, because it rarely happens and I don't have a back up or anything, have you tried contacting microsoft it's a long shot but it's still worth it. And if that dude that knows a lot about os doens't know that has a bike as his avatar, then I think it's a long shot that anyone else here will know.

Good luck searching though

[ThePerfectCore]

Convert to NTFS, dump ME. :P

[DaWiper]

Is scandisk still a file? Or is it built-in somewhere?
Wouldn't it be possible to change the scandisk executable with a dummy file like a .bat file that does nothing? And keep scandisk around with another name?

[Avg]

Convert to NTFS, dump ME. :P

He is already using Xp, he says tha he knows how to do this with windows 98/me but hasn't been able to do it with windows xp.

[turd]

The Chkntfs.exe utility has been developed by Microsoft and is available in Microsoft Windows NT 4.0 Service Pack 2 and later versions of Windows. It is designed to disable the automatic running of chkdsk on specific volumes, when Windows restarts from an improper shutdown. Chkntfs can also be used to unschedule a chkdsk if chkdsk /f was used to schedule a chkdsk on an active volume on the next system restart.


Chkntfs is a utility that enables a system administrator to exclude volumes from being checked by the autochk program. The utility is run from a command prompt and has the following command line options:

syntax
CHKNTFS drive: [...]
CHKNTFS /C drive: [...]
CHKNTFS /X drive: [...]
CHKNTFS /t[:Time]
CHKNTFS /D

key
drive : Specifies a drive letter.

/C : Check - schedules chkdsk to be run at the next reboot.

/X : Exclude a drive from the default boot-time check.
Excluded drives are not accumulated between command invocations.

/T : Change the Autochk.exe initiation countdown time (time in seconds)
If you don't specify Time: displays the current countdown time.

/D : Restore the machine to the default behavior; all drives are
checked at boot time and chkdsk is run on those that are dirty.
This undoes the effect of the /X option.

If no switches are specified, CHKNTFS will display the status of the dirty bit for each drive.

/T option is new in Win XP

Examples:

chkntfs /x c: This disables chkdsk from running on drive C:

chkntfs /x d: e: This disables chkdsk from running on drives D: and E:.


The chkntfs /x commands are not cumulative, the command overwrites any previous drive exclusions that have been established. In the above example, chkntfs only disables the chkdsk checking on drives D and E, drive C is not checked for the presence of a dirty bit.


http://support.microsoft.com/?kbid=160963

[c627627]

Note that Chkntfs only temprarily disables Disk Check, not permanently which is what I wish to do.

[turd]

You sure that it is temp? I have used it and it seemed to stick, and it even seems to read that it is not temp to me, but you may well be right. But could you batch it at shutdown or startup and get it the way you want?

[redduc900]

Save the following .txt file with a .reg extension, and merge it into your Registry...

[c627627]

Huh.
:)
I hesitated to PM you.
:)
The man with the plan.


Just out of curiosity, the dirty bit that XP sets, how is it removed from (all FAT32) system if I boot into Windows 9x/Me on another partition.


Thank you very much redduc900.

[redduc900]

Just out of curiosity, the dirty bit that XP sets, how is it removed from (all FAT32) system if I boot into WIndows 9x/Me on another partition
I'm not sure I follow you.
I hesitated to PM you
You can feel free to PM me anytime you'd like, as can anyone on the forums.

[c627627]

You know, 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 can try to explain further if it isn't clear.

[redduc900]

My understanding of it is...the "dirty" bit is a bit in the boot sector (for FAT or FAT32 volumes), or in the MFT (for NTFS volumes), that as you know is checked when Windows starts. This bit is checked to determine whether corruption has been detected in the file system. If the dirty bit is set on a volume, Autochk runs to correct any errors on the volume.

On NTFS volumes, the dirty bit is typically set only if the file system has detected potential corruption. In this case, an event is logged in the System event log.

[c627627]

How is the dirty bit removed

• 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.)

[redduc900]

Just out of curiosity, the dirty bit that XP sets, how is it removed from (all FAT32) system if I boot into Windows 9x/Me on another partition
The bit that XP sets (either in the MFT of an NTFS volume, or in the boot sector of a FAT or FAT32 volume) is removed when it determines that the file system is free of corruption.
How is the dirty bit removed

• 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.)
AFAIK, and I could be wrong here, but a non-NT based OS doesn't recognize the bit set by XP/W2K...in the boot sector of the volume in which it resides. I believe the NT based OS which sets the bit is the only OS capable of removing it...a Win9x based OS or a DOS bootdisk won't recognize it.

[c627627]

Thank you.

When you say "...when it determines that the file system is free of corruption." that means after running a scan, which will be run when you boot into XP ordinarily?

So if the system is reset "improperly", is that one of the times when the dirty bit is set? If so, there is no way therefore to remove it unless you run a scan?

[redduc900]

When you say "...when it determines that the file system is free of corruption." that means after running a scan, which will be run when you boot into XP ordinarily?
Yes, after Autochk runs and corrects any and all file system errors on the volume, will XP then remove the dirty bit from the MFT or the boot sector of the damaged volume.
So if the system is reset "improperly", is that one of the times when the dirty bit is set? If so, there is no way therefore to remove it unless you run a scan?
That's right, although the dirty bit isn't always set after an improper shutdown...at least not when running an NT-based OS using the NTFS file system. For example, rebooting the computer by pressing the reset button from within the GUI normally won't set the bit (unless of course there's obvious file system corruption)...unlike a Win9x system using the FAT or FAT32 file system. XP doesn't view a hard reset as an improper shutdown, unlike a Win9x OS...which will immediately run ScanDisk upon next reboot, and notify you of the fact that the OS was shut down improperly.

[c627627]

I have an all FAT32 system.
C: is XP
D: is Me
E: is where certain system folders are like Desktop, Start Menu, etc...

Rebooting the computer by pressing the reset button from within XP, did appear to trigger lengthy disk checking of both C: drive (10GB) and E: drive (100GB).


That (lengthy) scan usually doesn't find any problems.

Whatever it is that it does to remove the dirty bit, I just need to confirm this once again (sorry), whatever it does to remove the dirty bit, that can't be 'simulated,' that can't be done by using third-party tools 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...

Thank you for your opinions and advice.

[agredon]

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].

[c627627]

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.

c627627
View profile
More options Apr 27 2007, 7:05 pm
Newsgroups: microsoft.public.windowsxp.help_and_support
From: c627627 <edi...@yahoo.com>
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...

[Dj Spiel]

yes! thanks so much for this

[c627627]

If someone can post a step by step script creation process, that would help people.

[cate0012]

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:


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

[c627627]

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.

[cate0012]

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:


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. (http://support.microsoft.com/kb/218461/en-us)

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:


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!

[c627627]

Useful info, much obliged.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?

[c627627]

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.

[cate0012]

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.

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.

[c627627]

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.

[slayerpunkclint]

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.

[sdarkn3ss]

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...

[c627627]

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.