Closed Release Candidate 6

[Steve]

Proposed Final SpinRite v6.1 (RC6)​

No 3-year project as large as this one finishes with a clean sharp edge — and this labor of love certainly hasn't. But we've finally moved past our recent (and important) flurry of 5.x pre-releases, to Release Candidate 6, because I believe there is nothing remaining to resolve. SpinRite v6.1 appears to be ready for release.

Since I still think it makes sense to let any new code “rest” for a bit, this RC6 is labeled as such with a 93 day expiration. I'll now be working to get ready for the non-RC release, getting the web-based documentation updated and pulling the 6.0 owner mailing list together in preparation of letting all v6.0 owners know that their free upgrade to v6.1 is finally ready and waiting for them (once it is).

After a few weeks, assuming that no showstoppers arise (and if some do we'll deal with them), I'll move this to final 6.1 code and we'll really be finished with this first step toward SpinRite's future.

THANK YOU EVERYONE for your continued testing and feedback. It has been truly instrumental in shaping this final result, which we will all be living with while I work toward SpinRite's rebirth under its own operating system with all native drivers, UEFI compatibility and very much more!

You may obtain this update, as before, by going to GRC's Pre-Release page, entering your SpinRite license serial number or transaction code and clicking the link to obtain your personal copy.

Thanks, all!

 

[markav2]

@Steve Thank you for the work you put into SpinRite and the podcast. I have been a listener since the first episode. I believe someone on Buzz out loud mentioned the first episode and I was a very avid listener to the CNET show. That's back when you had to manage downloading and transferring your podcasts manually, how things have changed.

 

[pcprof]

I've been a user of Spinrite since Spinrite II. Love it! In checking out the RC6, I see that it doesn't seem to play well with Yumi or Ventoy (These are USB multi-boot platforms) If I load it via "MEMORY" option (it won't work with other options), I get the Spinrite 6.1 Splash logo, but then it hangs on a blank black screen with a blinking cursor. (Works perfectly fine if I just boot directly off your Boot USB, but I hate carrying around so many USBs)

 

[Steve]

@pcprof : Yes. This is a known problem with 6.1 and it's a remaining open issue in GRC's GitLab instance.
Since I'm not a user of Ventoy, I need to familiarize myself with it... then I'll figure out why SpinRite 6.0 works with it whereas 6.1 does not!

 

[pthubbard]

I've been a user of Spinrite since Spinrite II. Love it! In checking out the RC6, I see that it doesn't seem to play well with Yumi or Ventoy (These are USB multi-boot platforms) If I load it via "MEMORY" option (it won't work with other options), I get the Spinrite 6.1 Splash logo, but then it hangs on a blank black screen with a blinking cursor. (Works perfectly fine if I just boot directly off your Boot USB, but I hate carrying around so many USBs)

I have been using RC6 with Yumi by loading SR as an unlisted ISO with GRUB. Seems to work fine but I haven't tested it thoroughly.

 

[LSI11-23]

Hello Steve,
This morning I downloaded a fresh copy of SR6.1PR from GRC and installed it via the create USB boot media option. I am running a Zimaboard booting from the USB drive I just made. After the press any key to continue screens I received this error.

"SOMETHING IMPOSSIBLE JUST HAPPENED" GRC impossible situation 1 just happened to you.

No other codes on the screen were observed, however there was a millisecond of another screen that I was not able to capture prior to the impossible screen displaying.
The target drive connected is a known SSD with errors ( INLAND PROFESSIONAL P/N: 1TBM). The below error only shows up if the drive is connected before power power up/ boot up. Spinrite starts up fine if the drive is connected after Spinrite starts, the drive is not detect though.

 

[davs2rt]

New user trying to recover a Tivo disk that the Tivo said was bad: WD Blue 3tb did not show up at all in the drive search in 6.0 and Feb 2 download of 6.1. I'd moved the SATA to a USB interface to plug it into various computers trying to evade UEFI issues. The drive didn't show up under Linux or Windows scans either, so I'm assuming the interface is just dead dead. Just a report, no help needed. Tivo is busy refilling Simpsons reruns on new drive now.

 

[Steve]

@LSI11-23 : (Nice handle, by the way! -- DEC's PDP-11 had one of the nicest and cleanest CISC instruction sets ever conceived. It was designed by programmers for programmers. : )

Hmm... So, not as impossible as I was hoping! <g>

The code in question is shown above. As the instruction comments explain, the "Impossible Event" (which I suppose I should rename to "very undesirable event" is a "sanity test" to make sure that SpinRite's division of a linear sector number by the sectors per track, to obtain the sector on the track (in the division's remainder) and the track number (in the division's result) will not "overflow" and cause a division by zero.

The only reason it might overflow is that the "track number" would not fit within a 32-bit result, which can probably only occur if "sectors per track" is extremely low, or zero... which is probably the case.

Hmmmmm. Since you're doing this on a ZimaBoard, we know a LOT about the system. It's as solid and modern as any. And it's been extensively tested by me and many other SpinRite testers since its discovery. So that's not the trouble.

Due to limitations of the BIOS, it is DEFINITELY necessary to have ALL drives connected to the system when it is first booted and then SpinRite is run. So it must be that the drive's "identify" information contains data that doesn't make any sense... and that SpinRite's code currently believes what the drive is telling it without protecting itself from erroneous information be performing a "sanity check".

Is THIS the drive? https://www.amazon.com/dp/B07FM9SSP6. Assuming that it is, I'll grab one to see whether I can reproduce the trouble and come up with a solid solution.

Thanks!!

 

[Steve]

The drive didn't show up under Linux or Windows scans either, so I'm assuming the interface is just dead dead. Just a report, no help needed.

The fact that the drive isn't visible anywhere does suggest that it has died hard.

 

[LSI11-23]

@LSI11-23 : (Nice handle, by the way! -- DEC's PDP-11 had one of the nicest and cleanest CISC instruction sets ever conceived. It was designed by programmers for programmers. : )

Hmm... So, not as impossible as I was hoping! <g>

View attachment 1039

The code in question is shown above. As the instruction comments explain, the "Impossible Event" (which I suppose I should rename to "very undesirable event" is a "sanity test" to make sure that SpinRite's division of a linear sector number by the sectors per track, to obtain the sector on the track (in the division's remainder) and the track number (in the division's result) will not "overflow" and cause a division by zero.

The only reason it might overflow is that the "track number" would not fit within a 32-bit result, which can probably only occur if "sectors per track" is extremely low, or zero... which is probably the case.

Hmmmmm. Since you're doing this on a ZimaBoard, we know a LOT about the system. It's as solid and modern as any. And it's been extensively tested by me and many other SpinRite testers since its discovery. So that's not the trouble.

Due to limitations of the BIOS, it is DEFINITELY necessary to have ALL drives connected to the system when it is first booted and then SpinRite is run. So it must be that the drive's "identify" information contains data that doesn't make any sense... and that SpinRite's code currently believes what the drive is telling it without protecting itself from erroneous information be performing a "sanity check".

Is THIS the drive? https://www.amazon.com/dp/B07FM9SSP6. Assuming that it is, I'll grab one to see whether I can reproduce the trouble and come up with a solid solution.

Thanks!!

Hi Steve,

Yes that is the exact drive ( I purchased mine from microcenter), a new one may not provide the exact error since the drive I have has errors and has failed a few times as a windows boot drive. The ssd drive drive may be so bad its is causing a fault as soon as it is detected..

Glad you enjoy my handle, that was one of the first computers I was trained on fresh out of high school while I was in the US Navy working as a mainframe technician.

Thank you,
Pat

 

[Steve]

Hey Pat,

Yes that is the exact drive ( I purchased mine from microcenter), a new one may not provide the exact error since the drive I have has errors and has failed a few times as a windows boot drive. The ssd drive drive may be so bad its is causing a fault as soon as it is detected..

The nature of the failure makes me think that it's about the way it's identifying itself to the system rather than anything to do with the drive's data access. Although we have a nearby Micro Center, and I saw it was the Micro Center house brand, I decided to have Amazon send that drive, hoping that you would say that it was the one. It arrives tomorrow and I'll plug it into my ZimaBoard and hope that "Something Impossible" happens again!! I'll let you know what I find! Thanks!

 

[dg1261]

I have been using RC6 with Yumi by loading SR as an unlisted ISO with GRUB. Seems to work fine but I haven't tested it thoroughly.

Thanks, @pthubbard! Like @pcprof, it didn't work with Ventoy for me, but your method seems to work just fine with Yumi. I've tried RC6 launched from Yumi on about a half dozen spinners and SSDs now, and haven't encountered any glitches.

 

[Steve]

UPDATE/REVERSAL/CORRECTION: SpinRite v6.1 will NOT be compatible with Ventoy. Please see THIS posting (below) for more.

Guys: Just an update that I spent some time yesterday with Ventoy, and the next released build of SRv6.1 will run with Ventoy “out of the box” without trouble.

It appears that the problem is that the DOS boot environment (with memdisk) that's created by Ventoy doesn't support the "HMA" (high memory area) where DOS normally tucks itself to conserve lower conventional memory. This forces DOS into lower memory and just barely doesn't leave sufficient low memory to run SR6.1. The "DOS only" version runs fine. Even the full Windows+DOS version runs if I don't digitally sign it -- since the size of the appended digital signature is just enough to push the size over the limit.

Once I have this week's podcast behind me, I plan to modify SpinRite for Windows so that the ISO it builds will only contain the DOS version of SpinRite rather than the full copy of the Windows+DOS. Since the DOS EXE is all that's needed, everything should work well.

 

[Steve]

@LSI11-23 : Unfortunately — my identical 1TB Inland Pro drive works perfectly with SpinRite. :-(

I may need to add a feature to SpinRite to capture and display data to explain what's going on... but could you first try running SpinRite on a system with that drive and adding the command-line option "diags"? SpinRite is going to display the "Something impossible" message, we know that... But before it does it MIGHT dump something useful into the .DBG file in the SRLOGS subdirectory. So... If running SpinRite with the “diags” option does product a .DBG file in the SRLOGS subdirectory could you share it?

Thanks!!

 

[fabriceroux]

Bonjour,

I ran into an issue on the Windows media creation application side. I'm using Windows 11 23H2 with the January cumulative patch and 2 monitors. The app behaves normally when the main window is on the main screen.

But as soon as I move the main window on the secondary screen (placed on the left side of main one), the 3 main buttons have the same behavior. The clicking noise is played and the main window disappears. But the next window (USB, ISO or diskette creation) is nowhere to be found.

I thought I had an account here from the SQRL days. I don't have access to the gitlab to check if this issue is know. So I recreated an account using my SQRL ID.

Best regards,
--
Fabrice Roux from southern France

 

[Steve]

Nice to see you back, Fabrice. (@fabriceroux):

This has not been reported before. All of my workspaces are multi-monitor, and I haven't seen this myself, nor has it been reported. But I'll create a GitLab issue to remind me to follow-up on it in the next day or two. I did address the behavior of the parent and child windows for ValiDrive, and I used the same code base for it. I'll also send you the info to join our GitLab in case you're interested in tracking and verifying. Thanks!

 

[Steve]

UPDATE: I immediately recreated this, Fabrice! Thanks!! I'll get it fixed in the next update.

 

[lancem631]

According to the Spinrite 6.1 Windows/Dos version it seems I should be able to use a bootable CD however I am confused about dealing with SRLOGS not being able to write to a subdirectory. Seems like a catch-22 having ability to boot from CD but cannot use because of need for SRLOGS to be written.

• Users with a CD-R (CD recordable) drive can create a standard ISO file which can then be used to "burn" a CD to automatically boot FreeDOS and run SpinRite
• Or an IMG image file of a 144 megabyte diskette can be created for later recording to a diskette on another system.

(Useful if this system does not have a diskette dive).

• A system booted from the CD or diskette created from these files will load the FreeDOS operating system then automatically start SpinRite running on the system.

 

[Steve]

According to the Spinrite 6.1 Windows/Dos version it seems I should be able to use a bootable CD however I am confused about dealing with SRLOGS not being able to write to a subdirectory. Seems like a catch-22 having ability to boot from CD but cannot use because of need for SRLOGS to be written.

You're right, Lance. It IS a Catch-22. This ISO-creation capability is mostly a hangover from the original release of SpinRite 6.0 in 2004, back when many systems would not boot from a USB thumb drive... but everything could boot from a CD. And most systems back then were still equipped with diskette drives and all could boot from diskette.

Today, 20 years later, the recommended way to run SpinRite is from USB since all machines can do that and since that creates a writeable environment that can accept and retain SpinRite logs.

Despite the fact that writing an IMG for diskette or writing an ISO for CD no longer really makes sense, since those capabilities were already present in SpinRite 6.0, I decided to leave them there in 6.1.

You raise a great point about the built-in documentation in 6.1... I'll update that! Thanks!!

 

[Steve]

REVERSAL: SpinRite v6.1 will NOT be able to support Ventoy. (But Checkout Easy2Boot!!)

After two days of research, I've determined the cause of the conflict between Ventoy and SRv6.1: Ventoy's A: drive emulation is fundamentally incompatible with SpinRite 6.1's "flat real mode" use of 32-bit addressing.

I explored workarounds for this and concluded that arranging to allow SpinRite's ISOs to be "Ventoy compatible" would create an unacceptably big mess for everyone else. There would be too many "gotchas" that could trip-up other situations. Also, frankly, the "read-only" nature of any ISO emulation is not ideal for SpinRite, since it never allows SpinRite's log files to be saved. Simply booting from its own USB drive is a far superior solution for SpinRite.

During this work (thanks to a posting by "Jason" in GRC's newsgroups) I learned of “Easy2Boot” which is a rather incredible superset of Ventoy... and SpinRite's ISO's are completely compatible with Easy2Boot. So, if you really want to carry around a single bootable USB stick which can also boot SpinRite from an ISO, Easy2Boot will do that and VERY MUCH MORE!

(If you're curious, this posting, which I made to GRC's newsgroups, has more to say about the Ventoy mess.)