EFIGuard Fails to boot. LoadImage Error 8000000000000E (Not Found)

[metazooa]

Hi, I tried to run EFI guard on a USB stick and it did not boot, then I tried to run it on a FAT32 formatted partition on one of my drives separate from my windows boot drive and it didn't boot. OS Win10 Motherboard Gigabyte z97x-UD3h-cf

It throws the error "LoadImage Error 800000000000000E (Not Found)" on each of my attempts to run it on the partition or USB stick.

Any help is greatly appreciated.

[Mattiwatti]

Hi,

The error you are seeing is caused by this call to LoadImage failing. I can't say what is causing this, as apparently the loader did find the file, and the driver has also been loaded successfully. It is the firmware that is failing the LoadImage call for the Windows Boot Manager.

Do you have EDK2 set up to compile the loader? If yes, you can try adding some debug code to print the path to the file that is failing to be loaded. First, comment out these two lines at L433:

//if (ConvertedPath != NULL)
//    FreePool(ConvertedPath);

Then, after the call to EfiBootManagerConnectDevicePath(), insert the following:

if (ConvertedPath == NULL)
{
    Print(L"ConvertedPath is NULL!\r\n");
}
else
{
    Print(L"ConvertedPath: %S\r\n", ConvertedPath);
    FreePool(ConvertedPath);
}
WaitForKey();

This will print the path if possible so you can see if there is something obviously wrong with it.

[metazooa]

I do not have EDK2 set up to compile; I will do that though and add those lines of code to see what happens. Which file would i add those lines of code to?

[Mattiwatti]

Loader.c.

If you don't get EDK2 to work I can probably attach a version of the loader with the change compiled in here, but I try not to attach binaries (especially ones that run in kernel mode) on Github issues if I can help it. Also note that this will only at best tell you what's going wrong, it won't fix anything.

[Mattiwatti]

Any news? Or do you need me to post a compiled binary here with the changes?

[ChocolateRustHax]

I had the same issue. When editing the NVRAM boot options you need to specify the full path to the loader file. For example:

bcfg boot add 4 fs2:\EFI\Boot\Loader.efi "EfiGuard"

Source: https://www.tonymacx86.com/threads/solved-uefi-clover-boot-option-gone-after-bios-update.211715/

[0xnobody]

Hey. I am also getting this error. I would debug this myself but I am unsure how to set up an EDK2 development environment... Can you provide me a debug build for this?

[gudenau]

I'm getting this error trying to use GRUB to boot this with a boot entry that I copied from the Windows one and edited to point to /EFI/Boot/Loader.efi.

insmod part_gpt
insmod fat
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//disk@0,gpt2' --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2  [possible UUID]
else
  search --no-floppy --fs-uuid --set=root  [possible UUID]
fi
chainloader /EFI/Boot/Loader.efi

[Mattiwatti]

@0xnobody: please try the attached Loader.efi: Loader-print-path.zip

[0xnobody]

@Mattiwatti I got the following print: It then hangs on this.

[Mattiwatti]

Thanks. The 'hang' is actually the loader waiting for a keypress (just in this binary) which I should have clarified, but it's not really important since it would have failed with the same error regardless. The main goal was to get it to print the device path that's failing to load.

BBS(HD,,0x0) is a legacy (BIOS Boot Specification) device path to a hard disk, in this case hard disk 0. This is presumably caused by your BIOS being set to 'UEFI + Legacy' mode (the exact name of the setting depends on the motherboard and BIOS, but this comes down to allowing both UEFI and BBS boot entries). Is your Windows installation actually a UEFI one? I can make the loader skip BBS entries, but this will only actually fix anything if the BIOS boot entry list looks like the following:

1. USB disk or other device used to boot EfiGuard
2. [BBS entry that is present in the list for whatever reason]
3. Windows Boot Manager (UEFI)

Please try this Loader.efi: Loader-ignore-BBS.zip.

This version should skip BBS boot entries, unless a fallback (non-Windows, or non-UEFI Windows) boot option is being loaded; in that case it will print a warning message. If this version still tries to boot BBS(HD,,0x0) I will need some more detailed photos of your BIOS boot entry configuration and/or the output of bcfg boot dump from the UEFI shell.

[0xnobody]

Hey. It seems I had EFI disabled on windows, enabling it fixed it! I'll let you know if I encounter this problem again. Just a suggestion: maybe print a warning if the windows version isn't running EFI. That would skip a lot of confusion for people not familiar with custom bootkits like myself.

[Mattiwatti]

Thanks for reporting back. Good to hear it's working now.

I agree that the error is not helpful, as evidenced by the fact that I myself didn't know what caused this until you showed the photo with the loader printing a BBS device path.

I will implement the following changes in an upcoming commit:

1. Make the loader print the device path it is booting. This changes nothing, but it simplifies debugging.
2. Skip BBS (non-EFI) entries on the first boot attempt (the one that tries to boot Windows).
3. Warn(?) if a BBS entry is being booted anyway, because this will only happen on the second boot attempt, i.e. the fallback/failure path.

With regards to (3), I'm not yet sure what the correct course of action would be here. Perhaps the loader should just abort entirely with an error, since the UEFI boot services LoadImage call can only be used to load EFI files (that's what causes the obscure 8000000000000E error in the first place). There is no alternative BbsLoadImage that I could use in this case.

Since presumably Loader.efi was started in order to boot Windows or at least a UEFI OS, I think it would be OK here to print an error, wait for a keypress and then return to the BIOS or boot menu. I don't really see any possible way this failure could be converted to a successful boot of a legacy device path, but I will have to look through the EDK2 sources some more to confirm this.

[Mattiwatti]

@gudenau: can you please verify if the cause of the error is the same for you as for @0xnobody (i.e. booting a non-EFI Windows)? I'm a little less certain about your case because hd0,gpt2 obviously is a GPT path. But on the other hand I'm suspicious about the passing of --hint-ieee1275='ieee1275//disk@0,gpt2' (IEEE 1275 is a specification from 1994), as well as --hint-bios together with --hint-efi.

It is possible (though quite rare) to have a disk that is both a valid MBR and GPT disk, with a legacy Windows installation on it. This is called a hybrid MBR. You can run EfiDSEFix.exe -i from a command prompt to see the firmware type to confirm which type your Windows installation is.

For reference, here is a working GRUB entry on a machine of mine that was generated by Gentoo:

setparams 'EfiGuard (on /dev/nvme0n1p2)'

    insmod part_gpt
    insmod fat
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root 36E9-0377
    else
      search --no-floppy --fs-uuid --set=root 36E9-0377
    fi
    chainloader /EFI/Boot/Loader.efi

Note 1: there is no set root='hdX,gptY' following the insmod statements. Note 2: the second if branch is completely the same as the first one, so I'm not sure why this entry was generated this way. Presumably you could just use a single search instead.

Here, 36E9-0377 is the serial number of the FAT32 EFI System Partition. In Windows you can find this as follows:

C:\Users\Matti>mountvol X: /S
C:\Users\Matti>dir X:
  Volume in drive X has no label.
  Volume Serial Number is 36E9-0377
  <...>

[Mattiwatti]

I've just pushed a commit which fixes this issue as far as it is possible for me to do so. The new loader behaviour is as follows:

• The device path being booted will now always be printed.
• BBS (non-UEFI) boot entries are ignored on the first boot attempt.
• On the second boot attempt (i.e. if no UEFI Windows was found), BBS entries are valid and will be booted correctly. This means that the vague LoadImage Error 8000000000000E message is gone. However, a warning will be displayed in this case since the EfiGuard driver can't actually work on these boot entries.

The corresponding binary release is v1.0.3 which I've made available on the releases page.