boot-time chkdsk fails to execute

[jason]

This is new behavior. System is XP Pro SP2. If I schedule a chkdsk run
at boot time, it now fails to run. I've tried running chkdsk (without
/f) with XP running to see if it would clear the dirty bit, but it
doesn't seem to. My defrag program (Diskeeper) refuses to run at boot
because it spots the dirty bit..which would normally have been cleared
if chkdsk had indeed done its job.

What might be causing this? It happens on any volume I try.

Jason

 

[Claymore]

Hello Jason,

Don't know what you did to "clear" the Dirty Bit, but ...

chkdisk - Dirty Bit

**Parameters:

chkntfs drive: [...]
chkntfs /d
chkntfs /x drive: [...]
chkntfs /c drive: [...]

drive: Specifies a drive letter.
/D Restores 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.
/X Excludes a drive from the default boot-time check.
Excluded drives are not accumulated between command invocations.
/C Schedules chkdsk to be run at the next reboot if the
dirty bit has been set.


**Examples:

chkntfs C: {This would manually schedule a chkdsk on C: on the next
boot - the dirty bit is set for C:}

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

chkntfs /d {This restores the Dirty Bit to a normal condition - no
drives checked if the dirty bit has not been already set}


**Usage:

Go to Start => Run and type in "cmd" {without the quotes} to open a
Command window.
Type in "chkntfs C:" {without the quotes}
It should tell you if the dirty bit is set ("C: is dirty")
If it is, type in (or copy/paste) "chkntfs /x C:" {without the quotes}
This will prevent chkdsk from scanning drive C: at startup.

To reset it to normal, again open a Command window, and type in
"chkntfs /d"


**Purpose

The dirty bit is set for two main causes - a software problem such as
your improper shutdown, or a more serious hardware problem that can
indicate a failing drive. It is this dirty bit that during the
transfer of data instructs your computer to run the chkdsk at startup
(autochk).
The instruction I gave should get you out of the endless checking loop
as, yes, it will instruct chkdsk to run without checking drive C:. You
can then try some other things, such as chkdsk without the /f switch
(read-only), a defrag of the drive. You could then reset chkntfs back
to default using the /d switch and run chkdsk /f again.


**For more information see here:

http://support.microsoft.com/kb/160963

 

[thecreator]

Hi Jason,

Have you tried this:

Uninstall Diskeeper and reboot.

Now on reboot, go into My Computer and right-click on your operating
system Drive and click Properties.
Click Tools. Click Check Now. Check both options. Click Start and click
Yes to Schedule.

Before you reboot, go into your \Temp Folders and delete all possible
Files and Sub-folders. Then run Disk Cleanup and now reboot.

Once Chkdsk runs and fixes the Drive, reinstall Diskeeper after you
finsh the reboot.


--
thecreator




"jason"

 

[jason]

Hi Jason,

Have you tried this:

Uninstall Diskeeper and reboot.

Now on reboot, go into My Computer and right-click on your operating
system Drive and click Properties.
Click Tools. Click Check Now. Check both options. Click Start and click
Yes to Schedule.

I don't think there's anything the matter with Diskeeper. It's only
reacting to its own rule about not running at boot on a volume with the
dirty bit set. The trouble is that chkdsk fails to run; I had done as
you suggested to schedule boot-time chkdsk but it didn't work.

I have since learned that modifying the registry entry for autocheck to
its default (from a MS KB article) does the trick: chkdsk runs and
subsequent Diskeeper boot-time (with chkdsk enabled) works as it should.

Jason

 

[Guest]

Hi Jason,

I was experiencing the same problem with Diskepper and then I came across
the following post on the Microsoft forum (last 2 responses):-

http://www.microsoft.com/communitie...&p=1&tid=7b9885d3-84fa-40d2-88b9-ef924e8f4ddb

As the post says, I also used my OS CD to boot into Recovery Console, ran
CHKDSK C: /R... and it fixed the problem.

When it started it ran through the first 50% very quickly (within 30
seconds) and then seemed to stick at 51% with the hard disk light on all the
time. I left it running and it finished after about half an hour. Exited
recovery Console, and it rebooted. Having logged on I ran Diskkeeper on the
defective Drive and all was well.

I would therefore suggest you try the same.

Please note that I have also read that if you have a program called Spyware
Doctor, this can cause the problems as well
(http://www.microsoft.com/communitie...&p=1&tid=0e185274-d5fc-4354-b5ff-a55d86d82721 see second response).

HTH

 

[hbutler]

Hi Jason,

I was experiencing the same problem with Diskepper and then I came across
the following post on the Microsoft forum (last 2 responses):-

http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?&q...

As the post says, I also used my OS CD to boot into Recovery Console, ran
CHKDSK C: /R... and it fixed the problem.

When it started it ran through the first 50% very quickly (within 30
seconds) and then seemed to stick at 51% with the hard disk light on all the
time. I left it running and it finished after about half an hour. Exited
recovery Console, and it rebooted. Having logged on I ran Diskkeeper on the
defective Drive and all was well.

I would therefore suggest you try the same.

Please note that I have also read that if you have a program called Spyware
Doctor, this can cause the problems as well
(http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?&q...see second response).

HTH








- Show quoted text -

Most recently we have seen Spyware Dr. as blocking access to the disk,
but there could be other causes.

Another cause is that the CHKDSK utility is unable to gain exclusive
access to the volume. This is a requirement for the Microsoft CHKDSK /
F or /R command, because changes may be necessary to the file system
to fix or correct the errors that initially caused the volume "dirty"
bit to be set.

Diskeeper's Boot-Time defrag operation also requires exclusive access
to the volume to perform functions to move or defragment such files as
the Paging File or the Master File Table. Also, it is a safety
mechanism of Diskeeper that if the volume is in a dirty state we will
not run a defragmentation job until the volume status is no longer
dirty. I'm sure you can appreciate the level of safety we take with
your files.

The best recommendation we have found is that you need to discover
what application, service, device driver, etc.. is being started up
too soon and thus preventing the Microsoft CHKDSK utility from
performing its task.

There is a free utility from Microsoft called Autoruns.

This utility shows you what programs are configured to run during
system bootup or login, and shows you the entries in the order Windows
processes them. These programs include ones in your startup folder,
Run, RunOnce, and other Registry keys. A "Hide Signed Microsoft
Entries" option helps you to zoom in on third-party auto-starting
images that have been added to your system.

You'll probably be surprised at how many executables are launched
automatically!

Autoruns works on all versions of Windows including Windows XP 64-bit
Edition (x64) and Windows Server 2003 64-bit Edition (x64).

 

[Guest]

Having, resolved the ‘dirty’ issue, I find I cannot run the boot time defrag
using Diskeeper.

I intend to download Autoruns as suggested to see what else is running at
startup in a bid to see why the boot time does not run.