[INVALID] EasyBCD WinPE entry causes incompatible entries in BCD store

H

HT Slider

Member
My second potential bug is an odd one that I am having trouble trying to describe. I had the workstation operating properly after manually correcting the "partition=\boot" entry in {bootmgr} as discussed in this thread: http://neosmart.net/forums/showthread.php?t=8963. Then I used EasyBCD 2.1.1 (installed directly prior to doing this) to add a WinPE entry to allow the Windows Recovery Environment to function. I had "WinRE.wim" physically located in "S:\Recovery\" when I added the entry. Looking at the BCD store entries now I am fairly certain the new Ramdisk entries are not correct (or at least are not compliant with what Microsoft expects to see here). Prior to adding the WinPE entry I had not created any WinPE or Ramdisk based entries and EasyBCD did not show any either (although it is possible there may have been default Ramdisk "Device Option" entries that were unused and had been created by either a Vista or Windows 7 installation previously).

Probably the easiest is for me to include here a list of all items in the BCD store using the "bcdedit /enum all" command:

Windows Boot Manager
--------------------
identifier {bootmgr}
device partition=S:
description Windows Boot Manager
locale en-US
inherit {globalsettings}
default {default}
resumeobject {1f8184a2-14de-11df-9734-f08c6d8c50b0}
displayorder {default}
{current}
{bf887605-114e-11e1-bf6d-0011e002d9ed}
toolsdisplayorder {memdiag}
timeout 5
displaybootmenu Yes

Windows Boot Loader
-------------------
identifier {current}
device partition=C:
path \Windows\system32\winload.exe
description Windows 7 64-bit
locale en-US
recoverysequence {bf887606-114e-11e1-bf6d-0011e002d9ed}
recoveryenabled Yes
osdevice partition=C:
systemroot \Windows
resumeobject {dc35048d-ff66-11e0-8bed-806e6f6e6963}
nx OptIn
pae Default
sos No
debug No

Windows Boot Loader
-------------------
identifier {bf887605-114e-11e1-bf6d-0011e002d9ed}
device ramdisk=[S:]\Recovery\winRE.wim,{bf887604-114e-11e1-bf6d-0011e002d9ed}
path \Windows\System32\Boot\winload.exe
description Windows Recovery Environment
locale en-US
osdevice ramdisk=[S:]\Recovery\winRE.wim,{bf887604-114e-11e1-bf6d-0011e002d9ed}
systemroot \Windows
detecthal Yes
winpe Yes

Windows Boot Loader
-------------------
identifier {bf887606-114e-11e1-bf6d-0011e002d9ed}
device ramdisk=[S:]\Recovery\bf887606-114e-11e1-bf6d-0011e002d9ed\Winre.wim,{bf887607-114e-11e1-bf6d-0011e002d9ed}
path \windows\system32\winload.exe
description Windows Recovery Environment
inherit {bootloadersettings}
osdevice ramdisk=[S:]\Recovery\bf887606-114e-11e1-bf6d-0011e002d9ed\Winre.wim,{bf887607-114e-11e1-bf6d-0011e002d9ed}
systemroot \windows
nx OptIn
winpe Yes

Windows Boot Loader
-------------------
identifier {default}
device partition=V:
path \Windows\system32\winload.exe
description Vista 64-bit
locale en-US
osdevice partition=V:
systemroot \Windows
resumeobject {7fc8c9eb-ff75-11e0-902d-806e6f6e6963}
nx OptIn
pae Default
sos No
debug No

Resume from Hibernate
---------------------
identifier {7fc8c9eb-ff75-11e0-902d-806e6f6e6963}
device partition=V:
path \Windows\system32\winresume.exe
description Vista 64-bit
locale en-US
inherit {resumeloadersettings}
filedevice partition=V:
filepath \hiberfil.sys
debugoptionenabled No

Resume from Hibernate
---------------------
identifier {dc35048d-ff66-11e0-8bed-806e6f6e6963}
device partition=C:
path \Windows\system32\winresume.exe
description Windows 7 64-bit
locale en-US
inherit {resumeloadersettings}
filedevice partition=C:
filepath \hiberfil.sys
debugoptionenabled No

Windows Memory Tester
---------------------
identifier {memdiag}
device partition=S:
path \Boot\memtest.exe
description Windows Memory Diagnostic
locale en-US
inherit {globalsettings}
badmemoryaccess Yes

EMS Settings
------------
identifier {emssettings}
bootems Yes

Debugger Settings
-----------------
identifier {dbgsettings}
debugtype Serial
debugport 1
baudrate 115200

RAM Defects
-----------
identifier {badmemory}

Global Settings
---------------
identifier {globalsettings}
inherit {dbgsettings}
{emssettings}
{badmemory}

Boot Loader Settings
--------------------
identifier {bootloadersettings}
inherit {globalsettings}
{hypervisorsettings}

Hypervisor Settings
-------------------
identifier {hypervisorsettings}
hypervisordebugtype Serial
hypervisordebugport 1
hypervisorbaudrate 115200

Resume Loader Settings
----------------------
identifier {resumeloadersettings}
inherit {globalsettings}

Setup Ramdisk Options
---------------------
identifier {ramdiskoptions}
description RamdiskOptions
ramdisksdidevice partition=S:
ramdisksdipath \NST\boot.sdi

Device options
--------------
identifier {bf887604-114e-11e1-bf6d-0011e002d9ed}
description Windows Recovery Environment
ramdisksdidevice partition=S:
ramdisksdipath \NST\boot.sdi

Device options
--------------
identifier {bf887607-114e-11e1-bf6d-0011e002d9ed}
description Ramdisk Options
ramdisksdidevice partition=S:
ramdisksdipath \Recovery\bf887606-114e-11e1-bf6d-0011e002d9ed\boot.sdi

What concerns me is the fact that there are a total of 3 "Ram disk" entries and that 2 of them have identical GUIDs. In addition to this, there are a total of 3 entries for "boot.sdi" that include two different physical locations on the hard drive. I have looked in the "Recovery" folder (that I created when I copied the WinRE.wim file into it right before creating the new WinPE entry) and there is indeed two sets of identical copies of boot.sdi, one in \NST\ and the other in \Recovery\bf...ed\. I did not create the bf...ed folder, nor add any copies of boot.sdi myself.

Is EasyBCD supposed to create all of these confusing Ramdisk entries when a single WinPE entry is added? If EasyBCD does not do this and Windows 7 or Vista creates them in advance then why doesn't EasyBCD use one of the original Ramdisk entries instead of creating essentially duplicate entries?

Thank you again for making this incredibly useful utility.
 
Last edited:
Hi HT,

Thanks for this wonderful and detailed question. Seriously. I wish all bug reports were like your two posts today.

This particular post is *not* a bug, but it is very complicated.

  • There are no duplicate GUIDs. I fell into this trap myself too many times - Microsoft lies when they say these are GUIDs, they're actually carefully crafted id strings. The last digit in the first group differs between the two GUIDs that you thought were identical.
  • EasyBCD used to reuse the one, only, and same {ramdiskoptions} entry. It created it the first time if it didn't exist, and then reused it thereafter for all entries. However, Microsoft has a bug in their bootloader - the name of the PE entry displayed in the boot menu is the name of the associated ramdisk and not the name actually assigned to that entry. As a result, our users were seeing multiple PE entries all showing the name of the first one, but each would boot a distinctly different file. I am not aware that Microsoft has fixed this in newer versions of Windows (this was back in the days of Vista RTM), but even if they did, we must continue to use a workaround that works for both old and new versions of Windows that EasyBCD supports.
  • EasyBCD did not create the \Recovery\......\boot.sdi file. This was created by Microsoft during some voodoo action or the other.
  • EasyBCD creates multiple ramdisk entries in the BCD, but they all are associated with just the one \NST\boot.sdi file. So it's just extra meta data, no extra files on disk. There is one exception which is when using EasyBCD to create a PE entry when the boot drive is either or inaccessible then using it again when that is no longer the case - EasyBCD will create boot.sdi twice, once on the boot drive and once on an alternative drive. But that almost never happens, and it's not what you're seeing here.

I hope this answers your questions on this topic. WinPE support drove me up the walls with all the ridiculous chaining and bugs that Microsoft has in their system, I do not understand why it was designed the way it was.

Thank you for using EasyBCD.
 
Back
Top