HookedBootManagerImgArchStartBootApplication doesnt get called

[NMan1]

Hello, first off thank you for this project. I'm experiencing an issue where the StartBootApplication hook doesn't get called. I'm using Loader.config.efi with option 1 (no dse) as my goal is just to disable patchguard. I did this same process a week ago and everything worked fine now today after multiple attempts the output never gets passed "Successfully patched bootmgfiw!ImgArchStartBootApplication".

I've tried using the normal loader (Loader.efi) and the same thing happens.

[NMan1]

Fixed. This issue occurs when I use the shutdown option (or physical power button on my pc) instead of the restart option which fully clears memory and refreshes the kernel.

[Mattiwatti]

Hi,

This actually does sound like a bug to me, so I'm reopening the issue for now at least until I get a better picture.

To be clear: the issue (HookedBootManagerImgArchStartBootApplication not getting called) only happens when you shut down, but does not occur when you restart from within Windows? Because that's how I'm reading your second post, but I'm not sure I can make sense of that one. A stale, previously patched, bootmgr/bootmgfw being reused in the reboot process could perhaps explain this issue (although that also should not happen since EfiGuard's hooks remove themselves after completion), but a failure that only occurs after a full shutdown is somewhat baffling to me.

Can you post the specs of your PC (most importantly the motherboard model and its exact BIOS version)?

[NMan1]

You described the issue correctly. Specs:

Processor: i5-8400
Motherboard: Z370-A PRO
BIOS version: 7B48v24

[Mattiwatti]

Sorry about the lack of response, as you may have guessed I don't really have a clue what this might be, however...

It just occurred to me that something very similar, if not exactly the same, has happened to me in the past on one of my systems, which is Intel Z790-based (Asus Prime Z790-P D4). This was an issue I actually spent quite a lot of time on diagnosing and bisecting to find the culprit, and I eventually tracked it down to a change in the TianoCore edk2 repository(!), not EfiGuard. (502c01c5028038e4e6b4512e9c66be0ec4d11492 to be precise.) Furthermore, the issue now also seems to have been fixed in edk2, though I don't know in which commit.

When I made the current v1.3 release, I made sure that it was compiled with a version of edk2 without the guilty commit, and I can no longer reproduce my issue on the Z790 system using v1.3 (which was released after you created this issue).

So my question is: is your issue the same as my issue? If it is, v1.3 will have fixed it. If not, I'm back to having no idea what this could be.