On 3 Dec 2004 15:15:55 -0800, (e-mail address removed) (Scott Lansbury)
I've seen this about 10 times in the past with CHKDSK and it still
plagues me.
"ChkDsk" and "plague" do have an affinity, yes
chkdsk
some errors found use /f
chkdsk /f
sorry disk can't be locked on next re-boot (Sure I understand that)
reboot, chkdsk runs "fixes" errors, back to windows
chkdsk
some errors found use /f
chkdsk /f
sorry disk can't be locked on next
repeat indefinately.
OK. Suggests one of:
1) Physical HD defects
2) Other hware defects that corrupt file system writes
3) Bad shutdowns that damage the file system
4) Malware is deliberately damaging the file system
The only way I've solved this before is to find the files chkdsk had a
problem with, physically delete them, run it again, defrag and then
run it again - then the disk comes up fine.
That fits (1) in particular - as that would have the stasis this
implies. Other issues would generate new errors, but the
previously-generated errors would have been fixed OK
The above is "fuzzy", i.e. don't weight it hi-confidence.
and no the disk is in perfect condition, no bad sectors
Well, that's always hard to be sure of, because so much will conspire
to hide bad sectors from you - the HD's on-the-fly defect management
that may only show up in the unquoted details of SMART, plus the OS
which does the same thing on NT volumes.
You may also find that ChkDsk doesn't report details of what it does,
except in the depths of Event Viewer logs.
file system screw up which chkdsk is not repairing properly.
Is there a good cheap alternative?
An alternate ChkDsk won't make bad hardware go away.
1) Physical HD defects
Use the HD vendor's tools to test, and check that with something like
AIDA32 that gives some SMART detail (beyond the usual "you are not
actually dead yet; how sick you actually are is none of your
business") that vendor tools or BIOS/CMOS are likely to cough up.
And of course, if ChkDsk says "I found bad sectors, but fixed them
all!" then you should be very, very afraid - not reassured!
If file system is FATxx rather than NTFS, then I find it useful to do
a DOS mode boot and run the Win9x Scandisk surface scan (assuming the
Win9x version is OK with your HD's capacity and file system). Unlike
ChkDsk or Scandisk in Windows GUI, no other programs are running at
the same time - so whenever the fine-grained cluster counter pauses,
you know you are hitting retries and thus sick disk. Even if Scandisk
and/or HD firmware doesn't think it's a problem yet, you can see.
2) Other hware defects that corrupt file system writes
Suspect this if the PC is generally flaky, tho some mobo chipset
issues may specifically bite HD transfers only. Let's say you have
defective RAM, or corruption on a bus, that kinks what is written to
the disk's file system structural info, so that this info is
corrupted. If you were to do an elective ChkDsk, it would report
errors, and if attepts to access an affected file failed, you'd get
that balloon prompt to run ChkDsk.
3) Bad shutdowns that damage the file system
Obviously, if you don't shutdown properly (or the PC crashes) then you
can expect file system operations to be interrupted, a flag to be left
set accordingly, and the next startup would run AutoChk (similar to
ChkDsk). If you disabled AutoChk, the presentation would be
different; instead of AutoChk at startup, you'd get those balloons
when damaged files were accessed by the system.
What is less obvious, is if the system *thinks* it is shutting down
OK, but in fact is not. The classic example is when the ATX turns off
power after data is written to the HD, but before the HD has written
the material from its own cache RAM to the disk platters.
This usually presents as above, because the "all file ops finished OK"
flag is one of the things that didn't make it to the disk platters.
4) Malware is deliberately damaging the file system
In theory, this is impossible because the OS and NTFS are supposed to
prevent the sort of direct raw disk writes that would do this. But
the pudding was proved by Witty, which drilled into Black Ice Defender
and used the driver-level hardware access writes from there, to trash
the system just as easily as an old disk-biting virus from DOS days.
Suspect this if you have an old version of Black Ice Defender
Other malware may do what Witty has proved possible to do, though
right now I can't recall reading of any.
Personally, I'd suspect (2), (1) or less likely (3). Item (3) would
present differently (i.e. only AutoChk on startup, no "this file is
damaged" bubble pop-ups) unless you'd suppressed AutoChk.
If you haven't suppressed AutoChk, and you never see it running, then
it really is most likely (2) or in spite of your assurances, (1).
Those are the only things I can think of that would repeatedly
generate "bad file, run ChkDsk /F" pop-ups.
