I had a really "fun" experience last night as I tried to replace a failing 2TB HD in my media machine with a new 3TB I purchased. On the plus side SMART warned me early that there was a problem so I had time to order the new drive (2 day shipping, thanks Amazon!), install it, and copy everything over to it before the old drive started to smoke (it hasn't done that yet actually, heh).
On the negative side, it turns out the H: drive that was failing was actually on SATA 1 and, apparently, was the boot drive, even though Windows is installed on another drive. There's no OS installed on this system, never has been, so while I recognize the potential benefit of allowing partitions without the primary OS on it to be the "boot" partition, I really think this should be an advanced option that you need to manually specify. I also don't think it should have to do with what SATA port your drive is plugged in to. It's long enough ago that I can't remember why the config ended up this way, but I'm pretty confident I was not aware that some drive other than the OS install drive was set to manage booting. Why, after all, would I do this intentionally unless I was multi-booting? So my first issue is that I think Windows basically made this decision on its own during install of Win7. Bad default.
That would not be so bad *if* Windows could intelligently move or recover from the loss of a boot drive. In my case, at least, it could not. Here's what happened:
I removed the failing drive after copying everything off of it and on next boot I got a message "Reboot and select proper boot device..." etc. Now I had just copied all the files off the drive, I knew it wasn't the Windows install drive, but I plugged it back in just to be sure. It booted up, of course, but looking at H: showed no Windows files, as I thought. Unplugged again, same message. OK, Windows is stupid, but a simple repair should work, yes? Put in the DVD, booted to it, tried startup repair several times in sequence, no go. It didn't even recognize the Windows install I had in there, even though it was on C: and in the default \Windows install directory. WTF? Tried manual startup repair from command prompt in recovery mode. Nope. Then I found out about bcdedit.exe and the new way Windows 7 manages booting. I found a Windows-based BCD tool so I figured I'd just boot back into Windows and specify the right drive for boot. Oops, the "repairs" I had attempted previously without the old drive in there appear to have done *something*: they made it so even the old config doesn't work. Argh!
Finally I found
these instructions and yes, I had to follow every last one, essentially manually recreating the bcd file. This is a royal pain in the ass. This should not be necessary.
Why in the name of all that is holy does Windows 7 not handle this more gracefully? Seeing what is actually *in* the BCD file it is retardedly simple. The kind of thing you would think could be generated on the fly *if necessary*. A simple scan of the available drives ought to turn up *all* of the info that's in there. It's absolutely ridiculous that I had to spent a half hour in the command prompt to fix this, and that was only after an hour or two of trying other options that should have been easier and should have worked. Really I think it should have "just worked" considering nothing was lost except this stupid BCD file.
So has anyone else experienced this? Any sane explanations as to why it's done this way and why recovery is not easier? Why could Windows Startup Repair not even find my Windows install (yes, the BCD file was missing, but there is a bcdedit scan function that can find it, why did the GUI version not do this?)? Am I just ridiculous for expecting to be able to remove a non-boot (or apparently not) drive and expect my system to still boot? And why did I even get into this mess in the first place - I never asked Windows to use a drive other than the Windows install drive for boot management.
- Oshyan
