chkdsk doesn't run during boot

  • Thread starter Thread starter Gerhard Fiedler
  • Start date Start date
G

Gerhard Fiedler

Hello,

when I schedule a boot-time disk check with "chkdsk /f <drive>:" and answer
appropriately to the following questions about dismounting and scheduling a
boot time chkdsk, it works for all drives except my system drive (C:).

When I run "chkntfs c:", it tells me "The type of the file system is NTFS.
Chkdsk has been scheduled manually to run on next reboot on volume C:." But
when I reboot, nothing happens. That is, if there is another drive
scheduled to be checked, it does get checked. But never the C: drive. If I
run "chkntfs c:" right after boot, it comes back with the same message,
that a boot-time check is scheduled.

Can somebody please help me out here? How do I get the boot time chkdsk for
my C: drive back?

Thanks,
Gerhard
 
Does it work ok through the Windows interface?

ie

My Computer > Right-click c: > Properties > Tools tab > Check now ..


Jon
 
Does it work ok through the Windows interface?
My Computer > Right-click c: > Properties > Tools tab > Check now ..

No, it's the same thing. Scheduling through the Drive Properties works with
all drives except the C: drive. The C: drive still doesn't get checked
during boot, and running "chkntfs c:" immediately after boot still shows
that the drive is manually scheduled for a check.

Thanks,
Gerhard
 
Gerhard said:
No, it's the same thing. Scheduling through the Drive Properties works with
all drives except the C: drive. The C: drive still doesn't get checked
during boot, and running "chkntfs c:" immediately after boot still shows
that the drive is manually scheduled for a check.

Thanks,
Gerhard

Can you boot to the Recovery Console? If so, run CHKDSK /P and see if
that will work.

Steve
 
I have a similar problem, that checkdsk is always cancelled. Traced it
to my MS wireless keyboard. If I plug in a hardwired keyboard it runs
checkdsk just fine.
 
Scott said:
I have a similar problem, that checkdsk is always cancelled. Traced it
to my MS wireless keyboard. If I plug in a hardwired keyboard it runs
checkdsk just fine.

Yes, I've seen similar situations and I had thought of a keyboard error
or stuck key causing it to cancel at bootup but since the OP stated that
CHKDSK runs fine at bootup on non-system drives when scheduled I ruled
that out.

Steve
 
Scott said:
Can you boot to the Recovery Console? If so, run CHKDSK /P and see if
that will work.

I did that already. That worked (that is, I can run chkdsk on C: from the
recovery console). But it doesn't change the behavior -- after running the
recovery console chkdsk, chkntfs still tells me that a boot time chkdsk is
scheduled, but it still doesn't run at boot time.

Yes, I've seen similar situations and I had thought of a keyboard error
or stuck key causing it to cancel at bootup but since the OP stated that
CHKDSK runs fine at bootup on non-system drives when scheduled I ruled
that out.

No wireless keyboard here, just a standard PS/2 keyboard. Also, the chkdsk
on C: doesn't get canceled, it doesn't even start to run. If the C: drive
is the only one that's scheduled, the start-up text mode window doesn't
appear at all. If another drive is also scheduled, the text mode window
appears, but chkdsk only runs on the other drive. No mention at all of the
C: drive.

Thanks,
Gerhard
 
Gerhard said:
I did that already. That worked (that is, I can run chkdsk on C: from the
recovery console). But it doesn't change the behavior -- after running the
recovery console chkdsk, chkntfs still tells me that a boot time chkdsk is
scheduled, but it still doesn't run at boot time.

Does it say the dirty bit is set?

Steve
 
Just in case you haven't tried it, the /D option on the chkntfs command
looks promising

/D Restores the machine to the default behavior; all drives are
checked at boot time and chkdsk is run on those that are
dirty.

chkntfs /d
at a command prompt


Jon
 
No:

e:\>fsutil dirty query c:
Volume - c: is NOT Dirty

e:\>chkntfs c:
The type of the file system is NTFS.
Chkdsk has been scheduled manually to run on next reboot
on volume C:.

Just in case you haven't tried it, the /D option on the chkntfs command
looks promising

/D Restores the machine to the default behavior; all drives are
checked at boot time and chkdsk is run on those that are
dirty.

I tried this already.

FWIW, the whole story started with me using 'fsutil dirty set c:' to set
the dirty bit on C:. After that, I expected chkdsk to run on C: at the next
boot, without manually scheduling it through chkdsk. It didn't. So I
scheduled it manually through chkdsk, but it still didn't run. After I
booted into the recovery console and ran chkdsk there, the dirty bit was
reset (and stayed reset until now), but the manually scheduled boot time
chkdsk still didn't run. And that's where I am now...

I tried both the /D and /C options of chkntfs, to no avail. They actually
should neither cause nor prevent a manually scheduled boot time check. My
drive is not dirty, so the automatic check when the dirty bit is set (which
is what these options seem to be meant to work on) shouldn't run. And
according to chkntfs, the manual check (which should be independent of the
dirty bit) is scheduled and should run.

Thanks,
Gerhard
 
I think Scott may have made a good suggestion earlier in the thread,
actually. It could well be 3rd party usb device driver related. Try
unplugging all your non-essential USB devices (eg cameras, scanners,
webcams) and use a standard non-USB keyboard / mouse, if possible, and retry
the chkdsk scheduling.

Also try disabling 3rd party services, including your firewall and antivirus
start > run > msconfig > Services > Check "Hide all Microsoft services" >
Disable all
Reboot
Again retry the chkdsk scheduling

Jon
 
I think Scott may have made a good suggestion earlier in the thread,
actually. It could well be 3rd party usb device driver related. Try
unplugging all your non-essential USB devices (eg cameras, scanners,
webcams) and use a standard non-USB keyboard / mouse, if possible, and
retry the chkdsk scheduling.

Also try disabling 3rd party services, including your firewall and
antivirus start > run > msconfig > Services > Check "Hide all Microsoft
services" > Disable all Reboot Again retry the chkdsk scheduling

No success... Unplugged everything, disabled all the non-MS services, even
used the diagnostic startup of msconfig, but chkdsk didn't run, and
everything looks just like before: chkntfs still shows it as being
scheduled...

Thanks,
Gerhard
 
Gerhard said:
No success... Unplugged everything, disabled all the non-MS services, even
used the diagnostic startup of msconfig, but chkdsk didn't run, and
everything looks just like before: chkntfs still shows it as being
scheduled...

Thanks,
Gerhard

Have you looked in Event Viewer, System for any errors that may lend a clue?

Steve
 
Have you looked in Event Viewer, System for any errors that may lend a
clue?

Between the startup of the system and the time e.g. chkdsk on D: gets
logged in the application log (Winlogon, 1001) there are no errors in any
of the three logs.

I have a few error entries from non-essential hardware drivers that fail to
start (but otherwise seem to work fine later when I need them), but they
come quite a bit after the Winlogon entry from the boot time chkdsk.

Gerhard
 
The other major avenue to explore would be the various registry settings
that could cause chkdsk problems.

Obviously Googling, using search terms like "disable chkdsk registry",
should turn up a number of helpful registry settings, that you could compare
with your own.

For example, perhaps run through all the "BootExecute" keys in the
registry

eg at
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Control\Session Manager
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Control\Session Manager

Check that they are ALL set to autocheck autochk *


Another key to look at would be the WinLogon key at

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

I have pasted the current values of my entries (between the asterisks at the
end), so you can compare yours with those (obviously changed the user /
domain names). If you have any discrepancies, you might want to Google for
those.

Also saw that Kelly had a check disk enable / disable on her site (number
82 in this page)
http://www.kellys-korner-xp.com/xp_tweaks.htm

Hope this helps

Jon


************************************************************************************************************
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"AutoRestartShell"=dword:00000001
"DefaultDomainName"="*************"
"DefaultUserName"="*************"
"LegalNoticeCaption"=""
"LegalNoticeText"=""
"PowerdownAfterShutdown"="0"
"ReportBootOk"="1"
"Shell"="Explorer.exe"
"ShutdownWithoutLogon"="0"
"System"=""
"Userinit"="C:\\WINDOWS\\system32\\userinit.exe,"
"VmApplet"="rundll32 shell32,Control_RunDLL \"sysdm.cpl\""
"SfcQuota"=dword:ffffffff
"allocatecdroms"="0"
"allocatedasd"="0"
"allocatefloppies"="0"
"cachedlogonscount"="10"
"forceunlocklogon"=dword:00000000
"passwordexpirywarning"=dword:0000000e
"scremoveoption"="0"
"AllowMultipleTSSessions"=dword:00000001
"UIHost"=hex(2):6c,00,6f,00,67,00,6f,00,6e,00,75,00,69,00,2e,00,65,00,78,00,65,\
00,00,00
"LogonType"=dword:00000001
"DebugServerCommand"="no"
"SFCDisable"=dword:00000000
"WinStationsDisabled"="0"
"HibernationPreviouslyEnabled"=dword:00000001
"ShowLogonOptions"=dword:00000000
"AltDefaultUserName"="*************"
"AltDefaultDomainName"="*************"
"KeepRasConnections"="1"
"DisableCAD"=dword:00000001
"LeakTrack"=dword:00000000
"SfcScan"=dword:00000000
"AutoAdminLogon"="1"
"Background"="0 0 0"

(UIHost appears as "logonui.exe" in registry )
************************************************************************************************************
 
Obviously Googling, using search terms like "disable chkdsk registry",
should turn up a number of helpful registry settings, that you could compare
with your own.

I tried that (google web and google groups), with dubious results... :)

- http://www.dataclinic.co.uk/disable-scandisk-chkdsk.htm claims that by
changing "the BootExecute entry to: 'autocheck autochk *'" I can disable
chkdsk at boot time.

- http://support.microsoft.com/default.aspx?scid=kb;en-us;Q160963 claims
that "Chkdsk /f schedules itself to run at the next reboot by setting the
dirty bit on the drive." In my experience, chkdsk /f schedules a boot time
check by adding the line "autocheck autochk /p \??\C:" to the BootExecute
value in the registry. chkdsk /f does not seem to set the dirty bit:

--------------------------------------------------------
e:\>fsutil dirty query d:
Volume - d: is NOT Dirty

e:\>chkntfs d:
The type of the file system is NTFS.
D: is not dirty.

e:\>chkdsk /f d:
The type of the file system is NTFS.

Chkdsk cannot run because the volume is in use by another
process. Chkdsk may run if this volume is dismounted first.
ALL OPENED HANDLES TO THIS VOLUME WOULD THEN BE INVALID.
Would you like to force a dismount on this volume? (Y/N) n

Chkdsk cannot run because the volume is in use by another
process. Would you like to schedule this volume to be
checked the next time the system restarts? (Y/N) y

This volume will be checked the next time the system restarts.

e:\>fsutil dirty query d:
Volume - d: is NOT Dirty

e:\>chkntfs d:
The type of the file system is NTFS.
Chkdsk has been scheduled manually to run on next reboot
on volume D:.

e:\>
--------------------------------------------------------

Running chkdsk, instead of marking the drive as dirty, creates an
additional line in BootExecute, which on my system is now (after the
above):

autocheck autochk /p \??\D:
autocheck autochk /p \??\C:
autocheck autochk *

(Which results in D: being checked, but not C: ...)

The rest of the hits was either about how the standard settings should be
(which are not any different on my system) or about how to disable the
autocheck, using the BootExecute value or chkntfs.

Nothing that would add anything to what I already checked, with your (and
others') help.

For example, perhaps run through all the "BootExecute" keys in the
registry

eg at
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Control\Session Manager
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet003\Control\Session Manager

Check that they are ALL set to autocheck autochk *

Because I already tried to schedule a manual boot time check, all these
keys are set to:

autocheck autochk /p \??\C:
autocheck autochk *

(Or were, before I ran the sequence above that scheduled the D: drive.)

I already tried to delete the first line and set it back to the default
value. The result is that chkdsk does not run on boot (because the drive is
not dirty). When I run chkdsk /f after the boot, it adds that first line
(as expected), but it still doesn't run on boot.

Another key to look at would be the WinLogon key at

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

I have pasted the current values of my entries

Thanks a lot, that was new to me. Nothing odd there, except...
Also saw that Kelly had a check disk enable / disable on her site
(number 82 in this page) http://www.kellys-korner-xp.com/xp_tweaks.htm

She says that SfcScan in Winlogon should be 1; it's 0 in your system, it's
been missing in mine, but adding it didn't change anything.


I found a mention of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Diagnostics\RunDiagnosticLoggingGlobal, which I set to 1
during the last boot. But no additional error messages showed up in the
event log. Only the one normal Winlogon event with the results of checking
the D: drive.

**********************************************************************
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\Winlogon] "AllowMultipleTSSessions"=dword:00000001
is 0, can't see a problem with this
"LogonType"=dword:00000001
is 0, shouldn't be a problem
"ShowLogonOptions"=dword:00000000
is 1, shouldn't be a problem

The following are missing, but I can't see how they would change the chkdsk
behavior.
"KeepRasConnections"="1"
"DisableCAD"=dword:00000001
"LeakTrack"=dword:00000000
"SfcScan"=dword:00000000
adding this with a data of 1 didn't change anything
"AutoAdminLogon"="1"
"Background"="0 0 0"
**********************************************************************

Thanks... I'm pretty much lost with this. If only it were possible to get
some diagnostic output from autocheck or autochk... Can I run these
manually from the recovery console? I haven't found anything about
additional diagnostic output from these tools.

Gerhard
 
One thought is to try running chkdsk without any fixing parameters, from
within Windows, and have a look at any error messages produced in the
output. Might be some clues there.

ie

chkdsk c: >chkdskoutputfile.txt

or

chkdsk /v c: >chkdskoutputfile.txt

Then examine the text file produced.

Jon



news:[email protected]...
 
One thought is to try running chkdsk without any fixing parameters, from
within Windows, and have a look at any error messages produced in the
output. Might be some clues there.

Unluckily not (I think -- see below). I also ran "chkdsk c: /p" from the
recovery console. This didn't change anything besides clearing the dirty
bit that I had set previously (using "fsutil dirty set c:").

Thanks,
Gerhard

------------------------------------
e:\>chkdsk /v c:
The type of the file system is NTFS.
Volume label is WinXP.

WARNING! F parameter not specified.
Running CHKDSK in read-only mode.

CHKDSK is verifying files (stage 1 of 3)...
File verification completed.
CHKDSK is verifying indexes (stage 2 of 3)...
Index verification completed.
Detected minor inconsistencies on the drive. This is not a corruption.
CHKDSK is verifying security descriptors (stage 3 of 3)...
Cleaning up 20 unused index entries from index $SII of file 9.
Cleaning up 20 unused index entries from index $SDH of file 9.
Cleaning up 20 unused security descriptors.
Security descriptor verification completed.
CHKDSK is verifying Usn Journal...
Usn Journal verification completed.

8193149 KB total disk space.
7483148 KB in 26196 files.
9324 KB in 2800 indexes.
0 KB in bad sectors.
78973 KB in use by the system.
32784 KB occupied by the log file.
621704 KB available on disk.

4096 bytes in each allocation unit.
2048287 total allocation units on disk.
155426 allocation units available on disk.
------------------------------------
 
Very strange

- disk looking fine,
- no obvious registry problems
- seem to have eliminated the early problematic early
system driver option
by your clean booting
- unplugged any potentially problematic hardware devices
- autochk and chkdsk working fine for other drives

Nope, think I'm going to have to admit this one has me beaten.

Only other thought, is perhaps to consider whether there is anything
particularly distinctive about this particular drive c:, as compared to the
others eg separate disk or separate partition, different file format or
whether anything unusual has been done previously, like switching drive
letters etc. But you said it was working fine before issuing the fsutil
command, so that's probably unlikely to be relevant.

I suppose if you have no other obvious problems, you can get by with the
recovery console chkdsk, but might be time to do a full backup, just in
case.

If you do ever discover the cause, though, would be interested to know.

Best wishes

Jon
 
Very strange

- disk looking fine,
- no obvious registry problems
- seem to have eliminated the early problematic early
system driver option by your clean booting
- unplugged any potentially problematic hardware devices
- autochk and chkdsk working fine for other drives

Nope, think I'm going to have to admit this one has me beaten.

Me too :)
Only other thought, is perhaps to consider whether there is anything
particularly distinctive about this particular drive c:, as compared to
the others eg separate disk or separate partition, different file format
or whether anything unusual has been done previously, like switching
drive letters etc.

This is a Dell notebook with four NTFS partitions (C, D, E, F) on its main
drive. C is a primary partition (the boot partition); D, E and F are
logical partitions in an extended partition. This has been that way for
ages.

So I guess the one distinctive thing is that it's the one primary
partition. But other than issuing the fsutil dirty set command on it, there
hasn't been anything different that I did to the drive. I'm pretty sure
it's related to the fsutil, even though I don't understand how. According
to what I read, it should have the contrary effect (and force a boot time
check rather than prevent it...).
But you said it was working fine before issuing the fsutil command, so
that's probably unlikely to be relevant.

Yup...

One thing... I had that before. I tried the fsutil dirty set thing before,
the chkdsk stopped working, but soon thereafter started working again. I
couldn't figure out what caused it at that time, not why it stopped
working, not why it started working again. And it seems I can't either this
time around, just that I'm less lucky now :)

Talk about determinism in computers...
I suppose if you have no other obvious problems, you can get by with the
recovery console chkdsk, but might be time to do a full backup, just in
case.

Yes, I do that anyway. But there doesn't seem to be anything wrong with
this partition, other than the fact that chkdsk doesn't run on boot.
If you do ever discover the cause, though, would be interested to know.

I'll let you know... unless I get lucky again without knowing why. And I
promise I won't touch the fsutil dirty set command again anytime soon :)

No need to either, now that I learned about that BootExecute thing. The
whole exercise was about finding a way to force a boot time chkdsk
programmatically. Setting the dirty bit with fsutil seemed to be the
obvious way, from what I had read. /Seemed/ to be... :)

Thanks,
Gerhard
 
Back
Top