Cannot schedule chkdsk

[Guest]

Dear Dave Patrick:

Over the past couple of months you helped me as I struggled with the problem
of being unable to schedule a chkdsk on my machine. Of course, throughout
our struggles, the root cause of the problem seemed as elusive as ever.
Today, I am pleased to announce that I have finally discovered that cause and
felt perhaps you would appreciate me sharing this information with you. It
is probably only a matter of time before you presented with the same or
similar problem again by another user.

After my initial installation of Windows XP Pro SP1

Yes it is clear, but the situation remains that some system/boot start
device is not allowing autochk the required exclusive access to the disks.
This is the cause. Now the other issues you mention are only an immediate
effect or result of this for which I don't have an answer.

Afraid you really have two choices; either remove the device/service or put
up with it and use the RC when necessary.

--
Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

:
| Is the issue resolved? Well, only in part. When I ran chkdsk from the
| recovery console, I noticed that if either that dirty disk bit had been
set
| earlier, or if I had scheduled to perform a chkdsk at boot time, those
| settings still remained in effect after the chkdsk when I subsequently
| rebooted. Now, running chkdsk after Windows comes up completely that
problem
| seems to have vanished so that when I reboot, the system no longer tries
to
| initiate chkdsk repeatedly. The remaining problem is this: should I run
| diskscan from Norton Utilities, or if I should try to run chkdsk and be
told
| I need to schedule it to run at boottime, it simply will not execute -- on
| any of my four disk drives. When I later boot up, it tells me the scan
has
| been scheduled, is supposed to then let a few seconds elapse so that I can
| press a key if I want to abort the operation, and then on the next line
tells
| me that the operation was aborted. If I have scheduled each of the four
| disks to be scanned, it will run through all four of them in succession
and
| do exactly the same thing. There is no time lapse while the dots appear
on
| the screen (. . . .). While this may technically be totally inaccurate,
it
| is as though those extra keystrokes which ultimately abort the scans had
been
| stacked and were then immediately popped off the moment the scheduled scan
| kicked into swing. Of course, I never touch the keyboard. I know that
may
| not be what's going on, however it ACTS like a running program that is
just
| popping off it's input from the stack. My problem with this is that it's
not
| supposed to be that way. If the machine crashes, or power to a disk is
cut
| before finishing any final write operations (thus setting the dirty bit),
| Windows should check the disk for errors at the next boot and my machine
| simply will no longer do that. The good news is that you helped me get to
a
| point where I can run chkdsk manually when I know that it needs to be run,
| but I'd rather rely on the system to do this. It's late and I'm a little
| foggy headed now, but I hope that I have made this clear and not confused
you.

 

[Guest]

Dear Dave Patrick:

Over the past couple of months you helped me as I struggled with the problem
of being unable to schedule a chkdsk on my machine. Of course, throughout
our struggles, the root cause of the problem seemed as elusive as ever.
Today, I am pleased to announce that I have finally discovered that cause and
felt perhaps you would appreciate me sharing this information with you. It
is probably only a matter of time before you are presented with the same or
similar problem again by another user.

After my initial installation of Windows XP Pro SP1, I installed Recovery
Console on my main boot drive so that RC became a menu option at boot time.
Then, I was quick to install SP2 as soon as it became available, and although
I did not realize it at the time, RC was screwed up due to incompatibility
with SP2. It appears that this was the root cause and that by removing RC
from my hard disk, the problem of being unable to schedule a chkdsk at boot
time completely disappeared.

Yes it is clear, but the situation remains that some system/boot start
device is not allowing autochk the required exclusive access to the disks.
This is the cause. Now the other issues you mention are only an immediate
effect or result of this for which I don't have an answer.

Afraid you really have two choices; either remove the device/service or put
up with it and use the RC when necessary.

--
Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

:
| Is the issue resolved? Well, only in part. When I ran chkdsk from the
| recovery console, I noticed that if either that dirty disk bit had been
set
| earlier, or if I had scheduled to perform a chkdsk at boot time, those
| settings still remained in effect after the chkdsk when I subsequently
| rebooted. Now, running chkdsk after Windows comes up completely that
problem
| seems to have vanished so that when I reboot, the system no longer tries
to
| initiate chkdsk repeatedly. The remaining problem is this: should I run
| diskscan from Norton Utilities, or if I should try to run chkdsk and be
told
| I need to schedule it to run at boottime, it simply will not execute -- on
| any of my four disk drives. When I later boot up, it tells me the scan
has
| been scheduled, is supposed to then let a few seconds elapse so that I can
| press a key if I want to abort the operation, and then on the next line
tells
| me that the operation was aborted. If I have scheduled each of the four
| disks to be scanned, it will run through all four of them in succession
and
| do exactly the same thing. There is no time lapse while the dots appear
on
| the screen (. . . .). While this may technically be totally inaccurate,
it
| is as though those extra keystrokes which ultimately abort the scans had
been
| stacked and were then immediately popped off the moment the scheduled scan
| kicked into swing. Of course, I never touch the keyboard. I know that
may
| not be what's going on, however it ACTS like a running program that is
just
| popping off it's input from the stack. My problem with this is that it's
not
| supposed to be that way. If the machine crashes, or power to a disk is
cut
| before finishing any final write operations (thus setting the dirty bit),
| Windows should check the disk for errors at the next boot and my machine
| simply will no longer do that. The good news is that you helped me get to
a
| point where I can run chkdsk manually when I know that it needs to be run,
| but I'd rather rely on the system to do this. It's late and I'm a little
| foggy headed now, but I hope that I have made this clear and not confused
you.