Okay, I've had time to put together a proper outline here. It's long, but it's pretty complete and should help you see what's going on.
First, one way this can happen:
- Your BIOS loses its settings.
- No problem, all that stuff's stored in the EFI partition.
- ...except for the SATA IDE vs AHCI setting, for obvious reasons.
- Were you using SATA-AHCI? You're probably using SATA-IDE now.
- Did you try to boot before you figured that out?
- If you did, it failed. Did you let Windows try to fix it?
- If you did, BLAM, it may very well have destroyed the Boot Configuration Database.
- Make sure you're using the correct SATA setting you were using last time.
Here's what you've probably done by now. IF ANY OF THIS DOES NOT MATCH, CAREFULLY EVALUATE WHETHER THIS IS IN FACT YOUR PROBLEM, and READ this for ideas but don't FOLLOW it without thinking first.
You have HOPEFULLY ignored all the crap about fixing the Master Boot Record (MBR), partition table, partition flags, and other bullshit that DOES NOT APPLY to an EFI boot scenario. AT ALL. At best, you would be able to completely rebuild a new, unrelated, NON-EFI boot solution. That might not be trivial, however, because:
You have figured out that Windows is certain it does not have a Boot Configuration Database, but it is, unfortunately, either completely clueless or VERY certain about where it goes-- you can't quite tell which.
You're aware that the boot store is normally (somewhere)\Boot\BCD and that the file is HIDDEN; view it using "dir /a:hs".
You've familiarized yourself a bit with BCDEDIT.EXE and figured out that it will let you "mock up" a Boot Configuration Database in a staging file using "/CREATESTORE" (and please don't name it "BCD"), that you can explicitly use the staging file with the "/STORE" option, that you can add a menu entry for the Windows Boot Manager using "/CREATE {bootmgr}", and that you SHOULD be able to import it using "/IMPORT"...
...but when you try to do this, you can't. You look into the /SYSSTORE option, which sounds right, but you can't get it to use another store because it's "ambiguous". You have a hunch that it knows where the store is-- or should be-- but you can't find it.
You've tried to use "MOUNTVOL" to mount the EFI partition, but it doesn't even show in the list, so you can't.
If ALL of that applies fairly closely to you, here is what MAY be going on:
Windows can tell you're set up for EFI (you have booted the DVD via a UEFI boot, you have an EFI partition, etc.).
It therefore knows WHERE TO LOOK for the BCD file-- however, it either somehow has the location wrong (not this problem, but similar) or the BCD has been deleted.
Apparently, because it knows where it SHOULD be, this breaks /SYSSTORE-- and actually, that's probably correct behavior, because otherwise you'd put it in the wrong place.
As near as I can tell, MOUNTVOL deliberately hides the EFI partition (or is somehow incapable of noticing it). This prevents mounting the filesystem, which prevents finding the correct subdirectory, verifying that the database exists, etc.
So here, finally, is what you need to do about it. The good news is that it's probably a lot simpler than you're hoping by now.
- You do indeed have to mount the EFI partition.
Actually, I have a hunch that's not strictly correct-- I strongly suspect the EFI partition is already mounted by some internal subsystem, which is why BCDEDIT gets cranky-- it doesn't see the database, but it knows where it should go. Whatever it does not have, however, is a drive letter. So-- what to do?
Well...how far back do your DOS roots go? Do you remember the ASSIGN command? Guess what.
Start DISKPART.
If you are not familiar with DISKPART, the way it basically works is a hierarchy of sets; you must select exactly one element at one level to proceed to the next. So, "LIST DISKS", and then "SELECT DISK n" where n is whatever's appropriate for you.
Use "LIST PARTITION" and "LIST VOLUME" (note non-plural) to get some insight and identify your EFI partition.
It is usually a 100MB FAT32 partition marked "SYSTEM". Keep in mind that your disk should be using a GPT partition table by now, so you may see quite a few partitions. Some of these are for emergency recovery-- fat lot of good they do for EFI problems, eh? Oh well.
Notice that the EFI partition, and a few others, do not have drive letters. If you're so inclined, you can also view the GPT partition attributes, which may give you a few tangentially-related "Aha" moments as well.
"SELECT PARTITION n" where n is the EFI partition. (I expect you could select the volume instead if you need to.)
"ASSIGN". That's it. Don't specify a drive letter; just "ASSIGN".
"LIST VOLUME". You should now see a drive letter assigned to the EFI partition.
"EXIT" DISKPART.
And now... a big fat warning. You will probably go directly to S: (or whatever you got from ASSIGN) and notice a /Boot partition. "AHA!" You will say. "There is no BCD file here!" First... remember that file is hidden. Second... dig around a bit more, and you will notice that while there is:
S:\EFI\Boot
there is also:
S:\EFI\Microsoft\Boot
You need to check both of these for problems.
S:\EFI\Boot is for the motherboard, and contains the Windows Boot LOADER (and possibly other things for other operating systems). This has this name because the motherboard has no idea if you're going to have Windows or not, and needs a fixed path that makes sense.
- Inspect S:\EFI\Boot. For Windows 7 Professional, 64-bit, you should see:
bootx64.efi
If you have installed an EFI shell (always a good idea), you might additionally see "shellx64.efi".
NOTE: Dual-boot Linux users using "chainloader+1" WILL NOT see an extra entry here.
- Inspect S:\EFI\Microsoft\Boot using both "dir" and "dir a:h". For Windows 7 Professional, 64-bit, you should see a bunch of language templates ("en_US", etc.) and the following files:
bootmgr.efi
bootmgfw.efi
memtest.efi
BCD
BCD.Backup.001
BCD.Backup.002
...except that you probably don't see BCD, do you? But those backup files sure look tempting.
Determine which backup file you want to use. Whatever recent changes it's missing are nowhere near as important as your ability to boot the system, so go for the one that's most intact. Probably you will see one large one and one fairly small one. The small one is already corrupt, and is an artifact of the failed repair process-- don't use it. If they're both large, use the older one. IN ANY CASE, make ADDITIONAL BACKUP COPIES OF THE BACKUPS somewhere else.
Copy the backup you've decided to use to "BCD".
Exit the shell, shutdown cleanly, and reboot.
Tell Windows to start NORMALLY. At this point, it should start.
Q: What if you don't HAVE a backup BCD?
A: Well, that really shouldn't happen. It likely means you're either in the wrong directory, support EFI but weren't actually using it, or somehow rebuilt your entire EFI partition without all of the required Windows materials (possible, especially when using multiple versions of Windows). In that case, you'll need to copy the EFI materials from the DVD, then either modify or rebuild the Boot Configuration Database using BCDEDIT.
Q: Can you give me an example of a scenario where "BCDEDIT /SYSSTORE" can be used to do anything at all on an EFI system?
A: So far, no.
Anyway, hope this helps solve some problems for people, or at least gets them thinking. As a very important final point, please note that you can mount and inspect your EFI partition under Windows normally using the DISKPART ASSIGN technique above. You should do this at least once, to get a complete backup of your EFI partition, BEFORE you run into this kind of trouble. I recommend one backup into a subdirectory on your C: drive, and one on a USB flash drive.
Sorry that's so long-winded. I need to turn this into a proper article at some point, but there are so many people who are SO frustrated that I felt the need to document my experience as completely and rapidly as I could.
Cheers,
Matt "Breakpoint" Heck