chkdsk.exe returns different errors depending on user who runs it

  • Thread starter Thread starter Florian
  • Start date Start date
F

Florian

I am experiencing interesting behaviour with chkdsk.exe on a Windows 2000
Professional machine (SP4, all patches). This machine has a few NTFS
partitions, all on a RAID5 Adaptec SCSI (shouldn't matter but I thought I'd
mention it anyway).

I'm running a plain chkdsk.exe on a drive as the local Administrator, and
the file system is clean. That is chkdsk.exe does not display an error
messages.

Then, I'm running the EXACT same command under the "Task Manager" with a
scheduled task. Hence, the command is executed under the LOCALSYSTEM
account. Interestingly enough, the chkdsk.exe run shows errors this time,
such as:

CHKDSK discovered free space marked as allocated in the master file table
(MFT) bitmap.
CHKDSK discovered free space marked as allocated in the volume bitmap.

Windows found problems with the file system.

So, depending on whether I run chkdsk.exe under the Administrator or
LOCALSYSTEM account, I get different results.

Note that these results are persistent - that is running chkdsk.exe under
the Administrator account will NEVER show any errors, while running under
the LOCALSYSTEM account will ALWAYS show up errors (I have not tried running
"chkdsk.exe /F" under the LOCALSYSTEM account yet).

I'm not too worried about potential problems in the file system here, just
curious why this tool is not consistent. I was fairly certain that the
integrity of the file system was not dependent on the permissions of the
user account.

I understand that this is probably quite theoretical, but I have also seen
that chkdsk.exe always returns errors in the Volume Bitmap under Windows XP,
no matter how often one runs chkdsk.exe /f - so I'm starting to wonder how
useful chkdsk.exe is - or how useful NTFS is :-)


Thanks,
Florian.
 
Florian said:
I am experiencing interesting behaviour with chkdsk.exe on a Windows 2000
Professional machine (SP4, all patches). This machine has a few NTFS
partitions, all on a RAID5 Adaptec SCSI (shouldn't matter but I thought I'd
mention it anyway).

I'm running a plain chkdsk.exe on a drive as the local Administrator, and
the file system is clean. That is chkdsk.exe does not display an error
messages.

Then, I'm running the EXACT same command under the "Task Manager" with a
scheduled task. Hence, the command is executed under the LOCALSYSTEM
account. Interestingly enough, the chkdsk.exe run shows errors this time,
such as:

CHKDSK discovered free space marked as allocated in the master file table
(MFT) bitmap.
CHKDSK discovered free space marked as allocated in the volume bitmap.

Windows found problems with the file system.

So, depending on whether I run chkdsk.exe under the Administrator or
LOCALSYSTEM account, I get different results.

Note that these results are persistent - that is running chkdsk.exe under
the Administrator account will NEVER show any errors, while running under
the LOCALSYSTEM account will ALWAYS show up errors (I have not tried running
"chkdsk.exe /F" under the LOCALSYSTEM account yet).
Click to expand...

Chkdsk without the /f is useless, no matter who runs it. There's just no
way (short of suspending every task in the system, to be sure that someone
else isn't changing the FS and causing the errors. That's why the /f forces
a dismount or reboot.
I'm not too worried about potential problems in the file system here, just
curious why this tool is not consistent. I was fairly certain that the
integrity of the file system was not dependent on the permissions of the
user account.

I understand that this is probably quite theoretical, but I have also seen
that chkdsk.exe always returns errors in the Volume Bitmap under Windows XP,
no matter how often one runs chkdsk.exe /f - so I'm starting to wonder how
useful chkdsk.exe is - or how useful NTFS is :-)
Click to expand...

Since Win2K SP2, chkdsk has been indicating some benign states as not so
benign. It got much quieter in XP SP1, or maybe some hotfix between XP RTM
and now. The Google groups archive has lots of messages about that from
sometime in the last year and a half. I participated in those threads, so
if you look for my name, it should help you find that information.

Phil
--
Philip D. Barila Windows DDK MVP
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.
E-mail address is pointed at a domain squatter. Use reply-to instead.
 
Thanks for your reply. I have found the official chkdsk reference for
Windows Server 2003 in the meantime and realized that chkdsk.exe cannot be
trusted if processes are accessing the file system when it runs, only a
chkdsk /f is reliable.

I was just under the impression that the OS should know whether the FS is OK
or not - even when processes are accessing the file system. But then again,
I know too little about FS to really make a case here :-)

Thanks!
 
Florian said:
Thanks for your reply. I have found the official chkdsk reference for
Windows Server 2003 in the meantime and realized that chkdsk.exe cannot be
trusted if processes are accessing the file system when it runs, only a
chkdsk /f is reliable.

I was just under the impression that the OS should know whether the FS is OK
or not - even when processes are accessing the file system. But then again,
I know too little about FS to really make a case here :-)
Click to expand...

The short answer for why it can't is that chkdsk can't take a complete
snapshot of the entire FS in a short enough time to guarantee that it's a
fully consistent state. If there's the possibility that any other process
is doing something to the FS, the FS state can change between when chkdsk
starts and when it's done. So the net effect is that even though the FS is
always consistent, chkdsk sees some apparent inconsistencies due to the FS
changing while chkdsk is working.

The long answer is just like that, only more words! :-)

Phil
--
Philip D. Barila Windows DDK MVP
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.
E-mail address is pointed at a domain squatter. Use reply-to instead.
 
Interesting. I'm replying with reading the other replies here, but I just posted a Chkdsk problem and found this while waiting

Haven't tried it (Chkdsk) under local admin, but account used in admin group

While poking around I had another hunch. Something to do with the Recycle bin settings. Changing this (one setting for all drives, and back), all worked for my normal login account. When logged in ad local admin, I guess had files left in the bin, as it said "Recycle bin invalid", do you want to empty and reconfigure? Said yes, but when I did I started seeing errors like this

Windows will now check the disk.
Cleaning up minor inconsistencies on the drive
Cleaning up 1 unused index entries from index $SII of file 0x9
Cleaning up 1 unused index entries from index $SDH of file 0x9
Cleaning up 1 unused security descriptors

And regular (it always finds 1 to 5 of these). Other hunch was Frequent Defrag releated)

Do you defrag often (or when it says you don't have enough free space)
Have you changed Recycle Bin settings recently
 
Back
Top