KenK said:
I've had a persistant chkdsk error on C for many years. I fix it with
chkdsk and it's back again next check. Otherwise the drive works just fine.
I was in Staples to buy a printer toner cart and asked their repair guy
about the drive problem while I was there and he was ringing up the cart.
He said to DL Malwarebytes.
Before I do this on my very slow dial-up connection do you think it's worth
the trouble? I run Kasperski update and critical area scan every day and a
full scan every few weeks. Never finds anthing.
TIA
There are a couple ways, to signal that a CHKDSK run is required.
1) Open Command Prompt. Check the "dirty bit" on C:. Each partition
has a flag, which can be set by a user (or program), but not cleared.
But CHKDSK can clear the bit, once the partition has a clean bill of
health.
fsutil dirty query C:
http://www.microsoft.com/resources/...all/proddocs/en-us/fsutil_dirty.mspx?mfr=true
An example of usage might be, you boot Linux, Linux makes some
changes to the partition, but seeks to get the "blessing" of
Windows, the next time Windows boots and goes to use the partition.
Linux can assert (set) the dirty bit, as a means of communicating
that CHKDSK should be run. Typically this would happen, if say the
NTFS journal wasn't valid. And asserting "dirty", is a "better safe
than sorry" approach.
2) Windows can also store scheduled CHKDSK operations in a registry
key. Typically, a user might request CHKDSK C:, but since the system
has C: mounted, you can't run the CHKDSK right away.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager
BootExecute REG_MULTI_SZ autocheck autochk *
BootExecute is just a place to store a command to be executed
early on, in the boot process. In this case, it is executed
before C: is mounted. So C: is not busy at this point.
The autocheck determines whether any dirty bits are set,
and calls the appropriate CHKDSK utility (i.e. CHKNTFS) to finish
the job. Most of the time, there is no work to do, and this step
finishes in a flash.
And this would be the registry key value, if a CHKDSK had been
scheduled by the user. This registry key would be reset to
the default value, after CHKDSK was finished. The BootExecute key
can also have multiple lines of text in it, such as when a third
party utility wishes to start before any other programs have a
chance to start.
autocheck autochk /r \??\C:
*******
Hard drives have automatic defect management. In the case of IDE/SATA
drives, the defect management is not reversible (like it can be on
SCSI drives).
The drive has spare sectors. It replaces bad sectors with spares. The
disk continues to return read data for each sector (whether a spare
or a regular sector). It's only when the drive runs out of spares in
a particular area of the disk, that eventually the disk throws a "CRC
error". At that point, the Windows file system is involved, and
an entire cluster can be marked as $BADCLUS. That should prevent the
cluster from being used for storage later. Usually the computer is
in pretty sad shape, by the time things have sunk that low. The
hard drive is likely very slow, and the user already has an inkling
that drive death is imminent.
Reformatting a drive, would remove any memories of bad clusters,
but they would be rediscovered again by the file system (eventually).
Whereas the hardware level defect management, is not supposed
to be reset (unless the drive is returned to the factory
and the appropriate utility used to clear all the spared
sectors).
I've reset the defect management system on SCSI drives in the past,
and pretty soon, it detects the defects again and spares them out.
In some cases, it's possible for an IDE drive to mistakenly mark
a lot of sectors as bad, when they aren't, but I'm not aware
of any way with those drives, to "fix" them. There is no longer
a low level format capability, so you can't expect to do it
that way. Modern drives are low level formatted once at the factory,
and that is "good for life". Every other operation done to
an IDE drive, is a "sector write". So at the best of times,
an attempt to format a modern IDE drive, just does writes
to all the sectors. No structures on the disk are changed by that
(no servo wedges re-written, no data structures reset). I don't
even think an Enhanced Secure Erase (one of the IDE commands),
affects stuff like that. It's still just "sector write" at heart.
*******
Start by checking the two items above. It's probably
not going to fix anything, but it'll tell you what's
been set, either on the drive, or in the Registry.
You would need to run Regedit, to inspect that
registry entry.
Paul
