DNS Benchmark v2 Release 5 with Consultant License
Guest: If you own any earlier release of our DNS Benchmark you may immediately download its release #5 replacement. Running an earlier release will detect the new release and help you upgrade.
Although this release is cosmetic, appearance matters and affects ease of use. The biggest change, as seen in the image above, is that the DNS Benchmark now has a traditional Windows application menu to more fully expose its many features. This release is also "Consultant License Aware" and GRC will now issue a Consultant version when owners have previously purchased four "Personal Use" licenses. If you have previously purchased four DNSB licenses, or if you wish to upgrade your "Personal Use" license to Consultant, GRC's purchase process will direct you through that process. /Steve.
Be sure to checkout “Tips & Tricks”
Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!
/Steve.
BootAble – FreeDOS boot testing freeware
To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.
GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.
The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.
You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.
(You may permanently close this reminder with the 'X' in the upper right.)
Hello, I'm attempting to recover a Seagate Barracuda ST380021A 80GB IDE HDD which was throwing I/O errors on the PowerMac G4 it came from. DiskWarrior/Norton pointed to "bad blocks", so I though I'd try SpinRite!
I have a Dell Dimension E512 booted up to FreeDOS to run SpinRite v6.1 via a USB flash drive. All other IDE drives except the troubled HDD are disconnected. I selected level 2, the 80GB drive is detected and selected, and the scan proceeds till it hits bad blocks ~57% through when the scan and it flips to DynaStat recovery. If I leave it alone it seems to be fine... but if I arrow-key between the status screens, SpinRite seems to freeze up a few minutes later (can't hear any activity on the HDD, screen is frozen, caps-lock on the keyboard no longer lights up when pressed). My only option is to power off the PC and try again. I've tried ~4 times so far with the same result. It ran all last night, but again, froze up shortly after toggling between the screens this morning. I've used this Dell to run SpinRite previously w/o this issue. However, past attempts were on v6.0. I let the new RAM test in v6.1 run for a few hours just in case it was the RAM in my PC. However, it found no errors.
Any advise on what I should try to resolve this freezing issue?
Hmmm, is the USB flash drive writable? I'm wondering if maybe it's not and SpinRite is trying to write to the log there and getting hung up that way. (Not suggesting I know this can happen, it's just a guess.)
It's connected to the Dell via IDE channel 1 and set to MASTER/Single drive. This PC's motherboard only has 1 IDE port on it.
Spinrite's Drive list discovers the drive as: ST380021A
I do want the data from the drive. I was hoping to get the bad block repaired so I can take an image.
Hmmm, is the USB flash drive writable? I'm wondering if maybe it's not and SpinRite is trying to write to the log there and getting hung up that way. (Not suggesting I know this can happen, it's just a guess.)
it's a USB keyboard. The USB boot drive is plugged into the USB ports on the front of the Dell, and the keyboard is plugged into the USB port on the back.
The scan I started last night with the options Peter mentioned (SPINRITE NORAMTEST SKIPVERIFY LEVEL 2 DYNASTAT 1 NOREWRITE) produced a different screen! "This drive has stopped responding to commands."
The scan I started last night with the options Peter mentioned (SPINRITE NORAMTEST SKIPVERIFY LEVEL 2 DYNASTAT 1 NOREWRITE) produced a different screen! "This drive has stopped responding to commands."
Ahh . . .Now things are beginning to make sense. You have a rather troubled drive there.
SpinRite 6.0, which does everything via the BIOS, uses a transfer block size of 256. Per your OP that works. But it is slow.
SpinRite 6.1, using its internal ATA/IDE native driver, starts out much more aggressively, with a transfer block size of 32768 (See the lower right corner of the Real Time Activities (RTA) screen). If the drive allows it, SpinRite 6.1 will try successively smaller transfer block sizes (16384, 8892, etc.) to find something that works successfully. In your case the drive is going off line before that happens.
You might try starting SpinRite 6.1 with the command line parameter XFER. For example:
spinrite xfer X
Where X can be any integer from 1 to 32768.
When you get to the "Before Beginning" screen, consider pressing Tab (NOT Enter) and starting at 50.0000% to save time. There is no need to keep going thru the first half of the drive which is now known to be OK. Then again, it may not matter that much with an 80 GB drive.
You could start low (for example: spinrite xfer 256) and try higher speeds. Or start higher (for example: spinrite xfer 4096) and if the drive goes off line, try smaller XFER numbers. (Or start somewhere in between.)
This would allow the advantage of SpinRite 6.1's improvements (Speed, etc.) over SpinRite 6.0 with a gentler touch to avoid the drive takinmg itself off line with a too aggressive touch.
Hope this helps! Hopefully SpinRite 6.1 will be able to recover data on this drive.
The Seagate Barracuda ATA IV ST380021A is a 3.5-inch internal mechanical hard drive released in the early 2000s as part of Seagate's Barracuda ATA IV series.
Technical Specifications
Capacity: 80 GB
Spindle Speed: 7200 RPM
Interface: Ultra-ATA/100 (IDE)
Cache / Buffer: 2 MB
Average Seek Time: 9.5 ms
Average Latency: 4.16 ms
Form Factor: 3.5-inch desktop hard drive
You can change the CMOS BIOS to IDE and try any IDE
alternatives to see if any better match the drive's
'expectations' of incoming data retrieval requests:
When resetting your CMOS or BIOS storage options, the choices under the SATA controller mode ( often labeled as IDE, AHCI, or RAID ) determine how your operating system talks to your hard drives and solid-state drives (SSDs).
The Core SATA Controller Settings
IDE (Integrated Drive Electronics / Legacy Emulation Mode):
Meaning: An older, 1990s compatibility standard. It emulates old parallel hardware so that ancient operating systems (like Windows XP) can recognize modern SATA drives.
When to use: Only if you are installing a legacy operating system that lacks native SATA drivers.
Drawback: It disables advanced drive features and limits performance.
AHCI ( Advanced Host Controller Interface ):
Meaning: The modern standard protocol for SATA storage.
It unlocks advanced features built into modern AHCI-compatible drives.
Key Features: Supports NCQ ( Native Command Queuing ) to optimize read/write speeds and hot-swapping ( unplugging drives while the PC is on).
When to use: Recommended for almost all single-drive setups running modern operating systems (Windows Vista/7/10/11 or recent Linux kernels).
RAID ( Redundant Array of Independent Disks ):
Meaning: A multi-drive setting that groups two or more physical hard drives to act as a single volume for speed (striping) or backup/redundancy ( mirroring ).
Note: If you only have one drive and no array configured, enabling RAID mode usually lets the single drive run using AHCI-like underlying performance drivers, but it is specifically intended for multi-disk arrays, and the RAID overhead often means less responsive performance.
Important Warning
Changing this setting after your operating system is already installed ( for example, switching from IDE to AHCI ) will usually cause your operating system to crash with an INACCESSIBLE_BOOT_DEVICE blue screen or a boot loop because the operating system does not have the matching storage driver loaded at startup.
Always select the correct mode before installing or rebooting your operating system.
SpinRite 6.1 automatically drops the transfer block
size to 1 when the default larger group of blocks in
one transfer has errors, so XFER 1 no longer applies
as the only way to "sneak up on errors", but XFER
can be used to calm the drive down, walk through it
slowly, especially in conjunction with limited
sectors to check.
I've run XFER 1 LEVEL 5 on SSDs ... because I'm a
brutal explorer, and the SSD came back to 100%
performance, but within only 4 additional reads, it
proved to be crap and decayed back to 5 MB data
transfer rate, so it was a good learning experience
for me ... I digress.
@Steve Gibson refined the inbuilt auto XFER feature,
and I confirm that the auto behavior mimics my own
manual troubleshooting choices, so kudos to Steve.
I suggest cleaning the contacts between the drive
circuit card and the drive:
Other than that, there's not much we can do with a
drive that goes offline except exit SpinRite, power
cycle the drive ( no need to power-cycle the
computer ), restart SpinRite, and keep at it, pick
up where we left off, or a few or many sectors or
percentages further down the drive, and keep going.
If the data we need is in a readable area, and the
unreadable area is unimportant, then we may
actually win, even with a dying drive - data
recovery from some other boot drive accessing the
bad drive as a secondary drive in the system.
Also, keep supplemental cooling fans on the drive
and the circuit card to keep them at room
temperature ... though some folks suggest keeping
the drive in it's original 'oven' cabinet, so all
parts expand and contract as original when writing
in the hopes of same-same success when reading -
toss a coin, I prefer room temperature on modern
drives, an 80 GB could be old or newer
track-spacing tech, so I dunno - I have run drives
on an extension cable while they were in my freezer
- of course I have - and it worked - of course it
did - seal them in a plastic bag so they don't get
condensation on the electronics ).
The beauty of NOT using DYNASTAT is that it then
'respects' a 'fragile' borderline drive and does
not ask too much of it.
However, an older 80 GB drive may actually need
DYNASTAT to approach a sector from back and
forth, though the drive itself is supposed to do
that natively.
Does anyone know when internal back-and-forth
sector access became a thing?
The specific error recovery mechanism you are describing—where a drive repeatedly seeks back and forth from the front and back of the platters to read a stubborn bad sector—is known as Directional Read Retry or Asymmetric Bidirectional Seeking.
Hard disk drives began integrating this into their internal firmware during the late 1980s to early 1990s, standardizing it with the arrival of the IDE/ATA interface ( ATA-1 in 1994 ).
It remained a staple through the transition to SATA and AHCI modes in the mid-2000s.
How the Technology Evolved
Before this became an automated, internal drive feature, early hard drives ( like MFM or RLL drives from the 1980s ) relied heavily on the host operating system or third-party software ( such as Steve Gibson's SpinRite (
to manually issue seek commands to oscillate the head back and forth over a bad track.
As drives transitioned to the IDE ( Integrated Drive Electronics ) architecture, the controller board was moved directly onto the hard drive itself.
This allowed drive manufacturers to build complex Hardware Error Recovery Procedures ( ERP ) directly into the drive's firmware.
The Internal "Retry" Routine
When an IDE/SATA drive encounters a sector that fails its initial Error Correction Code ( ECC ) check, it goes through a multi-stage firmware routine before giving up and throwing an I/O error:
1. The Sweep / Micro-jogging: The drive subtly offsets the read head slightly to the left or right of the track center to account for thermal expansion or track misalignment.
2. Bidirectional Seeking ( The "Back and Forth" Routine ): If micro-jogging fails, the firmware commands the head to radically seek to a track far out ( the front/outer edge ) and then back in past the target sector ( the back/inner edge ).
Approaching the defective sector from opposite physical directions changes the aerodynamic "flight" dynamics of the head slider and utilizes the mechanical hysteresis of the actuator arm to try to catch the magnetic signal under a slightly different physical alignment.
3. Preamplifier and Voltage Tweaks: Modern SATA/AHCI drives will also change the electrical gain of the head's preamplifier or alter read-gate thresholds during these passes.
The AHCI Connection
When AHCI ( Advanced Host Controller Interface ) was introduced by Intel in 2004, it did not change how the drive mechanically hunted for the data, but it did change how long it was allowed to do so.
Because an IDE drive performing this rigorous, multi-second back-and-forth routine would completely freeze the entire system bus, features like NCQ ( Native Command Queuing ) under AHCI allowed the drive to say, "I am struggling with this sector; let me pause, handle other data requests first, and I will keep trying to read it in the background".
So the drive probably already does it's own internal
equivalent of DynaStat, and SpinRite's DynaStat may
be redundant, and in a fragile drive, overkill,
literally, at the moment, maybe useful if the drive
ever settles down and stays online during DynaStat,
but not now.
LEVEL 2 DYNASTAT 0 NOREWRITE tells the drive to only
read.
Still, I've seen drives take on self-repairs on
non-data activity, and my worst example so far is a
drive that took 14 hours to scan end-to-end, but after
two weeks of repeated LEVEL 2 DYNASTAT 0 NOREWRITE,
the drive had self-'fixed' a lot of it's own internal
housekeeping, and then was able to finish a scan in
only 7 hours, so I was getting someplace with the
drive slowly becoming a data-playback machine once
more, and then ddrescue got most of the data I needed.
I discovered that the unrecoverable errors were in
non-data areas, Windows files, metadata, blank areas,
whew.
So keep at it, go slow, treat the drive with respect,
be patient, and don't force anything ( my intuition
is to throw LEVEL 5 at everything, and I need to
calm way down ! ).
BAD advice, Peter! The OP specifically said he wants the data. DynaStat 0 guarantees loss of data.
Hence my "gentler" approach to try to keep the drive happy.
The NoRewrite switch might be advisable as only fully recovered sectors would be rewritten. Then use a smaller transfer block size on any unrecovered sectors for hopefully more data recovery.
Recovery of all data may or may not be possible due to the nature / extent of the bad area(s).
Tells SpinRite not to ask the drive to rewrite any
sectors that were not read 100% accurately,
leaving them alone to try, try, try again later by
any means.
DYNASTAT 0
Do not keep retrying unreadable sectors, let the
drive do it's own recovery attempts, but move on
( because DYNASTAT 1 threw the drive offline ).
LEVEL 2
Read everything if possible, and recover in place
only sectors with errors that were 100% readable,
and considering the NOREWRITE command, do not
rewrite sectors that were not 100% accurately read.
SKIPVERIFY
Do not pretest the drive's read/write capability
on the last track since that has nothing to do
with recovering the unreadable data and is
therefore an unnecessary test at this point
NORAMTEST
Do not test the memory, which has already been
done, and which leaves SpinRite drive discovery
and enumeration in a compromised condition where
'ghost' copies of a single drive might appear,
and who knows what else might go wrong - @Steve
has seen it and has a fix in the queue and may
eventually release another version of SpinRite
with that and other fixes, too.
- - - - -
Our own @ColbyBouma has a nice but terse summary,
and even my explanations above are terse compared
to the many, many posts in the GRC development
environment on these issues and command lines, as
well as exhaustive field experience and testing:
I ran another default scan (no command line switches) at level 2 starting at 57%. Spinrite finished the rest of the drive. It found 2 more bad blocks, but did not stop/freeze. I started another level 2 scan starting at 56%, it's been running since last night and so far has not frozen up like when I started at 0%. it's gotten further at 56.5175% I'm going to let it run to see what happens. if it freezes up or the drive goes offline again, I'll try the updated advise.
Hello, good news! This last scan completed successfully. Spinrite dealt with ~575 bad sectors. It took a while... but it didn't freeze up this time! I ran another level 1 scan on the whole drive, and it also competed without any errors.
I put the drive in a Mac and was able to get a whole disk image captured.
in case it's of any value, I've attached copies of the Spinrite log.
Log 3 was the second scan after entire system froze up. at ~56%. Log 0, 1, and 2 are all 0k/empty.
Log 9 has the level 2 scan from 57.0000 to 100% and the final level 2 scan from 56% to 57%.
Log 10 was the followup level 1 scan.
For me, repeated DYNASTAT 0 NREWRITE caused my drive
to 'heal' - it took two weeks of repeats for maybe
1/2 of the errors to subside, each repeat causing
the drive to self-resolve more and more problems
without rewriting data, especially without rewriting
zeros where data could not be recovered, instead
moving on to try again on the next round.
Though a full:
SPINRITE NORAMTEST SKIPVERIFY LEVEL 2 DYNASTAT 0
... would also be appropriate, but would it throw
the drive offline or not?
Then maybe the drive will come back to full write/read
performance via:
Hopefully SpinRite 6.1 will be able to recover data on this drive.
