This past summer, I had to rebuild one of my test Windows machines when the original motherboard went south. When doing the rebuild, the machine crashed during the reboot part-way through the install process, and forced me to switch from AHCI to IDE mode for the disk drives I was using, even though they’d worked fine in AHCI on the previous motherboard. I wrote it off to some issue with AHCI and my combination of parts, and simply stayed with the switch to IDE and figured that would be the end of it.
But when I was finally able to get the proper IDE drivers loaded for that machine this weekend I decided to revisit the AHCI issue on this Gigabyte P43-ES3G. I like to tinker with my systems over the holidays, and have just finished a major patch-fix-upgrade-and-repair pass over all my PCs now; the disk controller stuff all started working when I switched the BIOS from “emulate IDE” to “straight SATA” just to see what would happen. IDE kept working, but DriverAgent was suddenly able to help me find the right, current drivers for the Intel ICH10R chipset and the JMicron JMB36X SATA/IDE controller on the P43-ES3G. “What the heck,” I figured, “Let’s try AHCI now, and see what happens.” It still kept hanging during drive detect while booting.
With some assiduous poking around, I discovered that others have had issues with the BIOS hanging during the drive detect just as I have, including a variety of Asus as well as Gigabyte motherboards. As it happens, the reason I had to switch from AHCI to IDE drive mode was because drive detection would hang on the second of the two drives in that system (a Samsung 1 TB HD103UI 7200 RPM hard disk) after correctly detecting the WD 300 GB Raptor that serves as the boot drive, but before detecting the presence of the SATA DVD burner on the system.
Just for grins, I tried a different drive instead of that Samsung yesterday while fiddling with the machine, after which AHCI booted like a charm. Upon further investigation I came across a posting on social.technet.microsoft.comfrom a gentleman named Ivan Filippov –who just happens to work for German-based disk formatting and partitioning company Paragon Software (whose Hard Disk Manager Suite has long been a favorite of mine) that explains a possible cause for this situation. He observes that when the disk geometry data in the first partition on a drive gets munged, it can cause disk recognition at the BIOS Level to fail. The two other drives I tried to replace the original Samsung didn’t have this problem, apparently, and the drives were recognized and the AHCI BIOS loaded successfully–and so did the Samsung itself, after I popped it into a SATA drive caddy on another machine (after backing it up, of course) and repartitioning and reformatting that drive.
Problem solved, and I learned something both interesting and valuable. I should’ve just tried another drive (I’ve always got at least a couple of spares around, sometimes more than that) when I first hit this problem and it pretty much would have solved itself. And so it goes! Another obscure but interesting Windows lesson learned, and another pesky annoyance rubbed out at last…
[Note to readers: I'm taking the rest of the year off, so you won't see me post again until January 2, 2012. Let me take this opportunity to wish everyone a happy holiday season, and a festive and prosperous New Year!]