Windows 11 boots on v1.33 but fails with "Synchronous Exception at 0x0000000036BDAAF4" on v1.34

[Botspot]

For the past several days I've been rewriting WoR-Flasher to not rely on uupdump anymore, but in tests I could not get the sd to boot at all.
Turns out that downgrading the uefi bundle link from:
https://github.com/pftf/RPi4/releases/download/v1.34/RPi4_UEFI_Firmware_v1.34.zip
To:
https://github.com/pftf/RPi4/releases/download/v1.33/RPi4_UEFI_Firmware_v1.33.zip
Solves the problem.

On UEFI firmware 1.34, the startup begins, and after 2 minutes or so, "Synchronous Exception at 0x0000000036BDAAF4" appears on the screen.

Since your 1.34 release has been out for a week now, I would have expected someone to report this issue on my wor-flasher repo. But maybe everyone is not getting that far due to uupdump's continued API outage.

In any case, I would be grateful for any troubleshooting and bug investigations for this. For now, I suppose I will force wor-flasher to use your 1.33 release.

[Botspot]

Has anyone else been able to reproduce this? It is getting to be pretty annoying to make all WoR users use an outdated version of your firmware. Ideally, this bug can be reproduced, isolated in the changes between 1.33 and 1.34, and then fixed for future versions.

[TheMindVirus]

#97 - looks like this came back
v1.33...v1.34 - looking at the diff, any number of things could have caused it
tianocore/edk2@79f2734...0adc35f - most probable is this failed automatic merge from edk2
tianocore/edk2-platforms@958fc02...20e0709 - but edk-platforms looks ok

[KeepNaivety3]

Had the same problem.
I use Rufus to write a CentOS Stream 9 image in a USB flash drive, and "Synchronous Exception at 0x00..." appears when using the latest v1.35 UEFI Then use the same USB flash drive to change to v1.34 UEFI and it can be installed normally.

[somemarco]

I had now a similar issue with Fedora CoreOS 38 redeploy (SD Card), which in combination with v1.35 gave the "Synchronous Exception at 0x0000000033858000". With v1.34 it previously worked and after reverting back to using v1.34 the boot again succeeds.

[Dingoldine]

Same Issue and when reverting to previous version v1.34 it boots correctly

[pbatard]

Note that the issue above is only about WIndows 11 booting with 1.33 but failing with 1.34, so please do not use it to report an unrelated issue with Linux not booting with 1.35 but booting with 1.34, as these two issue clearly have nothing in common (since in one case someone is saying 1.34 is the one that doesn't work for them and in the other someone is saying 1.34 is the one that works for them).

Please use #235 if you want to report an issue about 1.35 failing to boot where 1.34 worked, thank you.

And also, if you used DeviceTree, please test with ACPI and report in #235.