A Patch for a SpinRite v6.0 Overflow

  • SpinRite v6.1 Release #3
    Guest:
    The 3rd release of SpinRite v6.1 is published and may be obtained by all SpinRite v6.0 owners at the SpinRite v6.1 Pre-Release page. (SpinRite will shortly be officially updated to v6.1 so this page will be renamed.) The primary new feature, and the reason for this release, was the discovery of memory problems in some systems that were affecting SpinRite's operation. So SpinRite now incorporates a built-in test of the system's memory. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
    /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.)

Steve

(as in GRC)
Staff member
Feb 1, 2019
893
1,235
69
Southern CA, USA
www.grc.com
TL;DR: SpinRite 6.0 contains a recently discovered division instruction which will probably overflow when DynaStat engages on any drive larger than ~549 gigabytes. While this will never damage user data, it will halt SpinRite with a "Division Overflow" notice. A patch utility has been created (click that link) to correct this issue for v6.0 until v6.1 is available.

For those who do not follow my weekly Security Now! podcast, here is the text from my full explanation of how this was discovered and resolved with a temporary fix:

It turns out that my claim that SpinRite 6.0 has had no known bugs for the past 19 years has not been correct. Though I suppose it would depend a bit upon how you define “known”. Certainly it hasn’t had any “appreciated” bugs, but it definitely has had a bug. And thanks to the work of an independent coder named Paul Farrer, GRC is now offering a pair of patch utilities which fix this bug that SpinRite has had, perhaps since the mid 90’s with SpinRite 3.1.

Since it only occurs on drives larger than 549 gigabytes, when SpinRite’s DynaStat system kicks in to perform data recovery and repair, and since this behavior has been present since at least SpinRite 3.1, what is now seen as an overflow was very likely my deliberate design decision at the time, since drives of that size were not even a dream back when 50 megabytes was a large drive. So what likely happened was that as I evolved SpinRite through the decades, I never revisited the parameters surrounding this one division operation to notice that modern drives might cause it to overflow.

Through the years, we’ve had reports of SpinRite halting with a division overflow error. Somehow, I got it into my head that the location reported by SpinRite was the segment where the error was occurring, not the offset. So “B04E” would not be in program space. It’s in the region of memory that was once set aside for the monochrome display adapter. So I assumed that this error was occurring in a chunk of code that the system’s BIOS had mapped into that unused region. And this belief was supported by the fact that GRC’s tech support guy, Greg, has developed a collection of workarounds for SpinRite’s users who encounter this error, things like “Try running SpinRite with that drive on another machine” – which he says often works. In fact, over the weekend, when I wrote to him to tell him that we had a patch for this long standing problem he replied: “Since we are getting closer to 6.1, I'll probably use this as the last thing to try as all the other "fixes" we have in place are much less technical.” So my point is, this hasn’t been a big deal or issue for us. But I know for certain that it has been so for some users – and that’s not okay. I also now understand why moving to a different machine may have helped, since part of the issue surrounded the BIOS’s mapping of cylinders, heads and sectors to a drive’s linear sector number, and that mapping is one of the many things that different BIOSes might do differently.

In any event, Paul had just finished developing a different patch for those buggy AMI BIOSes which we discovered were blasting main memory when anything attempted to access sectors past 137 gigabytes on USB-connected drives. Out of an abundance of caution, which I feel is warranted, SpinRite v6.1 will refuse to go any further than the first 137 gigabytes on any USB drive. But Paul had access to our newsgroup which was full of people who had machines with these buggy AMI BIOSes. So working with them, he’s created a tiny utility that can be run before SpinRite. If it finds an AMI BIOS that it recognizes, he’ll patch it. And then, with my blessing – we’ve discussed how this should be done to be stable – his utility will remain in RAM and cause SpinRite 6.1 to believe that USB devices are SCSI devices, thus lifting 6.1’s cautionary clamp on USB drive size. So that little utility will be made available for users to use at their own risk if they choose. SpinRite 7 will not use any BIOS, so all of this will be going away as soon as we move there.

After doing that work, Paul became curious about that B04E error. Without my bias of assuming that this was the segment of the problem, and therefore in the BIOS and not in SpinRite, he assumed that I had been reporting the offset – as I was. So he looked into SpinRite’s running, in-memory code and sure enough, he found a division instruction at that offset in SpinRite. He then proceeded to reverse engineer that region of SpinRite’s code to figure out what was going on and why. At one point I provided him with the relevant chunk of SpinRite’s source code so that he could be sufficiently confident that he knew what was going on. He had it exactly right. Drives had become larger, and the math that I had not revisited for decades, which decomposed a linear sector number into cylinders, heads and sectors for the BIOS was no longer able to handle today’s larger drives.

So Paul has produced another patch utility which fixes this problem for SpinRite 6.0. He created both a DOS driver that can be loaded through CONFIG.SYS and a DOS TSR that can be run before running the current SpinRite 6. After testing it thoroughly he provided me with his source code to review, and it was immaculate. So, thanks to his efforts, we have a patch for this bug that’s always been in SpinRite since its very early days. Out of curiosity, I checked SpinRite’s source code for 5.0 dated February 11th, 1996 and it’s the same code that SpinRite 6.0 is still using. So I never changed it for SpinRite 6.0 since, at the time, it was not a bug. But it is today. Hitting this error, which can only occur on drives over 549 gigabytes – and only when DynaStat engages – does not endanger or damage any of a user’s data, but it does mean that SpinRite cannot proceed with its recovery and repair. So my advice to all SpinRite users listening would be to grab Paul’s patch and to add it to SpinRite’s boot media. The file is called MDFYSR60.ZIP (that's a direct link to the file) and it’s in GRC’s freeware collection. It’s also now referred to near the top of the SpinRite FAQ and it has a menu entry under GRC’s main menu under SpinRite and “Knowledgebase: B04E”.

As I was writing this up for today’s podcast I suddenly became curious about what the code for this looks like now, since we already know that SpinRite 6.1 doesn’t contain this bug. We’ve all been running lots of DynaStat recoveries on lots of multi-terabyte drives without any trouble. So I was pleased to see that I had completely replaced that old code with a new routine which is capable of handling a full 64-bits worth of sectors. That’s 18,446,744 terabytes... so, even though releases of SpinRite tend to live for a long time, we should be good for a while.

Since this bug is already long gone from SpinRite 6.1, since 6.1 is so vastly superior to 6.0, is nearly finished, will be free to all 6.0 owners, and since this is never destructive to any SpinRite user’s data, I plan to get 6.1 finished, rather than delay it in an attempt to announce this patch to v6.0’s current owners. After I put all this online Sunday night, I updated Greg so it’s what he’ll be pointing anyone to who encounters this problem to the patch. And when I do announce 6.1, I’ll also inform all 6.0 users of this patch so that they’ll have it for 6.0, even though it will largely become obsolete, as will 6.0. So, a big public thanks to Paul Farrer for his terrific work on this.

One final point: Something else I had forgotten from 19 years ago which recently came to light was that for some weeks after SpinRite’s initial public availability I was still finding and fixing some final bits of debris. And I was updating SpinRite’s downloadable code on the fly. I didn’t have the mature version-stamping system that all of my recent work carries, and which SpinRite 6.1 will, so all of those early editions just say 6.0 without any indication of any sub version or build number. Nothing has changed in 19 years. But if you believe that you may have downloaded SpinRite 6 within week’s of its first release in 2004, and never again since then, you might want to update your copy until 6.1 is ready.
 
Hi Steve, et.al. I tried to load the .sys version of the patch in config.sys and get an error - "MDFYSR60 installation failed - no free INT 60h-67h".
This is an older Acer laptop that has a drive issue which always triggers the B04E exception, so would really like to be able to use the patch!
 
Code:
MDFYSR60 V1.0

This program modifies SpinRite 6.0 to avoid the Divide Overflow Error at B04E
which may occur when SpinRite goes into DynaStat mode for drives over ~549 GB.

Install using ONE of the following methods:

-------------------------------- Method 1-------------------------------------
If SpinRite is on an original floppy or USB flash drive with only these files:
  CONFIG.SYS    *
  KERNEL.SYS    *
  SPINRITE.EXE
  SRSPLASH.SYS  *

* These have attributes Read-Only, Hidden, System

Download MDFYSR60.SYS and copy it to the SpinRite root directory
Remove the attributes on CONFIG.SYS so it can be edited

Add DEVICE=MDFYSR60.SYS to CONFIG.SYS

-------------------------------- Method 2-------------------------------------
If SpinRite is installed along with COMMAND.COM and AUTOEXEC.BAT

Download MDFYSR60.COM and copy it to the root or other directory

Add <OptionalPath>MDFYSR60.COM to AUTOEXEC.BAT
------------------------------------------------------------------------------

MDFYSR60 Messages:

MDFYSR60 V1.0  A modification for SpinRite 6.0 to prevent Division Overflow at B04E.
MDFYSR60 is now installed.
MDFYSR60 is already installed.
MDFYSR60 installation failed - no free INT 60h-67h.

really like to be able to use the patch

Based on Method 2 above (from the README) I recommend you use GRC's INITDISK utility, with the /FREEDOS command line option. This will make you a bootable USB that boots to FREEDOS. Once you verify that is working, copy the SPINRITE.EXE onto it along with the MDFYSR60.COM and edit the AUTOEXEC.BAT to invoke the MDFYSR60.COM and then launch SpinRite.
 
Yay! Glad to hear that this is fixed! I had first noticed and reported running into the B04E issue in 2006 (first email was on November 7, 2006), which means that I might've been among the earliest people to report it. Greg and I had some back and forth emails, but nothing he suggested could fix it. I eventually noticed over the years that it only happened on large drives, and only when bad sectors were found above around 500GB, so I figured it wasn't so much a bug but maybe a 512 GiB limitation thing. When I heard that v6.1 was going to be coming, I sent an email to support about this issue (on March 5, 2012), so that hopefully Steve could address it, and make sure that v6.1 worked properly with larger drives.

I've downloaded the patch, and will give it a shot with my trusty SpinRite flash drive.

Wow - it was 11 years ago that v6.1 was first being talked about. The best stuff is worth waiting for! SpinRite II was the first piece of software I ever purchased (back in 1989), and there's a good chance that v7.0 will be the last piece of software I ever purchase!

Ray
 
Code:
MDFYSR60 V1.0

This program modifies SpinRite 6.0 to avoid the Divide Overflow Error at B04E
which may occur when SpinRite goes into DynaStat mode for drives over ~549 GB.

Install using ONE of the following methods:

-------------------------------- Method 1-------------------------------------
If SpinRite is on an original floppy or USB flash drive with only these files:
  CONFIG.SYS    *
  KERNEL.SYS    *
  SPINRITE.EXE
  SRSPLASH.SYS  *

* These have attributes Read-Only, Hidden, System

Download MDFYSR60.SYS and copy it to the SpinRite root directory
Remove the attributes on CONFIG.SYS so it can be edited

Add DEVICE=MDFYSR60.SYS to CONFIG.SYS

-------------------------------- Method 2-------------------------------------
If SpinRite is installed along with COMMAND.COM and AUTOEXEC.BAT

Download MDFYSR60.COM and copy it to the root or other directory

Add <OptionalPath>MDFYSR60.COM to AUTOEXEC.BAT
------------------------------------------------------------------------------

MDFYSR60 Messages:

MDFYSR60 V1.0  A modification for SpinRite 6.0 to prevent Division Overflow at B04E.
MDFYSR60 is now installed.
MDFYSR60 is already installed.
MDFYSR60 installation failed - no free INT 60h-67h.



Based on Method 2 above (from the README) I recommend you use GRC's INITDISK utility, with the /FREEDOS command line option. This will make you a bootable USB that boots to FREEDOS. Once you verify that is working, copy the SPINRITE.EXE onto it along with the MDFYSR60.COM and edit the AUTOEXEC.BAT to invoke the MDFYSR60.COM and then launch SpinRite.
Hello,
I have to admit that I have limited experience with DOS command syntax. But I have been learning Linux and getting used to CLI.

Following the instructions above I am not able to get the patch to load. Here is the text from the autoexec.bat:
@echo off
cls
MDFYSR60
SPINRITE
I have tried changing the order of the patch and spinrite.
I have tried running the patch from DOS mannually.
I continue to get the "MDFYSR60 installation failed - no free INT 60h-67h" message.
Any guidance would be appreciated.
Thanks
 
I continue to get the "MDFYSR60 installation failed - no free INT 60h-67h" message.
Unfortunately this means your BIOS is doing something uncommon. It appears that it is "capturing" all the BIOS INT's that would otherwise be unused, and directing them to a "place holder" routine, presumably to prevent an otherwise random crash with poorly written software that calls INT's that are not in use/supported. The author of the patch (@Paul F, the other Paul here on the forums) will probably need to make a special version of his tool to account for this uncommon behaviour of your BIOS.
 
Is it possible to bypass this issue by removing the drive from the HP laptop and run in a different bios on another computer?
 
run in a different bios on another computer?
Possibly yes. You could certainly try your SpinRite boot device on the other PC before even moving the drive. If it boots successfully and you don't get the error message, then you could relocate the drive to it and give it a go.
 
Is it possible to bypass this issue by removing the drive from the HP laptop and run in a different bios on another computer?
I agree with Paul H's reply... This code received a great deal of testing by the gang in GRC's newsgroups and I'm not aware that anyone encountered this problem. So I would expect that any other machine should work!
 
So I would expect that any other machine should work!
True.

What's missing from this thread are two private conversations to troubleshoot this BIOS anomaly which do not belong in the blog. They both involve BIOSes that don't respect the interrupt vectors reserved for user programs, so MDFYSR60 thinks those interrupts are being used. One has been resolved, and I'm waiting for feedback on the second. The fix is relatively easy but needs to be done on an individual basis since one sample isn't enough to come up with a general solution.

If anyone else gets the message: "MDFYSR60 installation failed - no free INT 60h-67h" please start a conversation with me and we'll figure out how to get the patch to install.
 
I'm running SR 6.0 under the SR 6.1 boot environment and with MDFYSR60 patch, appears stable, and ran level 5 scans on 10 sony branded floppy disks using a USB floppy drive. 3 floppy disks had bad blocks and the rest tested fine. It's amazing that SR 6.0 still runs on modern hardware. Mind Blown.
 
I'm running SR 6.0 under the SR 6.1 boot environment and with MDFYSR60 patch, appears stable, and ran level 5 scans on 10 sony branded floppy disks using a USB floppy drive. 3 floppy disks had bad blocks and the rest tested fine. It's amazing that SR 6.0 still runs on modern hardware. Mind Blown.
MDFYSR60 only addresses ~549GB to 2.2TB drives that have errors causing DynaStat to engage. MDFYSR60 is unnecessary when running SpinRite 6 to test diskette drives. Steve Gibson suggests that SpinRite 5 is best for testing diskettes, and can be downloaded using the same license as SpinRite 6. In my experience, diskettes are 'married' to the drive that formatted them, and may not read and write well in another drive, so I reformat any diskette in the drive I plan to use with that diskette, and I now move the same diskette drive itself around from computer to computer along with it's diskettes, instead of expecting diskettes from one drive to read in another drive. I also have a head-cleaning diskette that has a cloth disk to which I apply some alcohol and then let it run in the diskette drive to clean the heads. I don't know of anyone who professionally cleans, demagnetizes, and aligns diskette drive heads, track 0, and timing anymore ( see https://www.google.com/search?q=how+to+align+a+diskette+drive ) , but I've seen new diskette drives arrive misaligned and in need of service, so we get what we get. Good luck.
 
I'm running SR 6.0 under the SR 6.1 boot environment and with MDFYSR60 patch, appears stable, and ran level 5 scans on 10 sony branded floppy disks using a USB floppy drive. 3 floppy disks had bad blocks and the rest tested fine. It's amazing that SR 6.0 still runs on modern hardware. Mind Blown.
If you can find a regular floppy drive, SpinRite 5.0 is even better at scanning floppies. I've had better success with SpinRite 5.0 and a very old laptop that has a built-in floppy drive than I have with a modern computer and a USB floppy drive. Here are the instructions from the FAQ for obtaining a copy:

I've read that SpinRite v6.0 owners can also get the previous SpinRite version 5.0. How do we do that?
transpixel.gif

All you need to do is change the filename in the software download URL from "spinrite.exe" to "sr5.exe". To do that . . .
transpixel.gif

textbullet.gif
Display a fresh copy of your SpinRite v6.0 receipt by entering your SpinRite v6.0 transaction code into our customer service page.
transpixel.gif

textbullet.gif
Instead of clicking on the page's software download link (which would download a copy of "spinrite.exe" and use up the link), RIGHT-CLICK on the link and select "Copy Shortcut" to copy the link to your Windows clipboard.
transpixel.gif

textbullet.gif
Next, RIGHT-CLICK in your browser's URL address line and select "Paste". This will paste the software download link into the address line without using it yet.
transpixel.gif

textbullet.gif
Finally, edit the end of the URL, changing it from "spinrite.exe" to "sr5.exe", then press "Enter" to use that edited URL and retrieve your own individually licensed copy of SpinRite v5.0.
 
SR 5.0 crashes on my PC and there is no socket to connect a regular floppy drive to. :(
 
SR 5.0 crashes on my PC and there is no socket to connect a regular floppy drive to. :(

Ahh, tell us MORE, ( always ) about what 'crashes' means to you in your situation - error messages, what screens work, where it stops or exits or locks up or does nothing or does something unexpected.

I'm especially curious about what CONFIG.SYS settings and DOS versions are required to get ONE environment that supports SpinRite 5, 6, 6,1, and other utilities all together in ONE diagnostic boot session on as many different computers as possible.

So anything MORE you can tell us really helps.

Thanks.



Yes, a 'regular' floppy diskette drive attaches directly to the main system board, not via USB.

So, I suppose, in hindsight, recommending SpinRite 5 for diskettes should be amended to:

diskette drives attached via FDC floppy disk controller,

not diskette drives attached via USB universal serial bus.​

Sorry, and thanks.

.
 
". . . True. What's missing from this thread are two private conversations to troubleshoot this BIOS anomaly which do not belong in the blog. They both involve BIOSes that don't respect the interrupt vectors reserved for user programs, so MDFYSR60 thinks those interrupts are being used. One has been resolved, and I'm waiting for feedback on the second. The fix is relatively easy but needs to be done on an individual basis since one sample isn't enough to come up with a general solution. If anyone else gets the message: "MDFYSR60 installation failed - no free INT 60h-67h" please start a conversation with me and we'll figure out how to get the patch to install . . ."

It would be great to evolve a continuously updated all-purpose self-iterative intelligent MDFYSR60 that works successfully on as many computers as possible, the goals being:

MDFYSR60 defaults to success in as many situations as possible, not failure,​
SpinRite 6 defaults to success, not failure.​
However, it may also be valuable to make sure MDFYSR60 clearly says in it's response screen:

MDFYSR60 is for ~526 GB to 2.2 TB drives to avoid DynaStat-induced failure to proceed,​
. . . so anyone working on smaller drives doesn't panic if MDFYSR60 fails to load or is not present.



I presume that once SpinRite 6.1 is satisfactorily released in final form, the only reasons to run and support SpinRite 6 anymore will be:

diagnostic comparison, as a tool to troubleshoot misbehavior experienced under SpinRite 6.1,​
USB diskette drives,​
though SpinRite 6 also works to test FDC-connected diskette drives too,​
SpinRite 5 may be best for FDC-connected diskette drives,
data recovery and drive maintenance on drives that require device drivers that SpinRite 6.1 cannot 'see'.​
Thanks.

.
 
I tried to use SR 5.0 under the SR 6.1 boot environment. Maybe I could try to use SR 5.0 under it's own boot environment. However it probably DOES NOT like the modern BIOS on this PC.
 
". . . I tried to use SR 5.0 under the SR 6.1 boot environment. Maybe I could try to use SR 5.0 under it's own boot environment. However it probably DOES NOT like the modern BIOS on this PC . . ."

SpinRite 5 does not have it's own boot environment, does it?

ALL SpinRites work for me together, that is, at least LOAD, for me, in the same environment, well, SpinRite 2 II, SpinFAQ, 3,1, 4, 5, 6, and 6.1, all on the same boot diskette or USB boot drive, even if they don't 'see' modern drives and attachments beyond their original expectations.

1699646704815.png


So there must be MORE in your case.

Again, tell us MORE, ( always ) about what 'crashes' means to you in your situation - error messages, what screens work, where it stops or exits or locks up or does nothing or does something unexpected.

I'm especially curious about what CONFIG.SYS settings and DOS versions are required to get ONE environment that supports SpinRite 5, 6, 6,1, and other utilities all together in ONE diagnostic boot session on as many different computers as possible.

So anything MORE you can tell us really helps.

Thanks.

.
 
True.

What's missing from this thread are two private conversations to troubleshoot this BIOS anomaly which do not belong in the blog. They both involve BIOSes that don't respect the interrupt vectors reserved for user programs, so MDFYSR60 thinks those interrupts are being used. One has been resolved, and I'm waiting for feedback on the second. The fix is relatively easy but needs to be done on an individual basis since one sample isn't enough to come up with a general solution.

If anyone else gets the message: "MDFYSR60 installation failed - no free INT 60h-67h" please start a conversation with me and we'll figure out how to get the patch to install.
I am having the same error message on a 2013 Lenovo Ideapad Y500. I'd be interested to hear if there's a way to fix it!