Drive: WDC WD1001FAES-60Z2A0
The BIOS claims hard drive failure is imminent. I made a perfect image using ddrescue with no errors. A scan with MHDD showed no issues. To me the smart data does not show any media errors. Smart data from HDDSuperTool is below, and screenshots of BIOS message, MHDD smart data, and MHDD scan are attached. I need an opinion on what is going on here. Is there something in the smart data that indicates failure? Or is it possible that the BIOS on this computer is corrupt?

_________________
http://www.hddsuperclone.com
Home of HDDSuperClone

It doesn't look bad from what I'm seeing there, but I don't think all the S.M.A.R.T. parameters are being displayed there either. Maybe try checking it with Crystal Disk Info it might shed some more light on why it's giving the error.

_________________
Data Medics - Hard Drive, SSD, and RAID Data Recovery Service Company

I HATE having to plug a drive into Windows. But since this is already recovered 100% and just needs to be assessed, I did it. Screenshot from CrystalDiskInfo attached. As you can see, it reports as good.

_________________
http://www.hddsuperclone.com
Home of HDDSuperClone

BIOS is complaining because the End-To-End Error attribute has hit the threshold value of 97, as reported by CDI. However, the Super Tool has a bug in displaying these same SMART thresholds. Also the software is displaying two raw values instead of one, and "attribute" is incorrectly spelt as "attrubite".

_________________
A backup a day keeps DR away.

If I am reading it right, there have been 3 End-To-End Errors and 44 Command Timeouts. I have looked up the End-To-End Error and also the Command Timeout, and between the two I am unsure if the issue is the drive, or some other physical hardware issue. The computer's owner mentioned that the issue seemed to happen after a lightning storm. Knowing this, would it be a good recommendation for them to buy a whole new computer?



Spelling error will be fixed in next release (I sometimes have dyslexic fingers when typing).

The thresholds are exactly what data the drive provides. It would seem that on most newer drives that data is always 0. Other tools like CDI are getting the threshold value from some sort of list. Find me that list and I will put it in HDDSuperTool.

The second raw value is actually the high order 2 bytes, which is often not used and is not included in MHDD output. I don't have the link, but I did this because I read that the normal raw value was 4 bytes, and the other 2 bytes were optionally used. At first I had it as one value, but didn't like how it displayed sometimes. In reading up on the above errors, I came across information that the data is often 3 words (0x0000 0x0000 0x0000). My biggest problem is that I don't have a way to display leading 0's in the scripting, so it would end up 0x0 0x0 0x0. Actually I just now thought of a possible way to display leading 0's as I was typing this. If it works, would it be better to have the full raw value as all one number like CDI (0x000000000000)? I think I will work on doing it that way and see how it turns out.

_________________
http://www.hddsuperclone.com
Home of HDDSuperClone

After some more looking into this, I have found that it would appear that there is a second method to get the threshold values- SMART READ ATTRIBUTE THRESHOLDS D1h. That doesn't seem to be in any of my ATA documentation. The only place I have found this info so far is in specific hard drive specification data sheets. I will work on adding this into the smartdata script. The information I had previously (which I still can't find again) listed the last byte in the smart attribute entry as the threshold value, which I thought I had a drive that did provide threshold information in that field.

Smart Attribute Data Structure:
byte 1 = ID
byte 2-3 = flags
byte 4 = current value
byte 5 = worst value
bytes 6-11 = raw value
byte 12 = threshold (this seems to be wrong)

Device Attribute Thresholds Data Structure:
byte 1 = ID
byte 2 = threshold
bytes 3-12 = reserved

_________________
http://www.hddsuperclone.com
Home of HDDSuperClone

FYI
New output from HDDSuperTool below. This will be available in the next release.

Edit: The real output is completely aligned. This code box did some adjustments of its own and slightly broke the alignment.

_________________
http://www.hddsuperclone.com
Home of HDDSuperClone

To get back away from the scripting issues, this is still my main concern. At this point in time I am thinking that the response to the owner will be that while replacing the hard drive will clear the error message, it may or may not solve the overall problem. The drive has reported communication issues between itself and the computer, and while it may likely be the fault of the drive, it could also be an issue with the computer itself. I cannot be sure that replacing the hard drive will solve the problem. Due to the nature of the issue and the possible cause (power surge from lightning), I would recommend replacing the whole computer.

If anyone thinks this is incorrect, please respond with the reason why.

_________________
http://www.hddsuperclone.com
Home of HDDSuperClone

you can rule out whether or not the problem is with computer hardware.
first take s.m.a.r.t from a different computer of any hard drive then take s.m.a.r.t from the suspected computer and compare it against End-to-End Errors and Command Timeout, just a though

_________________
RAID/Server Recovery

The SMART READ ATTRIBUTE THRESHOLDS command (B0h/D1h) was present in ATA-3 but has been obsoleted in recent versions of the standard. However, it appears that HDD manufacturers have opted to retain support for this command in current firmware, probably because of all the software that would be broken if they were to drop it.

As for the raw attribute values, I believe that the full 56 bits are available for storing these data. In fact ISTR that some Seagate firmware actually uses the uppermost 8 bits (48 - 55) for storing the seconds count for Head Flying Hours or Power-On-Hours. Furthermore, there is no standard that governs whether the raw data are presented as bytes, words, or dwords. For example, Seagate's Seek Error Rate attribute stores the lifetime seek count in the lowest 32 bits and the seek error count in the upper 16 (or 24) bits. BTW, HDDScan reports 56 bits for the raw value, although it hyphenates the lower 16 bits, presumably because the author believes (erroneously) that these have some universal significance. Some authors also "interpret" the attributes without displaying the raw data, with the result that they sometimes get it wrong. IMHO, reporting all 56 bits as a single hexadecimal number, without adding your own interpretations, would be preferable.

I can't answer your question in respect of the End-To-End Errors, except to say that these should be detectable AND correctable, with the affected data being retransmitted. That said, the threshold is set very high, so this would suggest that only 3 such errors are acceptable during the life of the drive.

As for the 12th byte storing the attribute threshold, I haven't seen this, but I have always thought that it, or the leading, apparently unused (?) flag byte, would have been the most logical place for it.

One more thought that occurred to me in the past was whether any HDD manufacturers utilise the reserved area within the thresholds data block. Perhaps they could use it to "park" attribute information prior to calculating their normalised values.

_________________
A backup a day keeps DR away.