Note: I had originally thought that the BCD was the problem, which turned out to be wrong.
I originally had my laptop set up as follows:
- A 300 GB partition with OS X 10.10 and native full-drive encryption (FileVault).
- A 200 GB partition with Windows 10 and native full-drive encryption (BitLocker).
- A rEFInd boot manager installed on the ESP in
/EFI/boot. - A Microsoft boot manager installed on the ESP in
/EFI/Microsoft/Boot.
Two days ago, I shrinked the OS X partition to 200GB and added a 100GB partition in between, on which I installed Ubuntu.
Ever since then, I have been unable to boot Windows.
When entering the Windows boot manager, I'm still prompted for the password, but after that, I get a screen saying
Your PC/Device needs to be repaired
An unexpected error has occurred.
Error code: 0xc000000e
I then inserted my Windows 10 installation drive, and went to inspect the partition from the command line (ShiftF10).
But diskpart proved unable to mount the partition, because it apparently operates on the MBR.
(I made sure I booted the installation drive in EFI mode (via a manual boot stanza in rEFInd), and so I expected diskpart to operate on the GPT, but oh well…)
The MBR originally container four partitions:
- ESP
- Macintosh HD
- Recovery HD
- BOOTCAMP
The GPT additionally contained a BitLocker recovery partition after BOOTCAMP.
It turned out that adding the Linux partition had changed pushed BOOTCAMP out of the list, and made "Linux HD" the fourth partition.
I simply adjusted the MBR to have the last entry point to BOOTCAMP again, thus "skipping" the Linux partition.
After that, I was still able to boot OS X and Ubuntu, and I was now also able to mount the windows partition from diskpart.
And I managed to unlock the partition with
manage-bde -unlock W: -Password
proving that 1) I didn't mess up the MBR, and 2) the partition was still intact.
In light of this, I'm pretty sure that the problem lies in the BCR.
For reasons still unclear to me I am unable to mount the ESP from the installation drive – trying to assign a drive letter to the first partition of disk 0 tells me that "There is no volume specified", but list volume only lists everything that's already mounted.
bootrec /rebuildbcd also fails horribly, removing the BCD file from the installation drive.
However, I am able to simply copy the BCD to the installation drive, and use bcdedit on it.
bcedit /store BCD prints:
Windows Boot Manager
--------------------
identifier {bootmgr}
device unknown
path \EFI\Microsoft\Boot\bootmgfw.efi
description Windows Boot Manager
locale en-US
inherit {globalsettings}
default {default}
resumeobject {cc3e7046-4857-11e5-a015-f353893f9a4c}
displayorder {default}
toolsdisplayorder {memdiag}
timeout 30
Windows Boot Loader
-------------------
identifier {default}
device unknown
path \Windows\system32\winload.efi
description Windows 10
locale en-US
inherit {bootloadersettings}
recoveryenabled No
custom:16000060 Yes
custom:17000077 352321653
osdevice unknown
systemroot \Windows
resumeobject {cc3e7046-4857-11e5-a015-f353893f9a4c}
nx OptIn
custom:250000c2 1
Now these unknown didn't look so good to me, so I changed them to partition=W: using
bcdedit /store BCD /set {default} device partition=W:
bcdedit /store BCD /set {default} osdevice partition=W:
And I verified the result:
Windows Boot Manager
--------------------
identifier {bootmgr}
device unknown
path \EFI\Microsoft\Boot\bootmgfw.efi
description Windows Boot Manager
locale en-US
inherit {globalsettings}
default {default}
resumeobject {cc3e7046-4857-11e5-a015-f353893f9a4c}
displayorder {default}
toolsdisplayorder {memdiag}
timeout 30
Windows Boot Loader
-------------------
identifier {default}
device partition=W:
path \Windows\system32\winload.efi
description Windows 10
locale en-US
inherit {bootloadersettings}
recoveryenabled No
custom:16000060 Yes
custom:17000077 352321653
osdevice partition=W:
systemroot \Windows
resumeobject {cc3e7046-4857-11e5-a015-f353893f9a4c}
nx OptIn
custom:250000c2 1
But after pushing that BCD file back onto my ESP, the Windows boot manager doesn't even prompt me for a password anymore, but instead immediately display me a different error, saying
Your PC/Device needs to be repaired.
The application or operating system couldn't be loaded because a required file is missing or contains errors.
File: \Windows\system32\winload.efi
Error code: 0xc0000225
I tried setting device and osdevice before and after decrypting the W: drive, with the same result.
Setting device for {bootmgr} also made no difference.
Now, I'm pretty sure that this was a step back, because it doesn't even ask for my password anymore.
I also noticed that even running bcdedit /store BCD made quite a lot of changes to the file, given the fact that there were no data changes.
Among other things, the file would apparently contain its own path, being Volume1\EFI\Microsoft\Boot\BCD for the original BCD file, and ??\C:\BCD for my modified file.
I was at first worried that this would in some way "impurify" the file, but I ran a test, changing description of {default} to Windows 42, which, again, caused quite a lot of changes in the file, but the Windows boot manager still asked me for a password when using that file, so neither does a custom file location "impurify" the file, nor is the bcdedit I'm using broken.
Now, finally my question:
How can I repair my BCD?
Or if that's not the issue, then what is, and how can I fix it?
Additional info:
diskutil list
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.3 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_CoreStorage 200.4 GB disk0s2
3: Apple_Boot Recovery HD 650.1 MB disk0s3
4: Microsoft Basic Data 99.0 GB disk0s4
5: Microsoft Basic Data 199.7 GB disk0s5
6: DE94BBA4-06D1-4D40-A16A-BFD50179D6AC 363.9 MB disk0s6
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS Macintosh HD *200.0 GB disk1
Logical Volume on disk0s2
4A45027B-2703-4C7D-816E-3419DE0F0F61
Unlocked Encrypted
sudo gpt show -l /dev/disk0
gpt show: /dev/disk0: Suspicious MBR at sector 0
start size index contents
0 1 MBR
1 1 Pri GPT header
2 32 Pri GPT table
34 6
40 409600 1 GPT part - "EFI System Partition"
409640 391334208 2 GPT part - "Customer"
391743848 1269760 3 GPT part - "Recovery HD"
393013608 1688
393015296 193355776 4 GPT part - "Linux HD"
586371072 2048
586373120 390019148 5 GPT part - "BOOTCAMP"
976392268 1972
976394240 710656 6 GPT part - ""
977104896 131
977105027 32 Sec GPT table
977105059 1 Sec GPT header
sudo fdisk /dev/disk0
Disk: /dev/disk0 geometry: 60821/255/63 [977105060 sectors]
Signature: 0xAA55
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
1: EE 0 0 2 - 1023 254 63 [ 1 - 409639] <Unknown ID>
*2: DA 1023 254 63 - 1023 254 63 [ 409640 - 391334208] <Unknown ID>
3: AF 1023 254 63 - 1023 254 63 [ 391743848 - 1269760] HFS+
4: 07 1023 254 63 - 1023 254 63 [ 586373120 - 390019148] HPFS/QNX/AUX
The Windows boot manager with the original BCD:
The Windows boot manager with the original BCD after entering my password:
The Windows boot manager with a modified BCD:
Update 1:
I tried marking BOOTCAMP as "bootable" in the MBR, with no change at all.
Best Answer
The BCD was actually fine, it was the MBR that was causing all the trouble.
I had already decrypted my drive[1] and was attempting to reinstall Windows, but when selecting the drive gave me a popup, saying something like "this hard drive uses MBR, but EFI-based systems can only be installed on GPT drives".
So apparently, on Windows, MBR takes precedence over GPT.
I went ahead and replace∂ my MBR with a "protective" one, using
(On Linux,
gdiskshould be installed by default (otherwise trysudo apt-get install gdisk), on Mac you can get it from here.)This finally solved my problem.
[1] It seems that isn't actually necessary, but for the record: Assuming your encrypted drive is labelled
W:, first unlock it from the install drive command line, then runmanage-bde -off W:, check the progress every now and then withmanage-bde -status W:, and reboot once encryption hits 0%.