Closed Pre-Release 5.07

[Steve]

5.07: Many Additional Fixes & Improvements.​

UPDATED NOTE: The lifting of SpinRite's 137GB access clamp by this 5.07 release has revealed the existence of many additional unsuspected BIOS bugs. The next (5.08) release will adopt a new proactive bug detection strategy that will (if it can be done) give us a robust solution where SpinRite will only clamp USB drives to 137GB when it's required.

The biggest new feature of this 5.07 pre-release is its management of the AMI BIOS USB-access bug(s).

The full list of fixes and improvements:

• Added "NoReWrite" command-line option to inhibit SpinRite repair/rewriting of incompletely recovered sectors.
• Updated command-line summary and FAQ with the two latest commands.
• Fixed blanking window's top line of screen.
• DynaStat now accepts either mm or mm:ss format for timeouts.
• AMI BIOS: SpinRite is "AMI aware", able to run unencumbered on non-AMI BIOS and able to patch buggy AMI BIOSes when found.
• Reworked BIOS error recovery to avoid explicit drive status querying since that hard-hangs HP BIOS.
• Fixed an data transfer incompatibility with old NVIDIA chipset (IDE drives).
• Fixed “order dependency” of the command-line sequence “diags graphic” -vs- “graphic diags” and also allows “graphics” to be used as
  well since that seems more natural.
• Fixed *.LOG and *.DBG numbering mismatch. Now, the highest number of ANY numeric-only file will be found and ALL logging files of any sort will be given the next higher numbering.
• Production BIOS code contains debugging breakpoints which SpinRite had been intercepting. It no longer does so they will be treated as simple no-ops (as if SpinRite was not in the machine).

As always, you may obtain this update by going to GRC's Pre-Release page, entering your SpinRite license serial number or transaction code and clicking the links to obtain your personal pre-release copies of either the full Windows/DOS SpinRite and/or just the DOS code.

(VirusTotal is slightly less happy with this iteration with 1/65 detections.)

Thanks, all!

 

[eef321]

Steve, apparently VirusTotal resolved the issue where one engine flagged the 5.07 release. I am scanning for a friend with a 15 year old Dell Laptop so expected 1/65 but (attached) had 0/65. You are GOLDEN! Thought I would let you know! Bet that vendor fixed whatever was flagging SpinRite.

Thank you also for SecurityNow, I get lots of CPE Credits for listening, I am not aware of missing one episode!

Darian Stultz
dstultz@pm.me

No response needed! Keep up your good work, and hopefully keep Leo in line!

 

[Jacob Glass]

Dear Steve,

I'm a longtime Security Now! listener and when a colleague had hard drive trouble I thought it would be a great chance to give SpinRite a whirl.

So I plugged the Hitachi Travelstar Z7K500-320 (320Gb, 7200rpm) into my trusty Sabrent USB enclosure, connected that to my creaky ThinkPad X1 carbon first gen laptop and ran SpinRite 6.0. Following the MBR/EFI warning and B04E error, I promptly downloaded 6.1 (5.07).

On initial setup, 6.1 seemed to fare better - particularly in recognizing the drive and drive size, but when I ran a level 2 scan on the drive, it seemed to hang after a few seconds. Undaunted, I let it go (little blue light blinking away) and two black ascii squares appeared in the center of the screen, the second with a 0 in it (see attached). After letting this be for a few hours, I finally forced a reboot and tried again on level 3 then level 5 with the same results.

I'm curious if this is a known issue. Perhaps this is due to the 'self encrypting drive' feature? Or perhaps something about the bios or USB enclosure? Happy to try out different configurations to figure this out.

The data on the drive is not critical, and the partition setup I believe is EFI / data / windows recovery partition.

Thank you in advance,

Jacob

 

[Steve]

Hi Jacob! (@Jacob Glass):

I JUST updated the anchor posting of this thread with my plan for the next release (5.08).

After 5.07 released the 137GB clamp that SpinRite 6.1 has always previously applied, new and previously unsuspected BIOS bugs (such as the one in your ThinkPad X1 Carbon 1st-gen laptop (nice machine, by the way. I had one)) began crawling out of the woodwork and crashing SpinRite when they were overwriting main memory. I have a plan to fix this by proactively protecting SpinRite from these bugs.

But that won't help you with that laptop because it will always have a buggy BIOS. Until we get to SpinRite 7, which will be using its own USB drivers, SpinRite will refuse to go past 137GB on any USB-attached drive with a buggy BIOS.

So, your best bet would be run the current SpinRite 5.07 on another (newer) machine with that USB drive. Or, if you have any earlier (recent) pre-release of SpinRite before 5.07 it WILL run safely on (only) the first 137GB of that drive on your ThinkPad... and THAT might be sufficient to get that drive running better!

 

[Jacob Glass]

Thank you so much for the quick reply (and I'll admit I'm a little star struck)!

I will try it on a newer machine and get back to you. I imagine putting the drive into a desktop with an adapter would likely get around this issue? I'll order one and give that a whirl as well.

 

[ColbyBouma]

I imagine putting the drive into a desktop with an adapter would likely get around this issue? I'll order one and give that a whirl as well.

You shouldn't need an adapter, that's a SATA drive.

SATA will always be better than USB in SpinRite 6.1.

 

[Jacob Glass]

Apologies - I should have clarified. I was worried that the desktop was IDE given my penchant for reviving vintage hardware. Thankfully the venerable HP Pavilion 500-267c is a SATA setup, so I popped the drive in and am now happily running SpinRite 6.1 (5.07) on it at level 2. So far one recovered sector and 10 marked unrecovered in the first 13.6% (estimate from the graphical display). Most of the bad ones seem to be at the very beginning... hopefully in the EFI partition?

Fingers crossed that I can get the data off of it when this is done!

 

[Jacob Glass]

It worked!

After running SpinRite 6.1 (5.07) using a direct SATA connection, I was able to see the drive under ubuntu but not mount it. I took it out, put it back in the USB enclosure and connected it back to the old ThinkPad and was able to see the drive as well, but it wouldn't mount. So, I ran `chkdsk d: /f` in an Admin PowerShell terminal, and was able to fix a bunch of NTFS errors. After that finished, I was able to see all the files and folders! I copied out the 3.5G of important files for my colleague and sent them over. That old desktop has just become my official SpinRite rig! As a new user I'm curious if there is a better workflow. Presumably operating on the cloned disk image would have been better, but I guess this works too given that I have the image stored.

Thank you for a fantastic piece of work. I have enjoyed reading the manuals thoroughly and look forward to future releases. I'm of course curious how you went about doing statistical analysis in assembler .

If any of the logs would be helpful, please let me know.

 

[ColbyBouma]

If any of the logs would be helpful, please let me know.

I would love to have your logs

GRC Community / SpinRite Logs · GitLab

A community collection of logs from SpinRite. https://www.grc.com/sr/spinrite.htm

gitlab.com