Are there ghost IDE drives generating Event log erroros???

[RPT]

HDD Gurus needed -What do you think - IMO errors described below are all IDE and not SATA disk related.
Please correct me, if I'm wrong. Please suggest how to troubleshoot if needed ... Thanks!

Windows XP Pro fresh installation. and Event log

Error source - disk; Event ID 11; description: The driver detected a controller error on \Device\Harddisk0\D
How to find out which is Harddisk0? I'm afraid, that it may be non existing PATA? What means D in the end? A partion d:?

also few errors: Source - atapi; Event ID 5; description: A parity error was detected on \Device\IDE\IDEport2
--------
I built and installed XP to MSI contemporary motherboard G41M-P25 with intel ICH7 SATA chipset and CPU is E5700.
Now there are odd failures and only failure events are pointing to HDD

Installed is single SATA HDD Seagate ST2000DL003-9vt166 (according to device manager) to SATA1 and DVDRW to SATA2.
No PATA devices.

I have run successfully MHDD tests and Mem86+.

Failure symptoms are CPU overload 90-100% without any accordingly listed process. (Yes - Show processes from all users is enabled )
Sometimes occasional crashes without any event log.
As all existing errors are disk related, I started troubleshooting with disk and I don't understand with HDD Gurus what is going on.

[networks]

Drive0 is normally the first hard drive in the computer. Disk Manager will also show this as drive0 in the left hand pane. Based on your symptoms and errors your hard drive is indeed failing. Time to replace it. If its new then RMA it back to Seagate for a replacement assuming its still under warranty. If you don't have a good backup of the data now is the time before you run any tools on the drive.

[pclab]

Hi

No errors during installation? Do you have SMART enabled?
Check cables and PSU.

[Vulcan]

IMO errors described below are all IDE and not SATA disk related.
Please correct me, if I'm wrong.

You're wrong. Windows is referring to its IDE driver in some of the error messages, but that does not prove what interface is on the actual hardware.

Remember about the backwards compatibility which was designed into SATA and its register set, such that old IDE drivers could use SATA disks (with SATA bridge hardware). If you check your h/w configuration, I expect you to find that you have the SATA interfaces in IDE/compatibility (and not AHCI) mode.

Please suggest how to troubleshoot if needed ... Thanks!

Troubleshooting Windows is off-topic for this board, but you'll find information about decoding Windows event codes on the MS support website. I used to do this (many years ago), and it is not always easy - you typically need to examine the full event log entry hex data, to get the maximum value from such messages.

I'm afraid, that it may be non existing PATA?

No - I've explained your misunderstanding above.

What means D in the end? A partion d:?

No - some Windows versions truncate the device path in event log entries, unfortunately.

also few errors: Source - atapi; Event ID 5; description: A parity error was detected on \Device\IDE\IDEport2

I find this very interesting. This is more likely to be a problem with your SATA cables (as mentioned by pclab) or motherboard, than with the disk. So your disk might just be a victim, of a cause which is really elsewhere.

I have run successfully MHDD tests and Mem86+.

Interesting, but as with all "successful" test results, this proves nothing.

Sometimes occasional crashes without any event log.

This situation is common on many different types of computer system, where the problem is with disk I/O, and there is only one disk - if there is a problem with disk I/O, then no event log can be written to the disk for that problem!

As pclab also mentioned, looking at the SMART data for the disk will be helpful - specifically I recommend that you install smartmontools for Windows, so that you can collect and supply the disk's internal error log and not only the usual SMART attribute values, which are displayed using other SMART utilities.

During your troubleshooting, I suggest that you also look at the dates & times of the relevant event log entries, find when they first started, find when they have been logged since they started, and think about what changes to the system (or what the system was doing at those times) which might fit those timings.

You may also want to invest some time to get confidence in that disk drive by testing it with different SATA cables, on a different SATA port (perhaps even in a different PC).

[edit] P.S. As networks says - make sure you have a verified backup, and this does not have to turn into a data recovery situation even if the disk does have a problem (although I see no conclusive evidence of a disk problem, in the information you have provided so far - the data I requested will help to confirm or deny that possibility).

[RPT]

Thanks for thoughts how to understand and continue.
Cables I have changed, the smart log was empty.
Event log disk error entries started on the installation day 3-4 and have continued another 3-4 days under inspection, 4-5 errors per day.

Now as final effort, I copied boot volume with Acronis to new spare disk.

All components are under exporter warranty and my task is just to determine which one fails.

At closer inspection the event log hdd error content was somehow misleading and therefore I already thought for a while, that indeed MS Windows suffers errors from ghost drives

[networks]

RPT Now that you have a good backup you may want to download the Seagate Seatools and run them against the drive. They have a CD image you can boot from to run the tests. I am not saying its the best tool but one that is free. I know you said MHDD said the drive was ok. Also you can try downloading HDDScan at http://hddscan.com/ and check the smart attributes with that tool and see if any of them are yellow or red. The true test will be if the errors go away running on the replacement drive if you are doing that now as a process of elimination. If the errors continue it may well be the controller on the motherboard being the culprit.

[Vulcan]

the smart log was empty

That wasn't the answer to the question that I asked. There is specific information within the full (i.e. smartctl -a) SMART data, which may help to confirm where the problem is.

However, you seem to be happy continuing the troubleshooting on your own from here (getting 4-5 errors per day should make this easy for you to solve using parts substitution), so I wish you good luck!

[RPT]

After 48 successful hours with replacement drive and without errors in event log I changed back the previous disk and checked smart with HDDSCAN.
There is one yellow exclamation mark - 199 Ultra DMA CRC errors.
Does that means disk should be replaced? Or does manufacturer expects drive to be capable to recover from this error and disk doesn't need replacement?

Is there any more software suggestions to determine error severity?
Aren't errors in Windows XP event log serious enough to send disk back to manufacturer?

Thanks!

[Vulcan]

After 48 successful hours with replacement drive and without errors in event log I changed back the previous disk and checked smart with HDDSCAN.

So now what happens with another 48 hrs of usage with the original disk again, with a similar workload to what you used with the replacement disk. Do the same errors as before return, or not?

(To be clear - just because the errors have stopped with a different disk, does not actually prove that the original disk is faulty.)

There is one yellow exclamation mark - 199 Ultra DMA CRC errors.
Does that means disk should be replaced?

No. This is normally caused by issues external to the disk drive. This fits with the Windows Event ID 5 entries - possibly caused by the same problem.

Aren't errors in Windows XP event log serious enough to send disk back to manufacturer?

In my experience, no, but I haven't seen evidence that you followed my suggestions to fully investigate those event log entries. Without decoding them fully, the cause of the events is unknown - but is certainly not proved to be the drive.

[edited to add this] P.S. I will, again, recommend that collecting the full SMART data from smartmontools will give useful info. If you are not willing to invest the time to install & run that, then I will probably start to lose interest - but at the very least, if you supply the output from HDDSCAN which you already have, then there will be something for readers to look at.

[RPT]

Added HDDSAN SMART results.
In meantime I continue investigating how to run smartmontools, from boot Cd or from Windows.
I can't create exactly the same work burden as there is application data on partition D of the same disk.
But some earlier errors have been logged int event log instantly after PC restart, so that it doesn't seem to be a long time run problem.

[RPT]

Sorry, html was not accepted - I add now as Rar.

Attachments

ST2000DL003-9VT166-5YD1EBBK-SMART.rar

(3.37 KiB) Downloaded 457 times

[RPT]

Smartmontools results uploaded.

smartmontools2TB.txt

(11.26 KiB) Downloaded 687 times

[Vulcan]

Question: Was the "replacement disk" that you tried, exactly the same make & model as the "original disk"?

I can't create exactly the same work burden as there is application data on partition D of the same disk.

That is one reason (of several) why you cannot interpret the lack of errors with the replacement disk, to decide whether the original disk is faulty or not - without further evidence. Unfortunately your explanation of why the testing is different, was not clear enough for me to understand or offer further comment.

Smartmontools results uploaded.

Great, thank you very much.

Based on that information, I see no evidence for internal mechanical or read errors inside the disk. The non-zero values of attributes 188 & 199 may have the same cause.

I can't tell you about the causes of each of the Windows event log entries, without doing lots of work - out of scope for free advice. However based on your comments about those event log entries (especially Event ID 5), and the SMART data, I expect that either:

a) the drive is not faulty, and the problem is with the SATA interface somewhere outside of the drive;

or

b) the problem is with the SATA interface electronics of the drive.

I don't expect that software can tell you any more - which is why careful troubleshooting by parts replacement (and understanding how to interpret the results), might be the best way forwards for you.

Finding a good test case, which definitely "fails" (i.e. causes event log entries) within a certain time with the original drive (e.g. you definitely expect an error within X hours, based on several repeated tests), and which can be repeated (same test exactly!) with a different drive, and then confirmed to fail again (same test exactly!) with the original drive, would be very interesting. Note: If the replacement disk is a different make/model than the original disk, then that can cause extra complications with interpreting the test results - hence my question at the beginning of this reply.

[RPT]

Both disks are identical.
Partition D: is used for shared data and data is not the same anymore after 48 hours. While it may be possible to create previous conditions, it takes a lot of time to copy everything to continue without corruption. Also, some errors were logged instantly after PC start up without any other application running - without any stress. I have made already several efforts to force errors but no success and finally I gave up and posted a thread here

Right now I have run out of ideas and keep the previously failed HDD running without any special tasks, hoping to receive errors again.

[Vulcan]

Both disks are identical.

Thanks. In that case, I would follow the plan which I suggested in my previous posting, if I was in your situation.

Since the disks are the same, then it is reasonable to expect similar behaviour / response to an external (non-disk) problem, if that is the cause of the issues you are seeing. As I understand your situation, the main troubleshooting issue you have, is not having a clear test case, despite the fact that you said you were getting several errors per day (4-5).

I don't understand enough about your situation to see how you have "lost" that test case.

Partition D: is used for shared data and data is not the same anymore after 48 hours.

That only matters if your test case includes that data - I haven't seen you mention anyhere that you need to use that data in your testing. But later you said:

Also, some errors were logged instantly after PC start up without any other application running - without any stress.

Not enough detail about the exact frequency / reproducibility of those "some errors" - but if they were very frequent, then can you use that as your test case, to repeat with both the original disk and with the replacement disk?

I have made already several efforts to force errors but no success

I don't understand - earlier you said that you were getting 4-5 errors per day; now you're saying that you can't force errors. Do you mean that you were never able to force errors, but 4-5 happened anyway each day, when using the applications on partition (drive) D:?

If you mean something like that, then I would put back the original disk, and try to provoke errors in a way which can be duplicated with a different disk e.g. running HDDScan, or WDlg or some other disk reading utility (not your applications); and also doing writes to temp files on the disk. The event log entries might also tell you if they occurred during reads or during writes, so that can guide you about what tests to try.

If you didn't have a clear test case (which can be duplicated when using the replacement disk), then it was probably premature to start moving hardware - but from your earlier comments it seemed that you did have easy to reproduce errors.

Right now I have run out of ideas and keep the previously failed HDD running without any special tasks, hoping to receive errors again.

That's your choice about what to do - there is definitely more troubleshooting process that can be applied, but the details of your tests are not clear enough for me to fully understand, to be able to offer more steps.

Summary: As far as I can understand (which is clearly incomplete), you need to re-think finding a failing test / configuration using the original disk, which can also be repeated using the replacement disk. That would be my approach.

[RPT]

There is one significant difference - new drive after 48 hours - HDDScan didn't show any CRC errors against failing drive, instantly after starting PC, there were CRC errors, as seen in uploaded logs.
Does HDDscan Smart log is from the whole drive lifespan or just a current power up session?
How severe are such errors in event log? I understand that PC may be capable to recover from some CRC errors.


Data indexes a on C: and actual shared data on D: are already different as correct up to date index is now on the new disk C:\.

Thanks, yep I leave the failing disk running for some period, hoping to see new error entries. Errors were rather occasional, usually 1-2 errors during first 15 minutes and later 3-7 more errors. But today, as during 4-5 hours there haven't been not a single error with failing disk, this strategy doesn't seem to work.


Thanks!

[Vulcan]

Having spent several hours replying to questions on this topic over the past few days, I'll make this my last reply for a while. I don't think I'm able to understand you well-enough, to make useful progress at the moment. Perhaps someone else understands your questions & responses better than me...

There is one significant difference - new drive after 48 hours - HDDScan didn't show any CRC errors against failing drive, instantly after starting PC, there were CRC errors, as seen in uploaded logs.

I can't parse that. It's too confusing about when you are referring to the new drive, and when you are referring to the original drive (which might be what you are calling the "failing drive" - but if you are convinced that the original drive is faulty, then surely we're finished here?).

You also don't explain where in the HDDScan output you were checking for CRC errors (and where you believe there were none). The "uploaded logs" which you mention - I guess you mean the smartmontools output - show all the same SMART data as the HDDScan output - plus a little more - although the data is shown slightly differently (different column order and hex vs. decimal), but it's the same basic values.

Therefore I can't see how you are finding a difference between HDDScan output and the "uploaded logs" related to CRC errors (I guess you mean SMART attribute 199, but I'm not sure). Perhaps you misinterpreted the HDDScan rightmost column (000 for attribute 199), to be the raw value?

Does HDDscan Smart log is from the whole drive lifespan or just a current power up session?

Answer: The whole drive lifespan (assuming no-one clears the SMART data, which is not something that users have a normal / supported / official way of doing).

Specifically, those SMART attribute raw values which are counters (some are, some are not - attribute 199 raw value is a count in my experience, but the raw values are not actually defined in a standard) cannot tell you when their value increased - they only record a value. Obviously the SMART error log (collected by smartmontools) is a timestamped log (within limits), but that is empty.

From what you are saying above, it seems like you have seen the raw value of SMART attribute 199 be non-zero on the original drive, and thought that these are new errors "instantly after starting [the] PC"?

As with any counter, you would need to monitor that value for changes over time, if you were choosing to use that info (which I would do) - but I thought your testing was checking for new entries in the Windows event log?

How severe are such errors in event log?

As I've explained, Windows event log decoding is out-of-scope for what I'll do for you. That used to take me quite a long time, when I had to do it as part of my job, including researching driver source code etc. (DDK) in some cases.

All I'll say is that IMHO, those events that you have mentioned so far, are abnormal.

Thanks, yep I leave the failing disk running for some period, hoping to see new error entries.

If leaving the original disk "running" was not your original test, then...

Errors were rather occasional, usually 1-2 errors during first 15 minutes and later 3-7 more errors. But today, as during 4-5 hours there haven't been not a single error with failing disk, this strategy doesn't seem to work.

... this lack of errors is not really a surprise. I didn't say that just "leaving the disk running" was a suitable test, and that's why this choice of strategy doesn't work. Another possible interpretation of your result, is that with the moving of disks & cables, you have now touched or reseated a loose SATA connection, and the reason for you seeing no "failures", is that there is currently no actual fault, perhaps?

I wish you the best of luck.

[RPT]

Thanks to Vulcanos for his time. All my 5 stars go to him

Swapping disks between mobo ports, I believe I have determined the disk onboard controller being faulty.

To whom it may be interesting to compare, I add here SMART report of faulty and errorless disks.

What do you think, should MHDD discover such errors or are these discoverable only on higher driver level?
Can you suggest any test which should have revealed this disk onboard controller error?
I could now leave this disk running on another PC to test suitable discovering software availability.

Thanks!

SMART_ST2000DL003_CRC_ERRORS.pdf

(36.2 KiB) Downloaded 1050 times

SMART_ST2000DL003.pdf

(35.57 KiB) Downloaded 847 times

[Vulcan]

Thanks to Vulcanos for his time. All my 5 stars go to him

Thanks.

Swapping disks between mobo ports, I believe I have determined the disk onboard controller being faulty.

I guess you are saying that you have identified the problem as being a specific SATA interface on the motherboard? Anyway, I'm glad you found the problem, whatever it is.

What do you think, should MHDD discover such errors or are these discoverable only on higher driver level?

As I said earlier, one clue is the non-zero value of SMART attribute 199, but that has limitations (it's only a counter, not a log) and it cannot tell you exactly where the problem is (disk SATA electronics / SATA cable / external interference / motherboard SATA port etc.). The other clue was the "parity error" reported by a disk controller (in your case reported as IDE) logged by Windows, which you mentioned.

It is also absolutely impossible for MHDD to identify some types of SATA problems specifically, as they will just appear to be timeouts - and timeouts can have many causes, not only the interface. However MHDD would show you the value of SMART attribute 199 - so then it is up to you, as the troubleshooter, to know how important that is. The same is true about that specific error in the Windows event log.

I have experience in this specific area, and I can tell you that interface diagnostics are a real challenge for storage systems. FC & SAS interfaces have better diagnosibility, but SATA is designed to be simple & cheap, so you cannot expect to have all the same features of the more expensive interfaces, because you are not paying to have those diagnosibility features!

If you really want better interface diagnosibility, buy SAS disks & HBAs - then learn about their error counters in the disks, SAS expanders & HBA ports, and how to access that information from your OS. Using SATA disks with SAS HBAs can get you some of the benefits of the improved SAS diagnosibility.

Can you suggest any test which should have revealed this disk onboard controller error?

I haven't seen one for SATA, although I have written interface diagnostics for other interfaces and it would be possible to write something to specifically SATA interfaces - but it would have significant limitations, and could not necessarily identify exactly what was faulty.

As I explained, SATA simply does not include all the diagnosibility features which SAS has - that's one reason why disk manufacturers can sell SAS disks at a premium price! In the enterprise market, diagnosibility is worth paying for, as it (typically) reduces downtime.

[RPT]

FYI. I mean disk on board controller is faulty, not motherboard.
I moved this faulty disk to another PC just for some more testing. So are also all disk errors on this another PC now. Interestingly HDDScan couldn't detect failures while Windows Event logged these during HDDscan scan task. But as Vulcanos told, these errors are out SATA interface precision.