CHKDSK Always Reporting Errors - Bug?

  • Thread starter Thread starter Dave Onex
  • Start date Start date
D

Dave Onex

Hi Folks;

I'm running MCE 2005 - fully patched and a clean install on a fresh RAID 0
array.

Every time I run chkdsk errors will be found. Both drives have been checked
with Seatools - there's nothing wrong with them. I suspect it's actually an
issue with Windows XP.

For instance, if I run a chkdsk it will find something like this every time.

A disk check has been scheduled.
Windows will now check the disk.
Cleaning up minor inconsistencies on the drive.
Cleaning up 13 unused index entries from index $SII of file 0x9.
Cleaning up 13 unused index entries from index $SDH of file 0x9.
Cleaning up 13 unused security descriptors.
CHKDSK is verifying Usn Journal...
Usn Journal verification completed.

976760000 KB total disk space.
165186680 KB in 54578 files.
18352 KB in 5010 indexes.
0 KB in bad sectors.
252932 KB in use by the system.
65536 KB occupied by the log file.
811302036 KB available on disk.

If I immediately re-start the O/S and do another chkdsk it will also find
unused index entries. I can run chkdsk back to back all day long and it will
always find unused index entries.

Does anyone know what would cause chkdsk to report this even though there
are no actual issues with the disks themselves?
 
Dave Onex said:
Hi Folks;

I'm running MCE 2005 - fully patched and a clean install on a fresh RAID 0
array.

Every time I run chkdsk errors will be found. Both drives have been
checked with Seatools - there's nothing wrong with them. I suspect it's
actually an issue with Windows XP.

For instance, if I run a chkdsk it will find something like this every
time.

A disk check has been scheduled.
Windows will now check the disk.
Cleaning up minor inconsistencies on the drive.
Cleaning up 13 unused index entries from index $SII of file 0x9.
Cleaning up 13 unused index entries from index $SDH of file 0x9.
Cleaning up 13 unused security descriptors.
CHKDSK is verifying Usn Journal...
Usn Journal verification completed.

976760000 KB total disk space.
165186680 KB in 54578 files.
18352 KB in 5010 indexes.
0 KB in bad sectors.
252932 KB in use by the system.
65536 KB occupied by the log file.
811302036 KB available on disk.

If I immediately re-start the O/S and do another chkdsk it will also find
unused index entries. I can run chkdsk back to back all day long and it
will always find unused index entries.

Does anyone know what would cause chkdsk to report this even though there
are no actual issues with the disks themselves?
Click to expand...

There appears to be a misunderstanding here. Seatools checks the *physical*
properties of your disk. It knows nothing about its logical structure.
Chkdsk, on the other hand, checks the *logical* structure, i.e. if there are
inconsistencies with your file system such as lost or crosslinked clusters,
unused index entries etc. Seatools has no way of knowing about these things.
It doesn't even care if there is a file system on your disk or not.

The errors you report are, as it says, minor inconsistencies. There is no
need to worry about them. Let them go - the NTFS file system is quite robust
and can look after itself.

Before someone calls me a liar I need to add that the /R switch, when used
with chkdsk, will perform a physical examination of the disk.
 
Hi Folks;

I'm running MCE 2005 - fully patched and a clean install on a fresh RAID 0
array.

Every time I run chkdsk errors will be found. Both drives have been checked
with Seatools - there's nothing wrong with them. I suspect it's actually an
issue with Windows XP.

For instance, if I run a chkdsk it will find something like this every time.

A disk check has been scheduled.
Windows will now check the disk.
Cleaning up minor inconsistencies on the drive.
Cleaning up 13 unused index entries from index $SII of file 0x9.
Cleaning up 13 unused index entries from index $SDH of file 0x9.
Cleaning up 13 unused security descriptors.
CHKDSK is verifying Usn Journal...
Usn Journal verification completed.

976760000 KB total disk space.
165186680 KB in 54578 files.
18352 KB in 5010 indexes.
0 KB in bad sectors.
252932 KB in use by the system.
65536 KB occupied by the log file.
811302036 KB available on disk.

If I immediately re-start the O/S and do another chkdsk it will also find
unused index entries. I can run chkdsk back to back all day long and it will
always find unused index entries.

Does anyone know what would cause chkdsk to report this even though there
are no actual issues with the disks themselves?
Click to expand...

I don't recall and am too lazy to look it up and can't try it here,
but I seem to recall that CHKDSK doesn't work well or at all in a RAID
configuration. The manufacturer of the RAID environment should have
something equauvalent or probably better.

There might be a bug in CHKDSK, but I think if there was, people would
be screaming all over the place.

Maybe someone will know for sure and just say that you can't rely or
run CHKDSK in a RAID configuration.

(moments later)

Well, I looked anyway and it appears the popular answer is CHKDSK is
not RAID aware and will certainly not be able to repair any problems
even if it reports any (which it probably will since it doesn't
understand RAID). Then other people argue that it might run clean,
but still won't fix anything, other people just say DON'T do it,
especially trying to let CHKDSK fix anything (certainly not /R)! I
believe that.

I think I would check with Seagate or someone you trust, like Google,
and see what tool they recommend for checking and/or fixing potential
HD issues in your RAID environment that do not involve CHKDSK, then
you will know for sure. No guessing.

I know about Dell, Compaq and IBMs pretty much. Never ran a CHKDSK
yet...
 
Hi everyone;

Thanks for the replies!

I agree that it's probably not an issue per se however I'd sure like to see
it report back zero errors. In all my years the only time I've ever seen
chkdsk report errors was when a computer was not shut down properly or there
was some form of drive failure etc. Generally speaking, they always come out
100% - unless there's a reason for them not to.

I have seen that KB article but the XP section states that the issue was
fixed with the latest service pack. I'm on SP#3 with all other updates so I
would think that issue was addressed? It does sound right though.

With respect to checkdisk and arrays - I have several RAID 5 SCSI arrays
here and it works like a top on all of them. I think Windows just sees
logical drives as just that - a logical drive. The one I'm having issues
with is a workstation-based SATA array. The reason I mentioned SeaTools was
to let everyone know that the physical drives themselves are OK.

The KB article sounds right but apparently the issue was fixed! ;-0
 
Dave

From the KB Article

"Even when this hotfix is installed, it is still possible for Chkdsk to
reset permissions back to default settings. You can use the Vrfydsk.exe
utility to determine whether real Security Descriptor file corruption occurs
on a volume."


--


Hope this helps.

Gerry
~~~~
FCA
Stourport, England
Enquire, plan and execute
~~~~~~~~~~~~~~~~~~~
 
Isn't that for Windows Server 2003?

Gerry said:
Dave

From the KB Article

"Even when this hotfix is installed, it is still possible for Chkdsk to
reset permissions back to default settings. You can use the Vrfydsk.exe
utility to determine whether real Security Descriptor file corruption
occurs on a volume."


--


Hope this helps.

Gerry
~~~~
FCA
Stourport, England
Enquire, plan and execute
~~~~~~~~~~~~~~~~~~~
Click to expand...
 
Dave

Yes studying it further I think you are correct.

Another quote "This problem occurs because the Chkdsk utility may not find
references to all the security IDs if the master file table is larger than 4
gigabytes (GB) or if there are more than 4,194,303 files on the volume.
Therefore, the undiscovered security descriptors are reset."

Logically if the number of security IDs is reduced then the problem could
go away. Have you tried reducing the number either by using Disk CleanUp /
cCleaner or moving files to another partition? Remember each partition /
volume has it's own separate MFT.

One feature of the MFT as I understand it is that the only way to reduce the
size of the file is to reformat the volume. I do not know whether this has
any implications for the suugestion above.

--


Hope this helps.

Gerry
~~~~
FCA
Stourport, England
Enquire, plan and execute
~~~~~~~~~~~~~~~~~~~
 
Hi Gerry;

Good points - let's track 'em down...
Another quote "This problem occurs because the Chkdsk utility may not find
references to all the security IDs if the master file table is larger than
4 gigabytes (GB)
Click to expand...

At present my master file table is 60 megs in size and contains only 60,248
records.
So it certainly falls well under the 4 gig limit.
or if there are more than 4,194,303 files on the volume.
Click to expand...

I just ran dir *.* /s and it reports 45,343 files (45k)
Interestingly enough, disk defragmenter reports there are 54,091 (54k) total
files - somewhat of a discrepency
but the point is, it's much, much less then the 4.1 million. mentioned
above.
Have you tried reducing the number either by using Disk CleanUp / cCleaner
or moving files to another partition?
Click to expand...

I have run the disk cleanup utility and it did delete a bunch of old crap.
The system
is actually very new - it's only been running for a couple of weeks now.
It's squeeky clean.
Remember each partition / volume has it's own separate MFT.
Click to expand...

Good point, the only other partition however is the small boot partition (8
megs or so in size)
Hope this helps.
Click to expand...

I certainly think it did if only to eliminate the KB article as a possible
cause.
Certainly it seems to describe my situation to a T but I think we've removed
it
as a possible contributor.

I don't know what else to do. If you run CHKDSK on your system's root drive
does it find index issues?
Also, if you run it again immediately after start-up (after running a
CHKDSK) and then run it again (shut down re-start etc)
do you see the same? Maybe I'm chasing something that's become 'normal' ;-)

Best & Thanks;
Dave
 
Back
Top