The Dirty Bit in XP

  johndrew 15:22 09 Jan 12

Whether I have found the root cause of the anomalies I have been experiencing I'm uncertain, but, hopefully someone here may be able to provide a bit more advice.

Basically I did a check to see if the 'dirty bit' was set and found it was - the drive was 'dirty'. I ran chkdsk /f /r which has showed no problems with either the NTFS system or the drive, however when I check the dirty bit it shows the drive as still dirty. I should add that no automatic request for chkdsk to run has ever shown up during boot which would normally be the case if the dirty bit was genuinely set. There could also be difficulty in using the Windows defrag which I don't suffer.

After a fair amount of digging I found this post which led me to check the Registry entry (HKEYLOCALMACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute) identified. There were no references as mentioned, but I did find there are three other "ControlSet" files above the "CurrentControlSet" numbered 001 to 003. Given that each appears to contain similar data to that identified as "CurrentControlSet" I wondered if these are corrupt and the cause of various problems as (presumably) each would be read at Boot/Startup.

I am aware that MS has never revealed the location of the Dirty Bit and it appears no one has found it. I am also aware that many have tried to cure 'stuck-in' dirty bit indications with little success. Any help/advice/experience would be appreciated.

With thanks in anticipation.

  Batch 09:21 10 Jan 12

Have you looked at the S.M.A.R.T. drive info? If not, install something like Acronis Drive Monitor so that you can inspect the underlying state of the drive.

Maybe the dirty bit is getting left on as the problem is beyond the scope of chkdsk.

As for Control Sets, AFAIK, the 001 to 003 ones are just old ones. See MS Control Set Info

  bjh 09:42 10 Jan 12

I have one computer that regularly gets "dirty" with me. It's a multi-boot machine, and the problem is that the two "c" drives are not recognised as identical...and neither are some of the other partitions. On one boot to Win XP, one hard drive has a larger C and D ; reboot to Win 7, on the other drive, and different drive sizes appear. Result: the dirty bit gets set as there's obviously a failure occurring.

I have just set FSUTIL to do a dirty query on the said drives, and if found, it's fixed. However, and here's the odd "bit"... it sometimes has to be cleared consecutively from both operating systems to remain clear. That defies logic, suggesting that the drive itself may be marked dirty, as well as the info being stored in the O/S. (Suppose it might make sense for USB drives that might get transposed to another computer).

I haven't researched this much - I just fix it and ignore. If your system has multi-boot to two or more hard drives, this might help explain the cause. The possibility that the dirty bit is (partially) marked on the partition itself may help....

  johndrew 10:29 10 Jan 12

Thanks for coming back.

In answer to your points:

I run HDD Health to monitor the S.M.A.R.T. condition of my drives. This has provided no warnings or other 'bad' indications for either drive (both are spit into two partitions.

The information on the Control Sets is helpful; I didn't pick it up when I was searching. Having read it I now understand their functions (roughly) but I don't have a 'clone' version - whether this is of value or not I'm unsure.

You could be right about the scope of chkdsk although I understood it to be a panacea for this type of problem prior to starting the searches; now I know it's far from it. Unfortunately there don't appear to be any better tools.

I only use a single boot set up, but as I said above there are two dives each with two partitions. The drives are not the same size and the partitions are uneven on them but I doubt this should have an effect.

A further interesting occurrence is that for the first time today I checked the function of defrag immediately after booting and it advised that "Chkdsk is scheduled on volume C: ..." and refused to run. I can get around using the Windows defrag tool but wonder if this is an indication that something is getting worse.

Any other suggestions short of a complete reinstall??

  johndrew 19:53 10 Jan 12


I have made a discovery (possibly one of the last to do so) that chkdsk functions slightly differently when run from the Repair Console than a Command Prompt. I appears to do a deeper scan and a more thorough repair job.

I have, as I said, run it from the Command prompt with nothing being found and the problem remaining. Today I ran it from the Repair Console and it reported that it had fixed one or more errors on the drive". On reboot it was NOT dirty. To check this I Restarted the PC again and checked with the same result.

You may also find it resolves the problem you report if you ran it for both boot drives in the same way.

  bjh 09:31 11 Jan 12


Yes, there's a fundamental difference between the two.

The cause of my dirty bits (!) would only be resolved by my reformatting my partitions to match...not happening! If the O/S doesn't know what's happening, so be it.

Glad your case may be helped. I should have pointed that out!

This thread is now locked and can not be replied to.

Nintendo Switch review: Hands-on with the intuitive modular console and its disappointing games…

1995-2015: How technology has changed the world in 20 years

VFX Oscar nominees 2017: Discover how the visual effects were created

Best alternatives to iTunes for Mac | Best music players for macOS: Free your music from the…