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" <(E-Mail Removed)> wrote in message
news:H0N%b.11883$(E-Mail Removed)...
> 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).

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 :-)

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!

"Phil Barila" <(E-Mail Removed)> wrote in message
news:sZydnePmXe5N89_dRVn-(E-Mail Removed)...
> "Florian" <(E-Mail Removed)> wrote in message
> news:H0N%b.11883$(E-Mail Removed)...
> > 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).
>
> 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 :-)
>
> 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.
>
>

"Florian" <(E-Mail Removed)> wrote in message
news:FvG0c.13813$(E-Mail Removed)...
> 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 :-)

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.

Windows Server 2003 resource kit has a wonderful tool call "VRFYDSK". This
will create a shadow copy of the volume and run CHKDSK on that shadow copy.
Unfortunately this is not available for W2K.

The resource kit is available for download at:
http://www.microsoft.com/downloads/d...displaylang=en

--
Thanks,
Vishal Ghotge [MSFT]
--
This posting is provided "AS IS" with no warranties, and confers no rights

"Phil Barila" <(E-Mail Removed)> wrote in message
news:Ho2dnephaP653dndRVn-(E-Mail Removed)...
> "Florian" <(E-Mail Removed)> wrote in message
> news:FvG0c.13813$(E-Mail Removed)...
>> 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 :-)
>
> 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