Posted by: Ed Tittel
SpinRite v6.0 must use IDE mode BIOS to work properly, Windows 7 install encounters interesting issues with FAT-16 UFD
Among the many elements in my diagnostic and repair toolkit, I have a licensed copy of Steve Gibson’s SpinRite v6.0, purchased in 2006 (I still have a copy of the receipt in my email archives, and I’m glad I did for reasons I’ll elaborate upon later). I’ve been messing around with a very nice little 2.5″ drive cage that parks itself in a standard 5.25″ desktop PC drive bay — see this blog at edtittel.com “Great Product for Recycling 2.5″ Notebook Drives” for more info on that recent adventure. This led to some fiddling about with those recycled drives to transform them from OEM and/or home-built system drives with repair and hidden partitions into standard, single-partition data drives. And, in turn this led to the need for some low-level repair on one of the drives involved (luckily for me it was in the disk area devoted to a repair/recovery partition that I had never used, or it surely would’ve made a bad situation worse). And finally, to close this circle, that’s what led me back to SpinRite.
But, as usual with Windows, there were a couple of interesting flies in the ointment to content with. One is apparently a problem with my production desktop (a prospect that never fails to darken my day), where it simply refused to recognize the FAT-16 bootable UFD upon which SpinRite is installed. When I stuck it into my production system to make sure the UFD was still OK, I ended up wandering into an interesting hall of mirrors. This system doesn’t see the UFD (that’s MS-jargon for USB Flash Drive, in case the acronym is unfamiliar to some readers), except as an anonymous entry in the Disk Management utility:
And although USB gives me the cheerful French horn blast when I stick the drive into that machine, I don’t get the usual drive recognized pop-up window that asks me if I want to do something with it, either (as you’d expect, since the file system apparently doesn’t recognize the drive as a legitimate disk voluime).
But where it gets interesting is that another of my 32-bit Windows 7 systems and a 64-bit system DO recognize the drive, see it as a legit volume, and happily assign it a drive letter as well:
Once I was able to resolve the contents of the SpinRite UFD and ascertain its contents were still complete and correct (easy enough to resolve by downloading the files, and extracting them to disk to compare file names and file sizes, which is where my packrat tendencies to keep all receipts allowed me to grab a new copy from the Gibson Research Website and do due diligence), I was ready to try repairs on my slightly wonky WD 500 GB notebook drive. (Alas, I’m going to use this apparent problem with the file system on my production desktop to spur me into the upgrade to 64-bit that I’ve been putting off for too long now. I’m not sure I know how to solve this kind of file system issue, and it’s probably easier just to wipe the system drive, upgrade from 4 to 12 GB of RAM, and move up onto a more capacious working environment.)
That’s when I hit the next bump in the road: SpinRite would load FreeDOS and get going but it would never get past the “looking for storage devices” phase of its start-up on my test machine. A little quick research quickly revealed that not all BIOSes are created equal, and apparently the one that gets loaded when a PC boots into AHCI (or RAID) mode is not compatible with the BIOS that SpinRite needs to do its thing. With a little trepidation, I made the switch, then booted back up into the UFD. This time, SpinRite ran fine, and after about 6 hours of repair, fixed (or routed around) what ailed my errant disk drive. It seems that the AHCI and RAID BIOS developers cut enough corners in building their versions of the Basic Input-Output System that Mr. Gibson can’t use it to dig deeply and deviously into a drive’s contents with a disk controller that employs such a BIOS. After problems I’ve had with SATA-IDE vs. SATA-AHCI booting issues, I heaved a sigh of relief after switching back to AHCI on the next reboot to my system drive and seeing everything work properly.
But in the end it all turned out to be easy enough to work around, thanks to the presence of multiple machines I could use to figure things out along the way. Now, I just have to find time to upgrade my production desktop to 64-bit Windows and life will be good. Yeah, right!