Update, 2003-01-31: There is probably a way to solve this problem. I've noticed a few Google search hits for inaccessible_boot_device and other related terms coming to this page; let me know if it works for you. By the time Greg found more information about the problem, we didn't care any more, and the office will never be going back to having a Windows server.
I already have a rants category for this blog, but unfortunately I can only tick it once. Maybe I need a "stupid pigfuckers" category. I don't know.
It's probably the motherboard, and apparently it has happened before. One of the servers at work, running Windows 2000, refuses to boot. OK, says Greg, and puts the hard drives into another machine so the primary domain controller and mail server will still be available.
Stop 0x00000079 INACCESSIBLE_BOOT_DEVICE
I can't find the device I just loaded this error message from. No doubt it's all your fault; you've probably got a virus. Or maybe you should try running chkdsk /f. Yeah, that'll help.
(This is not an exact quote; only the essence of its stupidity is preserved here.)
OK, this must be an easy fix. I had a similar error with OS/2 once, when one of the lines in config.sys got munged (and it actually was my fault). Boot into command line mode, fire up the text editor, fix the offending line, reboot. Hooray! All is right with the world.
Of course, Microsoft lives in a very different world.
For one thing, booting into command line mode didn't work either. Microsoft's support web site is huge, so they must have something in there. Off to Google I go (because, of course, Microsoft's own search engine is shithouse) and throw in the magic words. (Of course, this dead server was our domain name server... so I had to find out the IP address for www.google.com and type that into the browser instead. No big deal, though.)
Q271965: "STOP 0x0000007B" Error After Moving Windows 2000 System Disk to Another System sounds remarkably like our problem, doesn't it?
CAUSE: The registry entries and drivers for the mass storage controller hardware in the backup computer are not installed in Windows.
Hmm... OK, so we need to tell Windows about the IDE controller in this computer, because the old computer had a different one.
I would like to point out here that every other PC operating system I've ever used would not have this problem. If it's IDE it'll just run (perhaps not as efficiently as if it had the correct drivers, but it'll run). But that's OK. I'm willing to give Microsoft a little latitude here; it's a simple problem of finding the right driver and telling Windows to use it.
So where does Windows store this information again? Ah yes:
Stupid fucking idiots.
How do you change registry entries? With the Registry Editor. OK, I'll just boot into Windows and... oh, wait. Boot? I was having a bit of a problem booting, wasn't I?
There must be a command line registry editor. Maybe I can boot to—to "safe mode with command line", which doesn't work either. I can't help but wonder what this mode is supposed to be safe from, if it can't boot from a standard fucking PC IDE controller.
There is a command line registry editor, by the way. Of course, you need to boot Windows to run it. While I was searching for all this information, Greg installed a clean copy of Windows on an additional hard drive. So now we can boot, and happily edit that new installation's registry. We can even remotely edit the registry of one of the other computers on the office network.
What we can't do, of course, is edit the registry on another hard drive in this computer.
Fucking useless idiots.
That "knowledge base" article I linked to above does suggest an unsupported remedy, which involves finding two identical machines (both of which will fail to boot with this Windows installation), boot one of them, merge in the magical missing registry keys for all of the IDE controllers Windows knows how to use (under other circumstances I might wonder why this isn't part of the standard Windows installation process, but by this point I'd stopped looking for rational explanations), and swap it back.
Huh? Boot the unbootable installation, then run the registry editor? If it booted it wouldn't be unbootable, for fuck's sake...
Oh — now I get it. I need two computers with Windows already installed, with different IDE controllers, so each computer would fail to boot with the other's hard drive. All I have to do is add the new registry keys, swap hard drives, and... I've now got two computers booting with different hard drives! Hooray, problem solved!
Of course, the "problem" I have solved is getting each of two working test computers (their emphasis) — by definition, computers I don't care about — to boot from the other's hard drive. The computer with the problem, the one I actually want to use, is still sitting in the corner with the pretty blue Stop screen telling me off for getting a boot sector virus.
Fucking hell, you stupid bloody fucking fuckers.
Seriously, if somebody can figure out what those instructions mean, and how that process gets the missing registry entries into the registry of the unbootable Windows system, I would really love to know.
Shortly before giving up, I re-read the "cause" section of the knowledge base article again later, and discovered the special part, the little detail that makes it all worthwhile. I had considered buying a more recent version of Windows to replace the one that came with my computer nearly five years ago. But this little detail is so remarkable that I simply cannot bear the thought of giving these people any of my money ever again. Because, right at the core of this situation, I found something I would never have expected. I found irony.
Fucking idiots, special ironic edition:
For integrated device electronics (IDE) controllers, there are several different chip sets available, such as Intel, VIA, and Promise. Each chip set uses a different Plug-n-Play (PNP) ID to identify it.
Their fucking system won't fucking boot when you plug the hard drives into another computer because of ... Plug and Play support.
All timestamps are Melbourne time.