Looks like my BCD is somehow broken but I can't figure out what is wrong. The system boots just fine but it prevents windows from installing updates:
MoSetupPlatform: Opening BCD store...
CDlpActionDiskSpaceReq::CalculateRequiredDiskSpaceInstallReq(1752): Result = 0x8007001F
I'm running Windows 10 on a MacBook (bootcamp), it uses EFI partition table. When I run bcdedit /enum
in elevated prompt I get
The boot configuration data store could not be opened.
A device attached to the system is not functioning.
When I try to open store directly, it opens just fine:
B:\>bcdedit.exe /store B:\EFI\Microsoft\Boot\BCD /enum
Windows Boot Manager
--------------------
identifier {bootmgr}
device partition=B:
path \EFI\Microsoft\Boot\bootmgfw.efi
description Windows Boot Manager
locale en-US
inherit {globalsettings}
default {default}
resumeobject {8b3fea76-03c8-11e6-8f47-dc08058a457d}
displayorder {default}
toolsdisplayorder {memdiag}
timeout 30
Windows Boot Loader
-------------------
identifier {default}
device partition=C:
path \WINDOWS\system32\winload.efi
description Windows 10
locale en-US
inherit {bootloadersettings}
recoverysequence {8b3fea78-03c8-11e6-8f47-dc08058a457d}
displaymessageoverride Recovery
recoveryenabled Yes
isolatedcontext Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \WINDOWS
resumeobject {8b3fea76-03c8-11e6-8f47-dc08058a457d}
nx OptIn
bootmenupolicy Standard
Does Windows store actual BCD somewhere else? How does windows know on which partition and path to look for system BCD store?
How do I diagnose what is wrong with my BCD store?
update: forgot that I boot using refind
bootloader which likely boots bootmgfw.efi
Looks like OS X makes some changes that are incompatible and break bcdedit. Here's how I was able to temporarily fix this issue: reset NVRAM with ⌘+Alt+P+R, then boot directly into windows partition by holding Alt. I was able to install windows updates but after I booted into OS X and installed updates, bcdedit became broken again.
One situation in which the system will boot but bcdedit /enum
will fail is if the EFI boot partition has the wrong partition type. As a side note, this may also cause reagentc /enable
to fail and may additionally prevent Windows updates from installing successfully.
You can check whether this is your problem with the diskpart
command. Assuming you have only one hard disk drive,
select disk 0
list partition
You should see something like this:
Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 System 500 MB 1024 KB
Partition 2 Primary 445 GB 501 MB
(There may or may not be a third "Recovery" partition as well.)
The smaller partition named "System" is the one you want, usually partition 1, so
select partition 1
detail partition
And you should see something like this
Partition 1
Type : c12a7328-f81f-11d2-ba4b-00a0c93ec93b
Hidden : Yes
Required: No
Attrib : 0XC000000000000000
Offset in Bytes: 1048576
Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ----- ---------- ------- --------- --------
* Volume 3 FAT32 Partition 500 MB Healthy System
If the file system is not FAT32 then you are not looking at the right partition. It should also be Hidden, and will not usually have a drive letter assigned unless (as in the originally posted question) it has been explicitly given one for troubleshooting purposes. It might not be exactly 500MB, but should only be taking up a small fraction of the hard disk.
The type of the EFI partition should be c12a7328-f81f-11d2-ba4b-00a0c93ec93b
as shown above. If it is not, and in particular if it is ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
(see Microsoft Basic Data Partition on Wikipedia) then that is likely to be the cause of the problem.
Addendum: if the current type of the partition is 07 or any two hexadecimal digits, the disk is partitioned in MBR mode rather than EFI mode and this answer is inapplicable.
If the partition type is incorrect, you can fix this with the set id
command,
set id=c12a7328-f81f-11d2-ba4b-00a0c93ec93b
The bcdedit /enum
command should then work.
A Does Windows store actual BCD somewhere else? How does windows know on which partition and path to look for system BCD store?
EFI mode works with two legs;
1- a special BIOS (on chip writable area) partition where OS Loader Partition GUIDs are saved.
2- a system (hidden) partition with that GUID named EFI where Bootloader executable located (.efi extension files).
If you have installed/reinstalled several OS'es on EFI mode , then chances are, BIOS SPI chip got cluttered with many records of old OS'es and eventually filled up space on that special 8MB (if I'm not wrong) on-chip partition and became read-only.
Microsoft has a Technet page where it's shown how to clean up EFI duplicate or unneeded guid records (for example OS deleted but EFI record is still there) .
It involves creating a backup of current configuration then resetting it without duplicate records.
on an elevated cmd prompt;
Bcdedit /export savebcd
this will backup current bootloader configurations.
make a copy of it for recovery purposes (savebcd will be our backup);
Copy savebcd newbcd
Then export current records to a text file in human-readable format;
Bcdedit /enum firmware > enumfw.txt
notepad enumfw.txt
Load that file with notepad and review it to point duplicate records.
to delete each duplicate/obsolete record:
Bcdedit /store newbcd /delete {93cee840-f524-11db-af62-aa767141e6b3}
where 93cee840-f524-11db-af62-aa767141e6b3 is just an EXAMPLE guid
replace it with the guid which you think unneeded
once you have gone thru deletion of all unneeded guids;
Bcdedit /import newbcd /clean
Clears current EFI records and imports the cleaned (file we just cleaned unneeded records from) configuration data.
If you still get "A device attached to the system is not functioning." error,
Then; I don't want to be a bad news bringer but You have two paths to follow;
- Stick to your current system; make a WHOLE disk image backup (including your EFI partition) ASAP,
because most possibly your SPI (BIOS) chip has cluttered and you cannot flush it without reflashing/replacing it.
This means current Bootloader pointers on the chip are final and if you try to reinstall another OS in EFI mode , it simply won't finalize installation and installer will be interrupted with an error (Windows OS family) or will finalize but BIOS won't load it (Linux installers , e.g. openSUSE), moreover you'll lose your old config, you'll end up having no booting OS on your device.
- Considering you have a Mac , ask tech support to reflash/replace BIOS.
if that's not the case or not feasible; replace hard drive switch to legacy BIOS mode (if that switch in BIOS still works, for me it just didn't work (Lenovo Ideapad B50)
other than these there are some other options to be ruled out as follows: as they are offered as if they are safe tips in some videos on Youtube about this subject, so I just mention them as not to try, because they are dangerous and/or voids device warranty (removing laptop battery + disassembling device to expose motherboard then removing bios battery + waiting (hoping) bios to reset , or shorting (short-circuiting) SPI chip); especially bios battery removal method never works in most (if not all) laptops, while shorting SPI chip can cause even whole system to get bricked.
Hope these helped.
User contributions licensed under CC BY-SA 3.0