You know how sometimes you're dealing with a computer problem and you find yourself trying a bunch of things, almost randomly, in a desperate attempt to try and get it to work? There's a name for that. If you're doing that while writing a program it's called voodoo chicken coding. If you're doing it while trying to debug some sort of operating system problem then I suppose it's voodoo chicken troubleshooting. it's called voodoo chicken coding (or troubleshooting) because you don't actually know what the problem is that so it is trying a bunch of random things to get it to work. It's the equivalent of mumbling things to the gods while waving some kind of voodoo chicken over the computer in a vain attempt to get to it to work.
This is not a good strategy. Even if you do manage to solve the problem this way it will probably reoccur again since whatever you did to fix the problem probably just fixed the problem by accident. (I say this coming from a background of trying to debug heavily threaded software).
What is not often stated, however, is that knowing how a system works can sometimes be of no help either. I recently had a problem on my PC where the computer would freeze early in the startup process while the BIOS was still scanning for IDE devices. I ran into this issue I was trying to switch my SATA bus over to AHCI. AHCI stands for Advanced Host Controller Interface. It's a newer protocol for talking to serial ATA devices that offers more features than the normal parallel ATA protocol such as hot swapping and native command queuing. I wanted to enable this on my internal hard drive for two reasons: 1) I thought I already had enabled it at some point in the past. 2) I wanted to enable native command queuing because it sounds cool. 3) I need to enable it in order to run the Mac OS which I've been trying, unsuccessfully, to get running on my computer since I bought it about a year and a half ago. At least part of the reason I haven't managed to get it running is because I haven't managed to get my computer running with AHCI.
Anyway, I turned on AHCI in my BIOS I started getting this freezing problem when the BIOS was scanning the SATA bus looking for new devices. I was a bit confused because as far as I know there's absolutely no way that anything I had done to the hard drive, in terms of formatting or partitioning or installing software, could cause this problem. Scanning for new devices shouldn't be reading anything on the hard drive. That's just weird. Well, it turned out that this was indeed the problem.
After trying everything I could think of I decided simply to wipe the drive in a voodoo chicken debugging attempt to try and get the system to recognize the hard drive without freezing. Amazingly, after doing a low-level formatted the drive and rebooting it worked fine. I still don't understand why this is. Why the heck is it reading off the drive during the device detection routine? Well, I don't know. Anyone want to explain this to me then feel free. Anyway, I'm just happy it's working now. Native command queuing is indeed cool!
So, I'm not sure what the moral of this story is. I think it is that once you've eliminated everything as being impossible the only thing that's left is the impossible, which is impossible. This in turn means you have absolutely no clue what you're doing and might as well start trying a whole bunch of random stuff that shouldn't work.
Now if you'll excuse me, I have some chicken stew to eat. yummy!
Sidenote: Switching from parallel ATA to AHCI requires installing drivers under Windows. Unfortunately installing drivers under Windows requires AHCI to be enabled. Enabling AHCI renders Windows unbootable unless it has the drivers for the AHCI controller installed. This is a very fun situation as it means you can't install AHCI drivers until AHCI is enabled and you can't load Windows if AHCI is enabled. I managed to get around this problem, on my machine by using my two SATA controllers to enable AHCI on the second controller, install the drivers in Windows for this controller, then manually change the hard drive over this this second controller. I then rebooted Windows under the second controller and turned on AHCI under the primary controller. I then moved my hard drive back to the primary controller and start up my machine again. And that effective all these shenanigans with the have AHCI enabled on both controllers and a half the drivers for these two AHCI controllers installed and enabled. There are apparently ways of installing the drivers by booting up from a CD-ROM or other startup disk and then inserting a floppy drive with those drivers at some point. I didn't bother reading up on how to do that as the above methods seemed far simpler to me.