WIndows/HD Sentinel conflicting info

How, what, where and why - when using the software.
vairox
Posts: 5
Joined: 2013.03.11. 20:18

WIndows/HD Sentinel conflicting info

Post by vairox »

Infamous Seagate ST3000DM001 3TB Drive, think I got it in 2011 or 2012.
Image2.jpg
Image2.jpg (445.34 KiB) Viewed 4624 times
Image4.jpg
Image4.jpg (467.36 KiB) Viewed 4624 times
Image5.jpg
Image5.jpg (467.36 KiB) Viewed 4624 times
ST3000DM001-1CH166_Z1F5Q4HB_CC49-surface.jpg
ST3000DM001-1CH166_Z1F5Q4HB_CC49-surface.jpg (241.21 KiB) Viewed 4624 times

HD Sentinel reports:

There are 6152 bad sectors on the disk surface. The contents of these sectors were moved to the spare area.
88 errors occured during data transfer. This may indicate problem of the device or with data/power cables. It is recommended to examine and replace the cables if possible.
At this point, warranty replacement of the disk is not yet possible, only if the health drops further.
It is recommended to examine the log of the disk regularly. All new problems found will be logged there.

WINDOWS 7 Scan on 9/1/17 says:

Chkdsk was executed in read/write mode.

Checking file system on A:

CHKDSK is verifying files (stage 1 of 5)...
256 file records processed. File verification completed.
0 large file records processed. 0 bad file records processed. 0 EA records processed. 0 reparse records processed. CHKDSK is verifying indexes (stage 2 of 5)...
278 index entries processed. Index verification completed.


CHKDSK is verifying security descriptors (stage 3 of 5)...
256 file SDs/SIDs processed. Security descriptor verification completed.
12 data files processed. CHKDSK is verifying Usn Journal...
352 USN bytes processed. Usn Journal verification completed.
CHKDSK is verifying file data (stage 4 of 5)...
240 files processed. File data verification completed.
CHKDSK is verifying free space (stage 5 of 5)...
732489073 free clusters processed. Free space verification is complete.
Windows has checked the file system and found no problems.

2861458 MB total disk space.
21568 KB in 6 files.
12 KB in 13 indexes.
156139 KB in use by the system.
65536 KB occupied by the log file.
2861285 MB available on disk.

4096 bytes in each allocation unit.
732533503 total allocation units on disk.
732489074 allocation units available on disk.


Windows 7 Scan on 8/9/17 says:

Chkdsk was executed in read/write mode.

Checking file system on A:
Volume dismounted. All opened handles to this volume are now invalid.

CHKDSK is verifying files (stage 1 of 5)...
122368 file records processed. File verification completed.
53844 large file records processed. 0 bad file records processed. 0 EA records processed. 0 reparse records processed. CHKDSK is verifying indexes (stage 2 of 5)...
129784 index entries processed. Index verification completed.


CHKDSK is verifying security descriptors (stage 3 of 5)...
122368 file SDs/SIDs processed. Cleaning up 2 unused index entries from index $SII of file 0x9.
Cleaning up 2 unused index entries from index $SDH of file 0x9.
Cleaning up 2 unused security descriptors.
Security descriptor verification completed.
3709 data files processed. CHKDSK is verifying Usn Journal...
33578736 USN bytes processed. Usn Journal verification completed.
CHKDSK is verifying file data (stage 4 of 5)...
Read failure with status 0xc000009c at offset 0x1ee19638000 for 0x10000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19638000 for 0x1000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19639000 for 0x10000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19639000 for 0x1000 bytes.
Read failure with status 0xc000009c at offset 0x1ee1963a000 for 0x10000 bytes.
Read failure with status 0xc000009c at offset 0x1ee1963a000 for 0x1000 bytes.
Read failure with status 0xc000009c at offset 0x1ee1963b000 for 0x10000 bytes.
Read failure with status 0xc000009c at offset 0x1ee1963b000 for 0x1000 bytes.
Read failure with status 0xc000009c at offset 0x1ee1963c000 for 0x10000 bytes.
Read failure with status 0xc000009c at offset 0x1ee1963c000 for 0x1000 bytes.
Read failure with status 0xc000009c at offset 0x1ee1963d000 for 0x10000 bytes.
Read failure with status 0xc000009c at offset 0x1ee1963d000 for 0x1000 bytes.
Read failure with status 0xc000009c at offset 0x1ee1963e000 for 0x10000 bytes.
Read failure with status 0xc000009c at offset 0x1ee1963e000 for 0x1000 bytes.
Read failure with status 0xc000009c at offset 0x1ee1963f000 for 0x10000 bytes.
Read failure with status 0xc000009c at offset 0x1ee1963f000 for 0x1000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19640000 for 0x10000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19640000 for 0x1000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19641000 for 0x10000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19641000 for 0x1000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19642000 for 0x10000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19642000 for 0x1000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19643000 for 0x10000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19643000 for 0x1000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19644000 for 0x10000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19644000 for 0x1000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19645000 for 0x10000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19645000 for 0x1000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19646000 for 0x10000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19646000 for 0x1000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19647000 for 0x10000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19647000 for 0x1000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19648000 for 0x10000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19648000 for 0x1000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19649000 for 0x10000 bytes.
Read failure with status 0xc000009c at offset 0x1ee19649000 for 0x1000 bytes.
Windows replaced bad clusters in file 97792
of name \SEAGAT~1\Seagate\REGIST~1\SOFTWA~1\[111]\WETAND~1\CHANEL~1.MP4.
122352 files processed. File data verification completed.
CHKDSK is verifying free space (stage 5 of 5)...
45809866 free clusters processed. Free space verification is complete.
Adding 18 bad clusters to the Bad Clusters File.
CHKDSK discovered free space marked as allocated in the
master file table (MFT) bitmap.
CHKDSK discovered free space marked as allocated in the volume bitmap.
Windows has made corrections to the file system.

2861458 MB total disk space.
2682169 MB in 64523 files.
27296 KB in 3710 indexes.
316663 KB in use by the system.
65536 KB occupied by the log file.
183239468 KB available on disk.

4096 bytes in each allocation unit.
732533503 total allocation units on disk.
45809867 allocation units available on disk.


I backed up all data, formatted it and rescanned it and a DReinitialize disk surface scan showed zero issues, so what gives?

would you trust any data on this drive?
User avatar
hdsentinel
Site Admin
Posts: 3128
Joined: 2008.07.27. 17:00
Location: Hungary
Contact:

Re: WIndows/HD Sentinel conflicting info

Post by hdsentinel »

Thanks for your message and excuse me for the confusion.

No, I can confirm that there is no conflicting info, I'm afraid what you see is completely normal on a such problematic drive.

The "bad sectors" reported in the text description are no longer used by the hard disk: they are already reallocated.
It means the spare area is used for all reads and writes targeting those bad sectors instead of the original location.
Read/write operations, disk surface tests (even the tests in Hard Disk Sentinel) does not access those sectors, but tests the remaining data area and the spare area. This should be good, as this way you can be sure that the original (bad) area does not contain important data and can't risk data loss.

This is why the detected and reported bad sectors can NEVER cause problems, regardless of their position because that problematic area is never used any more.
This is why manufacturers (really shame but work this way) "allow" some bad sectors and may not offer warrantly replacement.

Chkdsk /R never finds or repairs problems with the hard disk, but "repairs" problem only with the logical volume / partition. Even if sounds surprising, this may be independent form the actual hard disk status:
chkdsk may find and report problems on a perfect hard disk and vice versa: it may show perfect status on an almost dead hard disk.

However in your case chkdsk _already showed_ problems, so data corruption/data loss may already happened. Not surprising on a hard disk with so many problems and low health.

By using the surface tests in Hard Disk Sentinel, you can verify if the currently used data area is error-free, there are no further errors reported (no weak, damaged sectors, no further problems).

For more information about these "bad sectors", please click on the "?" next to the text description (the text area describing the issues) and check
https://www.hdsentinel.com/faq.php#health

If you prefer, after you used the tests in Hard Disk Sentinel and confirmed the status, you can acknowledge the reported problems (as they're already fixed), causing that the errors will be removed from the text description and the health of the drive improves. Then Hard Disk Sentinel will only report any problems occur in the future (if there will be).

However, because of the relatively higher number of problems and the relatively low health and the fact that corruption already detected/reported, I'd suggest to be careful about this hard disk. I'd expect new problems in future use, so I'd recommend to use it only for secondary storage and with constant monitoring and starting immediate backup upon any (even minor) change of the reported status.

Please check this page about how to clear the errors, eliminate the displayed problems after verified that the current status is really stable and the disk surface can be used without problems:
https://www.hdsentinel.com/faq_repair_h ... _drive.php

(If you are interested, this page: https://www.hdsentinel.com/hard_disk_ca ... ectors.php shows a slightly different situation where chkdsk does not help, but makes things even worse, so it is not best way to diagnose and repair the hard disk itself, just the current logical volume. But we can't expect perfect logical volume (at least for long time) on a hard disk with high number of problems and low hard disk health).
vairox
Posts: 5
Joined: 2013.03.11. 20:18

Re: WIndows/HD Sentinel conflicting info

Post by vairox »

chkdsk /r showed no issues, surface scan with hd sentinel showed no issues?
User avatar
hdsentinel
Site Admin
Posts: 3128
Joined: 2008.07.27. 17:00
Location: Hungary
Contact:

Re: WIndows/HD Sentinel conflicting info

Post by hdsentinel »

Yes.
Because at this moment, the hard disk is generally stable, working correctly.

This is the purpose of the spare area: when any bad sector found, the hard disk redirects all further reads/writes to such spare sectors, instead of using the original bad sectors.
The original bad sectors no longer used: as I wrote, chkdsk or any disk testing functions (including Hard Disk Sentinel disk tests) do not use (read/write/test) them.
So ideally users will not see any degradations, not see problems and the drive seems usable - until complete failure happens.

If the drive has relatively small amount of such problems - then yes, it can still be used and we can trust it.
But when thousands of sectors already reallocated, there is high chance that more and more sectors near the original sectors will fail. Maybe not today or tomorrow, but in the near future when they used.

You may start a Disk menu -> Surface test -> Read test in Hard Disk Sentinel.
There is high chance that (even if the complete data area seems working) there may be slower accessible regions on the disk surface map - which indicate the drive can be read/written in general - but sectors may already show performance issues and can predict possible problems later when they are used for actual storage. Chkdsk or other methods may not sensitive enough to report such issues (performance degradations, retries, damaged sectors and so).

Generally now, when the drive is stable - it can still be used, but considering its status and the problems ever occured in its lifetime (which recorded and read/displyed by Hard Disk Sentinel) personally I'd not really use to store mission critical data.

If you prefer, you can clear the error-counters in Hard Disk Sentinel to show it as good (as now all problems repaired). Then only possible new problems, degradations will be reported by the software. But this does not make the hard disk perfect of course.

If you prefer, you may use Report menu -> Send test report to developer option so I can assist in this procedure. Also later, when the status will (SURELY will) change (I mean degrade) would be nice to compare with the current status, examine differences.
Post Reply