EasyBCD Anomaly: HP Z2 G5 Workstation (UEFI, non-SecureBoot)

FroggieTheGremlin

FroggieTheGremlin

Member
OK, I've read all the referenced documents and came back with this post...

Greetings! Have been using EasyBCD for eons both on Legacy/MBR and UEFI/GPT Systems. When moving to UEFI Systems, I use it mostly for adding WIM entries to my BCD without issue.

All of a sudden, when configuring a newish HP Z2 G5 Workstation (UEFI, Win10 IoT Enterprise LTSC), strange things are happening. When an installed app adds a BOOT menu entry, no problem with the BCD. When I try and add a WIM (WinPE) to the BOOT menu via EasyBCD, the addition goes well but the entry does not BOOT with the dreaded "Can't find device" error and the 0xc000000e error code. This has always worked previously with UEFI Systems. I look at the entry specs via EasyBCD and all looks like it always has.

I then tried something simple... I used EasyBCD to change only the entry name of the entry produced automatically by the app mentioned above. EasyBCD sees the entry name change, BCDedit also sees the entry name changed, but when BOOTing the System, the BOOT menu offered has the old original name when the entry was created... very weird.

It's almost like the BCD is in some protected mode (which I'm not aware of) although BCDedit and EasyBCD always see the same thing, exactly what I expect. This may be some "standard" System protection thing I'm not aware of (who knew?). Any help with this issue, greatly appreciated.

Am I possibly dealing with a strange UEFI firmware issue here...??
 
Last edited:
Sounds possible that the BCD you're editing is not the actual BCD which is being used to boot the system.
Check in Tools > Options that you don't have an entry in the "automatically load..." field.
Alternatively File > load system BCD should ensure you're working on the correct BCD.
 
Terry60 said:
Sounds possible that the BCD you're editing is not the actual BCD which is being used to boot the system.
Check in Tools > Options that you don't have an entry in the "automatically load..." field.
Alternatively File > load system BCD should ensure you're working on the correct BCD.
Click to expand...
Thanks for the response @Terry60 - no automatic load entries, on load System BCD, only get standard UEFI msg about some features not being available, other than that nothing unusual.

Did another name change for the heck of it... EasyBCD and BCDedit both see the change, System BOOT menu offered does not have change (still contains original "description" used by the app when it made the BOOT menu entry).

This is very strange... I just don't know what's going on.
 
I tried a 2nd installed app that also has the capability to add its own BOOT menu... it was successful in its addition to the menu (EasyBCD and BCDedit confirmed). EasyBCD also was successful in changinig that entry's name... BUT, still failed to run from the BOOT menu (as described in OP) whether after the initial addition AND after the successful name change.

A tidbit from the previous System (just replaced)... it was also a piece of HP hardware (UEFI) although built from scratch (same software specs as the Z2 G5) as far as software was concerned (no HP factory bloat). That System also had an anomaly (I think it was BiOS related but will probably never know). If the WIM image referred to in the EasyBCD entry was not on the OS disk, it would also fail to load from the menu with the almost exact same error as described in the OP. As long as the WIM referred to was located anywhere (any partition, hidden or not) on the OS-based disk, it worked just fine (had to relocate all my referenced WIM images to the OS disk to make it work)... tried that with this Z2G5 with no affect on the WIM load failures.

Other, non-HP Systems, work just fine with identical builds with WIM images located anywhere (any disk) on the System. With the previous HP System, it was like the only disk available at BOOTmgr time was the OS disk... and with this HP Z2 G5 its like none are available (which is not true 'cause the initial app added BOOT menu item works just fine). This is getting more like a bedtime story...:coldsweat:

See why I'm confused... :confounded:

PS- maybe with the newer versions of W10 there are some "newer" BCDedit commands that I'm not familiar with...??? (Guessing here... think I'll go back to school on this just to be sure)
 
Last edited:
Don't know whether this helps or not, the BCDedit image below shows two BOOT menu entries... the first added by the application itself. This is the one that has allowed me to change the "Description" in the BCDedit entry, but when the System BOOTs, the description in the BOOT menu is the original it was placed in with, not the changed Description you see in the image. This entry BOOTs fine.

The second entry was added by EasyBCD. It shows the Description I used. It shows up like this in the BOOT menu but does not successfully BOOT... gets the "Can't find device" message with the 0xc000000e error code.

There are some differences in each entry (unbeknownst to me)... maybe someone with a deeper knowledge of the BCDedit options may be able to make some sense out of this. Thanks for looking...

EasyBCD Test.jpg
 
@Terry60 - I'm getting close to this :laughing:. Quick question... when I use EasyBCD for WIM additions to the BOOT menu, EasyBCD seems to select a random partition to create the NST folder needed to house the SDI file used in the BOOT directives. What decides this partition selection, and more importantly, how can I change that DEFAULT location, if needed?

Thanks for your help with this... I may be at the answer soon :sleeping:
 
OK, haven't heard anything concerning EasyBCD's assignment of the NST folder... so here goes what I've found to date.

This issue appears to affect HP OEM machines only... most likely a BiOS issue (I can't see anywhere else that may affect these anomalies). I've never encountered it elsewhere on any other machines (self built, DELL, Alienware, etc.) and have encountered it on both 4th gen and 9th gen iCore-based HP Systems (6-yrs apart, not bad:grimacing:). Lately I've only been using EasyBCD to manage WIM entries in my BOOT menu due to UEFI restrictions on multi-BOOT Systems. Here are the specifics...

1. If both the BOOT Loader AND the DEVICE OPTIONS Entry (SDI directives used by the WIM entry) are located in the lettered OS partition (C: to be precise), the BOOT option is successful. If either of the above are located on any other lettered partition (using EasyBCD directives <only lettered options are available>), the EasyBCD BOOT entry will fail. Since I find EasyBCD always creating (and invoking) the SDI directives file from its own NST folder on my D: partition, any WIM added BOOT option on this System fails, even if the WIM is actually located in the C: partition.

2. If both the BOOT Loader AND the DEVICE OPTIONS Entry are located on unLettered partitions, the BCD BOOT entries are successful. I used EasyBCD to create my BOOT entries (5 of them) from a separate lettered partition, then removed the partitions letter from the System. Using EasyBCD to look at the BOOT list, it now shows the WIM image location as \Device\HarddiskVolume<n>, a specific disk/partition instead of a lettered device. If I change the DEVICE OPTIONS Entry (via BCDedit or Visual BCD) and place the SDI file entry on the same previously lettered (now unlettered) disk, the EasyBCD BOOT entry works just fine... probably will work also on any unLettered disk at BOOT time as well (I'll check).

From the above testing, it appears the HP System(s), at BOOT Mgr time, don't understand any partition lettered references (except C: which may be some sort of default for OS location)... that's why the dreaded "Can't find device" error when using DEFAULT EasyBCD entries. If the BCD entries, at that time, use a reference to a specific disk/partition instead of a lettered device, all seems to work just fine.

That's the reason for the question above about EasyBCD's NST folder location... If I can control that, then I can then locate both by WIM files (and the EasyBCD SDI directives) on my OS partition (C: ) and just use the EasyBCD tool normally with those restrictions. Anyway, that's where I'm at with this conundrum...
 
Well, it seems there exists very little developer/user interest on this Forum concerning the unusual problem I'm experiencing. Although a simple method of locating EasyBCD's NST folder is not forthcoming, I'll have to move elsewhere to try and find an easy workaround for this problem. Thanks to @Terry60 for the initial suggestion for a possible fix... sorry it didn't work out. See y'all around on the infobahn!
 
Sorry I've been away a while.
Reading back
FroggieTheGremlin said:
a reference to a specific disk/partition instead of a lettered device, all seems to work just fine.
Click to expand...
There are no letters in the BCD. It uses a UID which is a hash of the unique device serial number and the partition offset on the devce.
Since that is extremely user unfriendly, EasyBCD translates that UID into a letter for you by reference to the running system's registry device map. This works the other way round too. When you point easy BCD to a letter, it uses the same map to create the proper UID when writing the BCD entry. This is why you must always use letters as the currently running system sees them, not as you expect them to be when the OS is booted.
It makes no difference if you remove the letter from the drive, the BCD entry is identical. The only difference is EasyBCD can no longer translate it into a letter for you because you've altered the registry map.
I suspect the problem is that HP is using a customized version of bootmgr to handle its own recovery/factory reset options as well as the "normal" boot and that is failing to do what MS bootmgr regards as normal, which EasyBCD complies with.
Sorry not to have been any real help.
 
I've never used WIMs, but in the days when I was Quad booting XP, Vista, W7 and Ubuntu, I know that EasyBCD placed the chaining files it created to effect the boot, on the drive where they had to be for the boot process to be able to succeed. I imagine that's still the case, but the author( mqudsi) is the only one who could confirm or deny that.
 
Back
Top