John B. Smith wrote:
Today my XP went off the tracks. I think it booted normally but when I
used Agent and Eudora to get hearders and check mail at the same time,
something got messed up bigtime. Agent seemed to freeze, but did work
after a while. Tried a reboot, things got stalled when my bat was
saving email. I finally pushed the Start Button to turn off. On reboot
things were REALLY messed up and Avast anti-virus refused to work. My
last Macrium backup was August 28, but it would have to do. And it
did, though I worked thru it painfully slow as I haden't done it in a
long time. Imaged the backup back on in 20 minutes. Took a long bootup
but everything looked normal. Messed a while with my saved email
rescuing stuff. I do have a bat but I don't trust it. Core Temp
reported 6% usage on both cores all the time???. Anyway, I thought I
better do a fresh Macrium backup. Got it started and saw the estimated
end time was 5 hours! HD Tune then said my 500G drive was running xfer
speedof 3 megabytes/sec! The 1 gig drive was its usual 170MB/sec.
Rebooted and all was ok.
Finally my question is why was the 500g boot drive running so slow on
its first boot after the recovery? Is that typical?
Is your 500GB drive on IDE (ribbon cable) ?
The IDE drives went up to 750GB. That's the largest
disk they made for IDE. My collection of disks, my
largest IDE drive is 250GB.
I picked IDE because it has the same sort of domain
validation as SCSI drives use. A SCSI drive can "gear down"
if errors are detected. This is intended to improve data
transfer error rate, at the expense of transfer speed.
It's a "safety feature" for unattended operation in a server room.
The driver does the magic, and not the disk itself.
Microsoft decided it would be fun to do that for IDE too.
The IDE one gears down, again and again, until it is in a slow PIO mode.
I've not heard of any attempt to do that for SATA.
*******
The "Workaround" section, half way down this page, recommended
uninstalling the boot drive in Device Manager.
https://support.microsoft.com/en-ca/...-out-or-crc-er
devmgmt.msc
Expand the IDE ATA/ATAPI Controllers node.
Double-click the controller for which you want
to restore the typical DMA transfer mode.
Click the Driver tab.
Click Uninstall.
When the process completes, restart your computer. When
Windows restarts, the hard disk controller is re-enumerated and
the transfer mode is reset to the default value for each device
that is connected to the controller.
*******
I can't imagine how Agent and Eudora got into one anothers road.
Maybe in fact, with both running, Avast had to scan the files
both of those were opening and Avast was a little busy too ?
*******
You should check the SMART statistics for the drive,
and see if the Reallocation thing has gone non-zero.
In this example, Reallocated has 9 errors. The tool used
here, is free for download.
http://atm.cyberec.com/~hello/pictures/Clipboard01.jpg
http://www.hdtune.com/files/hdtune_255.exe
If you do the math, and use the predicted percentage,
that field goes up to around 5000 errors or so. And
we have no way of knowing, how that relates to real allocations.
That statistic is "thresholded". When the disk is new, the
manufacturer doesn't want you to know how many errors are
present from the factory. There are actually *always*
allocation errors from the factory. The hard drive has
an acceptance criterion, and the number of errors might
be 100000 for acceptance. When you see 5000 in that SMART
display, the total number of reallocated sectors might be
105,000. But because this is not documented, you're on
your own in terms of interpretation. The people who
invented the SMART interface, don't go into the details
of running a disk business, and they aren't about to
explain "thresholding" to the public :-)
My theory:
0 ..100000 Show 0 in SMART Display
100001..105000 Show 1..5000 in SMART Display
Like "9" in the example picture above.
The thresholding prevents the user from seeing the
errors when the drive is new. This prevents "cherry picking"
by returning drives at retail, until a "low number" drive
is spotted and kept. By having the field be zero when
the drive is new, nobody suspects a thing...
The behavior of my Seagate drives is pretty strange. I
got a growing defect situation over a period of
a couple days, and I thought for sure "this drive is
going to die". I've been using that drive, and a couple
others that show 200-300 in the display, and those
drives are *still* working today as scratch drives
for experiments. They just won't die. So on the one hand,
if the value in that field grows rapidly, I replace
with a fresh drive. But if the drive has a change of
heart, it might actually last a long long time. The
counts never drop, but they can stop increasing too.
HTH,
Paul