EasyBCD Boot Device

C

cparke

Member
My system uses BIOS/MBR, but I have developed an issue similar to what has happened to others where my 'EasyBCD Boot Device' has become a different partition than the system partition or boot partition. This message appears to indicate where the Windows bootstrap code looks for the system BCD store itself, so obviously it's not something that can be defined in the BCD itself. I always thought the system BCD had to be located on the same active partition where the bootstrap code is loading from, or otherwise based on the a system flag in the MBR partition table, but apparently that's not the case and it can even be on a third partition!

See below my partitioning and EasyBCD settings overview, running under the Drive C: (Win7 Reinstall) installation:

Partition Table.PNG

EasyBCD Boot Device.png

Code: 
Windows Boot Manager
--------------------
identifier              {9dea862c-5cdd-4e70-acc1-f32b344d4795}
device                  partition=\Device\HarddiskVolume1
description             Windows Boot Manager
locale                  en-US
inherit                 {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
default                 {bd695476-583d-11eb-a432-c038964c4094}
resumeobject            {ae096e85-58a0-11eb-8b5a-bb58358aa898}
displayorder            {bd695476-583d-11eb-a432-c038964c4094}
                        {ae096e86-58a0-11eb-8b5a-bb58358aa898}
                        {6edec105-e9b9-11e7-a9ce-b5e6ef2bb9b8}
                        {f689521f-583b-11eb-a429-f785189f96d5}
                        {d5d869d4-583c-11eb-a429-f785189f96d5}
toolsdisplayorder       {b2721d73-1db4-4c62-bf78-c548a880142d}
timeout                 30

Windows Boot Loader
-------------------
identifier              {bd695476-583d-11eb-a432-c038964c4094}
device                  partition=W:
path                    \WINDOWS\system32\winload.exe
description             Windows 10
locale                  en-US
inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
recoverysequence        {571a03ec-583c-11eb-a432-c038964c4094}
displaymessageoverride  CommandPrompt
recoveryenabled         No
allowedinmemorysettings 0x15000075
osdevice                partition=W:
systemroot              \WINDOWS
resumeobject            {0b7cf552-583d-11eb-a432-c038964c4094}
nx                      OptIn
bootmenupolicy          Standard

Windows Boot Loader
-------------------
identifier              {ae096e86-58a0-11eb-8b5a-bb58358aa898}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 7
locale                  en-US
inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
recoverysequence        {ae096e87-58a0-11eb-8b5a-bb58358aa898}
recoveryenabled         Yes
osdevice                partition=C:
systemroot              \Windows
resumeobject            {ae096e85-58a0-11eb-8b5a-bb58358aa898}
nx                      OptIn

Windows Boot Loader
-------------------
identifier              {6edec105-e9b9-11e7-a9ce-b5e6ef2bb9b8}
device                  partition=V:
path                    \Windows\system32\winload.exe
description             Windows 7 Ultimate x64 (hidden)
locale                  en-US
inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
recoverysequence        {da941675-5842-11eb-a432-c038964c4094}
recoveryenabled         Yes
osdevice                partition=V:
systemroot              \Windows
resumeobject            {8c76dfa4-5842-11eb-a432-c038964c4094}
nx                      OptIn

Windows Boot Loader
-------------------
identifier              {f689521f-583b-11eb-a429-f785189f96d5}
device                  partition=U:
path                    \Windows\system32\winload.exe
description             Windows 7 Ultimate x64 (new)
locale                  en-US
inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
recoverysequence        {6edec106-e9b9-11e7-a9ce-b5e6ef2bb9b8}
recoveryenabled         No
osdevice                partition=U:
systemroot              \Windows
resumeobject            {6edec104-e9b9-11e7-a9ce-b5e6ef2bb9b8}
nx                      OptIn

Real-mode Boot Sector
---------------------
identifier              {d5d869d4-583c-11eb-a429-f785189f96d5}
device                  partition=\Device\HarddiskVolume1
path                    \Boot\linux.bin
description             Linux
I have a BCD store and bootmgr installed on all 3 primary partitions!

This was supposed to me to me that if I change the active partition to the Windows installation itself rather than the 'System Reserved', the boot menu would be based on the BCD store located on that partition instead. What I'm finding, however, is that if change the active partition to W:, the boot menu is based on the BCD store located on U: instead, which is wrong! (and could be a big problem if U: isn't there anymore) Notice on my setup, near the top: 'EasyBCD Boot Device: U:\' Where does this information come from?

I know for a fact that even marking the U: partition as 'hidden' doesn't stop its BCD from being used when the W: partition is marked active, and renaming the U:\Boot directory on the partition to U:\Boot.Saved makes the active W: partition non-bootable because it can't locate the BCD on U: anymore.

So the system BSD store location seems to be written into the Volume Boot Record (VBR) or something, as its location does seem to vary when I change which partition is marked active, but the Microsoft tools like BOOTSECT, BSDBOOT, and BOOTREC don't seem to provide any way to see this information or change it, nor provide a direct way to fix it (oddly too, it seems like \BOOT\BSD path is hardcoded and can't be moved?) Yet, EasyBCD seems to be at least able to find this location.

I fear very much that a variation of this problem may be the reason for the INACCESSIBLE_BOOT_DEVICE (Bug Check 0x7B) Blue Screen Of Death (BSOD) that I'm seeing trying to boot the U: and V: installations (which were there before W: was created), as there's nothing wrong with any of the disk or NTFS file systems. If they're trying to read the system BSD store from an invalid location, that absolutely could explain it! I would like to fix this issue too.

In this forum, several people have also had something like this happen to them. Here's the most recent posting:
https://neosmart.net/forums/threads...bcd-boot-device-which-points-to-drive-k.20113

Unfortunately, there is no good answer provided in any thread on how exactly the Windows BootMgr or WinLoader and EasyBCD know the BCD's location, nor do any tools that I know of allow you to directly modify it! EasyBCD has three confusing repair options that might help, "Reset BCD configuration', 'Re-create/repair boot file', and 'Change boot drive', but I think these all are applied to the currently running system (which right now is based off the 'System Reserved' partition), and I stated above I can't boot into the broken U: and V: systems to run the utility from there. Therefore, I would like to know how the location of the BCD store itself is determined by the system.

Much appreciation for any thoughts and assistance on how to use the tools properly to get my system setup corrected!
 
Last edited:
"EasyBCD Boot device" is not the location of the BCD.
In overview mode EasyBCD will tell you if it's stored any of its own boot files and that's how it describes the location (e.g. files used to chain to the location of a Linux or legacy Windows OS, which cannot be located from the BCD directly)
In "detailed mode" it will point to "Boot Device" which is the actual location of the boot files in use.

I don't know what partition manager you used for that screenshot, but it's obviously not using the term "boot" in the same way as MS does.
Post that information from Disk Management and you'll see a different set of flags.

"boot" = "this is the system you're running"
"system" = "this is where I found the boot files for the currently running system"
"active" (on the first HDD in the BIOS boot sequence) = "this is where I started the search for the boot files"
"active" (on subsequent HDDs in the BIOS boot sequence) ="this is where I will look if I don't find something in the MBR on the first HDD"
 
Terry60 said:
"EasyBCD Boot device" is not the location of the BCD.
In overview mode EasyBCD will tell you if it's stored any of its own boot files and that's how it describes the location (e.g. files used to chain to the location of a Linux or legacy Windows OS, which cannot be located from the BCD directly)
In "detailed mode" it will point to "Boot Device" which is the actual location of the boot files in use.

I don't know what partition manager you used for that screenshot, but it's obviously not using the term "boot" in the same way as MS does.
Post that information from Disk Management and you'll see a different set of flags.

"boot" = "this is the system you're running"
"system" = "this is where I found the boot files for the currently running system"
"active" (on the first HDD in the BIOS boot sequence) = "this is where I started the search for the boot files"
"active" (on subsequent HDDs in the BIOS boot sequence) ="this is where I will look if I don't find something in the MBR on the first HDD"
Click to expand...

The partition manager I used is Acronis Disk Director 11. I'm aware the flags are different than Windows, which as you know are quite confusing.

I resolved the boot drive issue by discovering that the boot sector code uses the hidden sectors information in the BPB block to determine what drive it running on! Folks who done partition cloning without proper tools and then try to boot the clone will run into this type of problem, because the BPB still points back to the original boot location and the bootmgr and BCD from the original location is used for the boot. This is what happened to me. Fixing that stopped the third party partition from being referenced.

However, I still have the INACCESSIBLE_BOOT_DEVICE (Bug Check 0x7B) Blue Screen Of Death (BSOD) trying start the other two Windows 7 parititons , even with Safe Mode minimal set. In this case, it looks like WinLoader.EXE has started running and loading drivers. However, after CLASSPBP.SYS loads, it throws the kernel exception. Is this perhaps a registry issue? I'm try SFC /SCANNOW OFFBOOTDIR=C:\ OFFWINDIR=C:\WINDOWS\ in recovery environment hoping something good will come out of that. Any other suggestions would great!
 
Delete those failing entries and add them again, simply pointing to the appropriate letter. You don't need separate BCDs on every partition. That's a complete waste of time and causing you confusion. Don't go resetting the active flag, that's how its finding the live BCD
The BCD on the System Reserved Partition should control everything and the partition be active permanently,
 
Last edited:
Does EasyBCD provide a good way to remove the \BOOT directory and the BOOTMGR? Somehow just deleting hidden system files doesn't feel good.

BTW - sometimes I see "EasyBCD Boot Device" and sometimes just "Boot Device". Still not clear what's the difference? I never used EasyBCD to write files...

Deleting the broken partitions giving the INACCESSIBLE_BOOT_DEVICE (Bug Check 0x7B) BSOD is not what I want to do. I want to get them running again. They crashes before boot logging begins, and there is no crash dump file. Perhaps Easy Recovery Essentials for Windows can find this issue? Or, I was thinking there might be a way to create a special BSD entry to cross-boot, so that the boot reads the startup system files from the good Win7 partition but then switches to the SystemRoot of the broken partitions. Does anybody know at what booting stage the switchover happens?
 
If you used EasyBCD to make a Linux entry, then you wrote an EasyBCD ANG (AutoNeoGrub) file into your currently active partition.
Bootmgr cannot natively boot Linux or XP, only Longhorn versions of Windows.
EasyBCD enables booting of those "foreign" OSs by using a Neosmart re-engineered Windows version of grub to create a chain to the target device, or an EasyBCD copied version of NTLDR, (and other necessary XP boot files)
That chain starts (has to start) at the device containing Windows own boot files. That's labelled "EasyBCD Boot Device" even if it's no longer being used (My own PC still contains redundant MBR entries from when I first multi-booted the W10 Beta with my existing OSs from a storage HDD. EasyBCD reminds me they're still there)
EasyBCD doesn't contain any method of removing redundant files when "Delete" will do it perfectly adequately.
I didn't mean delete the OS, just the BCD entry for it, then re-add the entry.
 
Interesting, that must have been quite an effort!

I did the same thing much easier, by just capturing the boot sector of the Linux partition into a NTFS file and then configuring BCDEdit to execute it if selected:
Code: 
$ dd if=/dev/sda3 of=/mnt/share/linux.bin bs=512 count=1

C:\>bcdedit /create /d “Linux” /application bootsector
C:\>bcdedit /set {ID} device partition=c:
C:\>bcdedit /set {ID} path \ubuntu.bin
C:\>bcdedit /displayorder {ID} /addlast

Of course, I've not used your EasyBCD ANG (AutoNeoGrub) file, but I'm still seeing "EasyBCD Boot Device" sometimes.


I'm pretty sure my issue with those broken partitions is not BCD related. I've verified and re-built the BCD several times now. It's happening in WinLoader.EXE while drivers specified in the CurrentControlSet are being loaded. The last message I see is the "Safe Mode - Minimal" announcement before it throws, indicating it definitely has read the BCD settings already. Unfortunately, it seems the only way to find out the invalid boot device path is to either manually review the driver registry entries, or perhaps use Boot Debugging mode of the WinDbg Kernel Debugger to obtain the data causing the exception. I'm assuming your recovery tool can't assist with this sort of problem?
 
Last edited:
I'm not a user of EasyRE. I have Installation DVDs for every version of Windows to effect boot repairs
This is a user peer-to-peer forum. "Staff Member" is an honorific conferred by the forum software on Mods and indicates no other connection with Neosmart.
Are you saying that with the System Reserved partition set active and a newly added entry in the BCD on that partition that the Winload still fails with a BSOD ?
 
Terry60 said:
Are you saying that with the System Reserved partition set active and a newly added entry in the BCD on that partition that the Winload still fails with a BSOD ?
Click to expand...
Yes, it does. Regardless of whether I try to boot it by making System Reserved, Windows 10, or its own partition active, in all cases the same BSOD happens at the same point. Really strange, whatever happened did so to both the partitions in the same way at the same time. No, they are not clones of each other either! I think Windows 10 did something to them during its install that fouled them up.

I'll look for another forum about EasyRE to see if it has a feature to scan the registry and find the inconsistency causing this.
 
Back
Top