Sign in with
Sign up | Sign in
Your question

CHKDSK simply doesn't work AGAIN

Last response: in Windows XP
Share
Anonymous
December 3, 2004 6:15:55 PM

Archived from groups: microsoft.public.windowsxp.perform_maintain (More info?)

I've seen this about 10 times in the past with CHKDSK and it still
plagues me.


CHKDSK as per usual fails me :( 

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.

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.

and no the disk is in perfect condition, no bad sectors - it's just a
file system screw up which chkdsk is not repairing properly.

Is there a good cheap alternative?

More about : chkdsk simply work

Anonymous
December 3, 2004 7:34:00 PM

Archived from groups: microsoft.public.windowsxp.perform_maintain (More info?)

If you get an error something to the effect "cannot open volume for direct
access" There is some system/boot start device that is reading/writing to
the drive before chkdsk can get a lock on the drive. Some anti-virus
applications do this.

You can also run
chkdsk /r
from the recovery console command line. (/r implies /f and /p)

To start the Recovery Console, start the computer from the Windows XP CD-Rom
Press ENTER at the "Setup Notification" screen. Press R to repair a Windows
XP installation, and then press C to use the Recovery Console. The Recovery
Console then prompts you for the administrator password. If you do not have
the correct password, Recovery Console does not allow access to the
computer. If an incorrect password is entered three times, the Recovery
Console quits and restarts the computer. Note: If the registry is corrupted
or missing or no valid installations are found, the Recovery Console starts
in the root of the startup volume without requiring a password. You cannot
access any folders, but you can carry out commands such as chkdsk, fixboot,
and fixmbr for limited disk repairs. Once the password has been validated,
you have full access to the Recovery Console, but limited access to the hard
disk. You can only access the following folders on your computer: drive
root, %systemroot% or %windir%


--
Regards,

Dave Patrick ....Please no email replies - reply in newsgroup.
Microsoft Certified Professional
Microsoft MVP [Windows]
http://www.microsoft.com/protect

"Scott Lansbury" wrote:
| I've seen this about 10 times in the past with CHKDSK and it still
| plagues me.
|
|
| CHKDSK as per usual fails me :( 
|
| 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.
|
| 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.
|
| and no the disk is in perfect condition, no bad sectors - it's just a
| file system screw up which chkdsk is not repairing properly.
|
| Is there a good cheap alternative?
Anonymous
December 5, 2004 1:28:06 AM

Archived from groups: microsoft.public.windowsxp.perform_maintain (More info?)

On 3 Dec 2004 15:15:55 -0800, scottylans@gmail.com (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.



>--------------- ---- --- -- - - - -
I'm baaaack!
>--------------- ---- --- -- - - - -
!