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.