Windows 11 Education Version 21H2 BSOD on "EfiDSEFix.exe -d" command

[MelindaJaphines]

When performing the EfiDSEFix.exe -d command I receive a BSOD with error code: attempted_write_to_readonly_memory What failed: Cl.dll

Eventviewer says this: The computer has rebooted from a bugcheck. The bugcheck was: 0x000000be (0xfffff8050e2bd004, 0x89000008a8820121, 0xffff8006f7b17450, 0x000000000000000b). A dump was saved in: C:\Windows\MEMORY.DMP. Report Id: c1bc6544-9a0e-4540-89ba-20945cecf27e.

I have managed to get it working on several Windows virtual 10 machines, however on my Windows 11 Education host, it appears to fail.

Thank you very much for all your effort, and for looking into this.

[Mattiwatti]

Hi, sorry for the delay but this took some time to look into and reproduce.

0xbe is indeed ATTEMPTED_WRITE_TO_READONLY_MEMORY like the message says. The message also says that CI.dll is what failed, but this is poor wording since in this case the correct interpretation is more along the lines of 'the failing write was targeted at an address in CI.dll'. Since g_CiOptions resides in a writeable section and not .rdata, this doesn't quite make sense unless the target address finding/calculation of g_CiOptions in EfiGuard is wrong, which I don't believe is the case here.

However... your machine is also the host of several VMs, which I'm going to assume here implies it's running as a Hyper-V partition. Why is this relevant? Because this means it is itself a guest of the root partition, and that (if I'm right about the cause, which I believe I am) the CI.dll loaded by the 'host' (to you - but really it is also a guest) is asking the root partition (i.e. the real VMM) to apply this write protection to a R/W section after the initialization of g_CiOptions is complete and the value can be made read-only.

I can't yet say whether it is possible to fix this - I think the answer is probably yes, but doing so will require adding a fairly significant amount of code to target and patch CI.dll specifically which was not previously needed. However note that if it is possible to patch this in EfiGuard, then that is only because of (frankly) incompetent design on MS' side of the API CI.dll uses to request this page protection, not any real weakness of the hypervisor. As such you should keep in mind that any potential fix for this can be trivially wiped out in a future Windows update.

How to check whether I am right about the cause:

1. Run bcdedit /set {current} hypervisorlaunchtype off in the host and reboot. NB: this will prevent Hyper-V from starting and make it impossible to launch VMs until reverted.
2. Run EfiDSEFix -d and observe result.
3. Run bcdedit /set {current} hypervisorlaunchtype auto and reboot to restore the original behaviour.

If the machine still crashes in (2), that means I'm wrong about the cause and I will need the crash dump file to investigate further. However if I am right it will not crash. This obviously doesn't help you much since in this configuration you won't be able to start VMs, but it will help me in determining whether this can be fixed and if so how.

[MelindaJaphines]

Hey Matthijs

Thank you for you reply.

I can confirm it works when Hyper-V is disabled.

Since I will not be needing Hyper-V in the near future, this works perfectly for me. Thank you once again!

Kind regards Melinda

[Mattiwatti]

This has been fixed in 2f4a666, which makes it so that VBS will be disabled during boot if the EfiGuard DXE driver was loaded.

Hyper-V is unaffected, so if you want you can remove the workaround in order to be able to use Hyper-V again: bcdedit /deletevalue {current} hypervisorlaunchtype