Help, anyone? Downloaded spinrite v 6.1 beta RC 2 Tuesday, booted to DOS, ran SR. All went well until I wanted to start the scan, nothing happens when I push 'Enter'. See the attached screenshots at this link https://photos.app.goo.gl/95MNZevLUwWpEReb8 I tried a second keyboard with the same result. Please advise, am I doing something wrong?
-
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.)
Other people have encountered that as well. Steve is looking into it.
Thank you Colby. I'm glad Steve is aware of the issue, we are anxious to start scanning our larger drives! Tried your link, get a GitLab sign in page. I don't have an account so I clicked "Register Now" and then I get a sign in popup. No way to sign in since I'm not registered and seemingly nowhere to register? I'm using Chrome (my preferred browser is FF)...do I need to install the newsreader to get access to the GitLab forums? (And sorry, I know this is not a Gitlab forum! Just hoping the answer is simple.)
The procedure to enter dev.grc.com is non-obvious. Steve configured it that way to try to keep trolls and spammers out. I can't directly share the answer, but you're close.
FWIW I think the problem came forward from vers 6.0, SR 6.0 always had problems with my Dell desktops and usb keyboards. Slightly different, the older version seemed to gradually 'lose' the keyboard, if I kept keystrokes to a minimum I might get through a scan. Too many keystrokes and it would stop responding. I ended up giving up and using different laptops (not dells) with an external dock. Not ideal. (Back to registering for Steve's Gitlab forum, I remember him saying something about that on SN...). Thank you for your help.
a quick hack is to press shift key (and release) and then push enter again (try both shift keys if that does not work). The reason you're stuck is probably because the shift key is constantly enabled (we don't know why yet. On my system it only have happend twice so far(random))
This behavior has been referred to as "BIOS Contention". When the BIOS is busy handling SpinRite's data I/O during a scan, it has no time to service other interrupts, such as keyboard interrupts. Hence the keyboard becomes unresponsive. This is a long standing issue with SR 6.0 that SR 6.1 does NOT have when scanning internal drives with its native drivers.
Yes! The reported problem WAS with a Dell machine. I've added the "keyboard" command-line option in RC2, which might help.
Could you give me the make/model of the Dell desktop you have that's causing the trouble? I would LOVE to be able to reliably recreate the trouble so that I'm sure of any fix for it. Thanks!!
Sure, happy to help. It is a Dell Optiplex 9020, 16GB ram, i5-4690 CPU @3.5 GHz. Tried two KB's; Logitech MK300 (wireless) & a generic Dell plug in USB keyboard, neither worked the first time. I was successful with the RIGHT shift key hack using the Logictech KB. Let me know if you need any other specs.
Hi Dan, it has been a while since I ran the old version on a Dell but I'm pretty sure I had the KB problem after the scan was complete. FWIW I would start the scan & go away then come back some time later to the screen blanker jumping around. The first few keystrokes took but then it became unresponsive. If v6.1 fixes it then it's a moot point anyway. Cheers.
Last edited:
Steve posted on the newsgroup that the latest code was reverted to using the BIOS to read the keyboard, so presumably all these weird keyboard issues will now go away [again].
Spinrite 6.1 RC#3 - Downloaded as a Registered 6.0 user
I am experiencing this Enter key issue on v6.1 RC3 as a semi random problem.
Using 4 different desktop computers
- all ASUS motherboards with AMI BIOS (UEFI versions - 3 early and 1 recent)
- 3 are older Intel (i5 Gen 2/3) and one is a newer AMD AM4 (Ryzen 5 5600G)
- all with Microsoft keyboards (PS2 and USB)
Problem seems worse (more frequent) with MKEYB UK loaded - but also occurs without driver loaded.
All is OK until attempting to confirm "Select Drive for Operation"
I am able to Select the drive (it is ticked) then you press Enter - no response (Return or Enter ignored)
Only the "Press Enter to begin Spinrite operations" stops working - the Enter key continues to work in all other screens
** Workaround Update:
When the Enter key fails to "Start Spinrite Operation" on the selected drive
- press both Shift keys simultaneously and release, then press Enter
For me this works to reverse the Enter key failure with no fails so far (10 plus occasions)
This workaround also works at the DOS prompt - ie reverses the Shift-Lock as detailed below
------------------------------------------------
Once the Enter key issue is triggered and the above workaround has not been used:
- when you exit Spinrite (to the DOS prompt) the keyboard acts as if a Shift-Lock has been activated.
The main keyboard is ALL Shifted to the upper characters (upper-case letters AND top row is no longer numbers)
- none of the keyboard controls reverse this Shift-Lock (Caps-Lock or individual Shift keys have no effect)
- loading or reloading Keyboard driver (MKEYB UK) has no effect
- reloading COMMAND.COM has no effect
The Numeric Keypad has the Num-Lock action inverted
- numeric keypad produces numbers when Num-Lock is OFF
- numeric keypad produces arrow keys, End, Home etc when Num-Lock is ON
Keyboard problem only occurs after Spinrite 6.1 has been used (never just working at the DOS prompt)
Appears to be something set by the Spinrite program (maybe as part of disabling the Numeric Keypad)
Workaround: at the DOS prompt press both Shift keys together - toggles Shift-Lock to OFF - keyboard reverts back to normal
I am experiencing this Enter key issue on v6.1 RC3 as a semi random problem.
Using 4 different desktop computers
- all ASUS motherboards with AMI BIOS (UEFI versions - 3 early and 1 recent)
- 3 are older Intel (i5 Gen 2/3) and one is a newer AMD AM4 (Ryzen 5 5600G)
- all with Microsoft keyboards (PS2 and USB)
Problem seems worse (more frequent) with MKEYB UK loaded - but also occurs without driver loaded.
All is OK until attempting to confirm "Select Drive for Operation"
I am able to Select the drive (it is ticked) then you press Enter - no response (Return or Enter ignored)
Only the "Press Enter to begin Spinrite operations" stops working - the Enter key continues to work in all other screens
** Workaround Update:
When the Enter key fails to "Start Spinrite Operation" on the selected drive
- press both Shift keys simultaneously and release, then press Enter
For me this works to reverse the Enter key failure with no fails so far (10 plus occasions)
This workaround also works at the DOS prompt - ie reverses the Shift-Lock as detailed below
------------------------------------------------
Once the Enter key issue is triggered and the above workaround has not been used:
- when you exit Spinrite (to the DOS prompt) the keyboard acts as if a Shift-Lock has been activated.
The main keyboard is ALL Shifted to the upper characters (upper-case letters AND top row is no longer numbers)
- none of the keyboard controls reverse this Shift-Lock (Caps-Lock or individual Shift keys have no effect)
- loading or reloading Keyboard driver (MKEYB UK) has no effect
- reloading COMMAND.COM has no effect
The Numeric Keypad has the Num-Lock action inverted
- numeric keypad produces numbers when Num-Lock is OFF
- numeric keypad produces arrow keys, End, Home etc when Num-Lock is ON
Keyboard problem only occurs after Spinrite 6.1 has been used (never just working at the DOS prompt)
Appears to be something set by the Spinrite program (maybe as part of disabling the Numeric Keypad)
Workaround: at the DOS prompt press both Shift keys together - toggles Shift-Lock to OFF - keyboard reverts back to normal
Last edited:
@DougCuk:
VERY nice diagnostics work, Doug. Thanks... and yes.
The trouble is that the shift states are getting messed up (stuck down). This is why tapping the left or right SHIFT key (press and release) serves to clear a "stuck down" state. SpinRite had always taken over responsibility for the keyboard from the BIOS and all had been working well for months (or years). But as we neared finality, incompatibility with some Dell systems was discovered... and I had long been bothered that having SpinRite takeover the keyboard meant that systems which do not fully emulate the PC (Apple's Intel Macs) would not be compatible.
So, late in the game I switched back to using the BIOS and things have been a bit unsettled ever since. There are also incompatibilities with using Shift+Enter. So I switched to Ctrl+Enter — but there was problems with that, too.
So the next release (I'll be working on this today) will be abandoning all use of any "Shifting" and we'll be switching to using the TAB key as the alternate option. THAT should finally give us universal keyboard compatibility, including for Intel Macs.
I'll post the news in a banner here once the next release candidate is available!
Thanks again!
VERY nice diagnostics work, Doug. Thanks... and yes.
The trouble is that the shift states are getting messed up (stuck down). This is why tapping the left or right SHIFT key (press and release) serves to clear a "stuck down" state. SpinRite had always taken over responsibility for the keyboard from the BIOS and all had been working well for months (or years). But as we neared finality, incompatibility with some Dell systems was discovered... and I had long been bothered that having SpinRite takeover the keyboard meant that systems which do not fully emulate the PC (Apple's Intel Macs) would not be compatible.
So, late in the game I switched back to using the BIOS and things have been a bit unsettled ever since. There are also incompatibilities with using Shift+Enter. So I switched to Ctrl+Enter — but there was problems with that, too.
So the next release (I'll be working on this today) will be abandoning all use of any "Shifting" and we'll be switching to using the TAB key as the alternate option. THAT should finally give us universal keyboard compatibility, including for Intel Macs.
I'll post the news in a banner here once the next release candidate is available!
Thanks again!
I can confirm that RC#4 has eliminated the "Enter key bug".
Tested on 3 different desktops that previously showed the issue - I can no longer trigger the problem!
Currently running Level 2 scans on a random selection of drives - several 1TB SATA (AHCI) and a Kingston 256GB NVMe (BIOS) - all working fine.
Discovered I had a "Shingled Magnetic" 1TB Toshiba when I tried to run a Level 3 scan on it - and was advised that was not a good idea
- and had to do a quick Google to remind myself as to what a Shingled drive was.
Also created a new USB Boot drive using WinSpin-R5 - and edited startup to allow running alternate Spinrite versions (eg RC#4)
Noted that with WinSpin you only get the bare essential FreeDOS files - I transferred the FreeDOS folder from ReadSpeed to keep me happy.
Takes me back to the old days creating Network boot floppies with loads of tweaking of the Config.sys and Autoexec.bat contents - happy days!
Tested on 3 different desktops that previously showed the issue - I can no longer trigger the problem!
Currently running Level 2 scans on a random selection of drives - several 1TB SATA (AHCI) and a Kingston 256GB NVMe (BIOS) - all working fine.
Discovered I had a "Shingled Magnetic" 1TB Toshiba when I tried to run a Level 3 scan on it - and was advised that was not a good idea
- and had to do a quick Google to remind myself as to what a Shingled drive was.
Also created a new USB Boot drive using WinSpin-R5 - and edited startup to allow running alternate Spinrite versions (eg RC#4)
Noted that with WinSpin you only get the bare essential FreeDOS files - I transferred the FreeDOS folder from ReadSpeed to keep me happy.
Takes me back to the old days creating Network boot floppies with loads of tweaking of the Config.sys and Autoexec.bat contents - happy days!
Yes. We were just discussing this over in the grc.spinrite.dev NNTP newsgroup. Once the dust settles we'll be assembling a "FreeDOS Utilities" archive that can be added to any of the FreeDOS offerings to load it up with a bunch of useful goodies.
Similar threads
- Contains 2 staff post(s)
