dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
1265

koitsu
MVM
join:2002-07-16
Mountain View, CA
Humax BGW320-500

3 edits

koitsu to Ghastlyone

MVM

to Ghastlyone

Re: Repair or Replace Disk Warning on Brand New WD Caviar Black.


HD Tune Pro acting stupid

HD Tune Pro acting even more stupid
Me either, unless HD Tune Pro was already running when you plugged in the drive (e.g. you "hot-swapped" it in), in which case re-launching HD Tune Pro should solve that. But somehow I don't think that's what happened.

I can assure you that the Erase feature in HD Tune Pro works since I've used it myself many times over, but Active@ KillDisk provides more granularity -- and if it fails, might actually shed some light on what the error reason is (volume locked, etc.). Windows does so much nonsense with disk drives under-the-hood (ranging from services to stuff the actual kernel does) that its infuriating at times.

Edit: I was able to reproduce the oddity with HD Tune Pro when trying to erase a 8GB CF drive I have. The first attempt actually erased successfully for about the first 1/40th of the drive, then spit out red the rest of the time (claiming something like 2428 errors). A subsequent Erase resulted in all errors (also 2500 error count, just like yours). Possibly the author of this software busted something in the 5.00 release, I'm not sure.

I gave Active@ KillDisk a shot. When erasing the same device, I decided to uncheck "Ignore all errors" just to see what transpired. The CF drive did erase, but intermittently I'd get "device is unable to erase sector xxx" where the sectors seemed somewhat arbitrary:

Error (the device is not ready) writing sector 104580 on Removable Disk 2.
Error (the device is not ready) writing sector 306306 on Removable Disk 2.
 

I re-ran the erase with "Ignore all errors" checked, and it did complete, but with this log message:

Bad (unwritable) sectors detected from 394758 to 15523839 on Removable Disk 2.
 

Complete bullshit. I'm not really sure what these programs are doing, because this is not rocket science to accomplish.

Finally, I resorted to using dd for Windows, which I know interacts with the underlying device using the proper methodology and is no-nonsense:

D:\Util\dd for Win32>dd --list
...
\\?\Device\Harddisk2\Partition0
  link to \\?\Device\Harddisk2\DR18
  Removable media other than floppy. Block size = 512
  size is 7948206080 bytes
...
 
D:\Util\dd for Win32>dd if=/dev/zero of=\\?\Device\Harddisk2\Partition0 bs=64k --progress
rawwrite dd for windows version 0.6beta3.
Written by John Newbigin <jn@it.swin.edu.au>
This program is covered by terms of the GPL Version 2.
 
733,760k
 

...and is still going, with no errors so far. So like I said, I don't know what these other programs are doing, but it's utter nonsense.

Edit #2: dd finished. Not a single REAL I/O error (keep reading and I'll explain what's shown):

7,761,920k Error writing file: 27 The drive cannot find the sector requested
7,761,920k
121281+0 records in
121280+0 records out
 

The "error" shown is actually normal given the flags I gave dd. The 8GB CF drive is 7948206080 bytes, and I requested a read/write size of 64k (65536 bytes). 7948206080 / 65536 = exactly 121280.

The above term "record" isn't magical -- it's simply a counter of how many reads (from the if device, in this case /dev/zero, which is just a pseudo-device that returns zeros) and writes (to the of device) issued.

I did not specify a count directive to say "only read/write this many records". dd tried to go past the end of the drive by 1 record (an extra 65536 bytes), and the underlying drive said "yeah right, bye", hence the records in vs. records out delta of 1. So the drive was fully erased successfully up until that last "bogus" write.

The question is why dd tried to go past the end of the device if it could have calculated its size. Well, this behaviour is documented on the dd for Windows web site:
quote:
On many usb devices this is not reliable so you should use --size to guess the size of the device, see below.

Traditionally when using dd, if you wanted to copy an entire device, you did not specify a block count and dd would read until it reached the end of the device. If you tried to read past the end of the device, the data up to the end of the device would be returned and if you kept reading you would get an error message. Windows however does not always do this so --size will tell dd to figure out the size of the device and make sure it does not read past that point. This is important for USB sticks which stop working if you read past the end of them. This is not on by default because getting the correct size of the device is not always possible. Some devices also keep returning bogus data past the end of the device without returning a suitable error code.

I didn't use the --size parameter, as you can see, so there's the explanation for the final error shown in dd. But the drive did get erased. I even verified using HxD which can "open a raw disk" and let you look at all its bytes/sectors.

So yep, HD Tune Pro's Erase feature, and Active@ KillDisk, are doing something stupid in their code or are just buggy. See what you get for relying on GUI tools? :-) Sigh.

aurgathor
join:2002-12-01
Lynnwood, WA

aurgathor

Member

said by koitsu:

So yep, HD Tune Pro's Erase feature, and Active@ KillDisk, are doing something stupid in their code or are just buggy. See what you get for relying on GUI tools? Sigh.

Did you take take a look at the event log? I'd say there is at least a 66.6% chance that it's the OS that doing something funny.

koitsu
MVM
join:2002-07-16
Mountain View, CA
Humax BGW320-500

koitsu

MVM

I would say the chance is pretty slim; the programs themselves have bugs. The issue with Active@ is completely different than HD Tune Pro. I was able to take the exact same system (without rebooting, making any changes, etc.) and use dd if=/dev/zero of={device string} bs=64k without a single problem. So the issue was definitely was not with the OS or underlying storage subsystem/drivers.

Besides, the Windows Event Log rarely tells me anything useful. It's always dumbed-down. It's very, very rare to find anything in Windows which discloses useful information that an engineer can use. Even the MCA/MCE handler in Windows doesn't give you enough information to decode an MCE; sad panda.

aurgathor
join:2002-12-01
Lynnwood, WA

aurgathor

Member

While I do agree that Windows Event log is very dumbed-down ( or cryptic ), when I have issues, more ofthen than not, there's a corresponding "Critical", "Error", or "Warning" entry in the log, even if the only thing I can do is scratch my head and stare at the error message in disbelief.
quote:
The following fatal alert was generated: 40. The internal error state is 107.
(an actual entry from my just cleared event log )

If there's nothing in the event log, that would definitely be indicative of a bug in the program.