ASSERT_EFI_ERROR (Status = Invalid Parameter)

[james090500]

I was told to report the ASSERT error here because "even if it’s user error, it should properly prompt an error or halt".

I mostly assume i've done something wrong but wont hurt to post this.

Specs CPU: Xeon E5606 RAM: 8GB

opencore-2021-02-06-123800.txt EFI.zip

[vit9696]

Hi. Yeah, this clearly looks like a bug on our end (some memory is tried to be freed that is not allocated). It should not crash like this. However, it is not possible to determine the location with just this log, so your help is needed, most likely involving running some test builds to produce more logs to determine the problem.

If you are up to this, could you tell me a bit more about what you are trying to do:

• This looks like a VMware-like hypervisor trying to boot a dmg recovery, is it right? Could you tell me about the versions for both?
• How much memory is the VM assigned? Does increasing RAM help?
• Could you try to load the DMG recovery for macOS 10.15 or macOS 11 and provide me the log?

[james090500]

Thanks for getting back to me. I am happy to do anything to see what we can do.

Yes, I am running an extremely unsupported environment here but just trying to see how far I can actually get. Mentally prepare yourself...

I am running Hyper-V on Windows. The Host has 44GB of RAM and 8GB of that is statically assigned to the VM. Increase/decreasing memory doesn't help unfortunately. However setting the memory before about 4500MB results in a verbosed error. OCB LoadImage failed - Unsupported

This is further than it previously got. I can try with 10.15 and 11 a bit later this evening or tomorrow. I have attached a log of booting the VM with 4096MB of RAM which seems to help a bit.

opencore-2021-02-06-185610.txt

[vit9696]

Yeah, there is no point in reducing the memory size, it dies earlier actually with an out of memory report. Provide a log with 11 dmg, and I will see what more prints I need to add to figure this out.

[james090500]

Attached both with relevant names

Catalina-10.15.txt BigSur-11.txt

[vit9696]

Okay, here is a build with more logging added. Please replace your OpenCore.efi and redo the log with 11. Please make sure that AppleDebug = YES is set. I will not promise this one will be enough to locate the bug, but I added relevant prints. Please let me know how it goes.

OpenCore-LT-r1.zip

[james090500]

Hope this helps! opencore-2021-02-06-215307.txt

[vit9696]

A bit confused, try this one (also need logs). OpenCore-LT-r2.zip

[james090500]

Here you go opencore-2021-02-06-222543.txt

[vit9696]

I found and fixed one bug with this code. However, I am quite unsure whether this is the one you observe. Yours might be a bug in the firmware itself. In addition to fixing the issue I also added even more logging.

OpenCore-LT-r3.zip

[james090500]

Hope this helps. opencore-2021-02-07-132509.txt

[vit9696]

It really makes no sense. We allocate and what we allocated is freed by us soon after. Yet the firmware reports it is an anvalid tree. I kind of get it that there may be some memory corruption, but to me it sounds like a memory corruption outside of OpenCore.

[james090500]

Hm, I'll do a memtest to check. That might explain why lowering the ram doesn't crash opencore

[vit9696]

Not sure it is a hardware issue actually. Lowering the RAM makes OpenCore stop earlier due to not enough memory. Here I would say a bug would be in the firmware code rather than hardware. Maybe try to understand what exactly breaks it at least. Try this version. It will likely error differently. include the log.

OpenCore-LT-r4.zip

[james090500]

Here's the log, I've also shutdown any VMS just incase

opencore-2021-02-07-144400.txt

[vit9696]

Okay, what about this one?

OpenCore-LT-r5.zip

[james090500]

Ok we've got a much different error.

opencore-2021-02-07-151854.txt

[vit9696]

So, EFI_BOOT_SERVICES::GetMemoryMap on your side somehow corrupts the allocated memory. Now the question is what can we do to it…

[vit9696]

Maybe try to increase the reserve :x Try this one. Need logs.

OpenCore-LT-r6.zip

[james090500]

Here you go

opencore-2021-02-07-155231.txt

[vit9696]

What about this?

OpenCore-LT-r7.zip

[james090500]

Sorry for the delay on this one opencore-2021-02-07-161048.txt

[vit9696]

Np… But I am out of ideas for the time being. We simply call the firmware, and it overwrites random data out of bounds @_@. I will provide some build to try to diagnose it in a better way later, but there hardly is a way to deal with such an obvious firmware bug.

[james090500]

I'm no expert with any sort of UEFI booting. I have done some googling of "GetMemoryMap and Hyper-V" and some bug reports of different Linux having to do some patches. Not sure if any of that could help?

Hopefully you'll figure something out xD

[james090500]

Just a random update. Installed Hyper-V on my Windows 10 PC and I actually get much further. It starts calling the Kernel. See log attached. The biggest different (aside from the hardware) is this is Hyper-V config version 9 where as the other machine has 8.

https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/upgrade-virtual-machine-version-in-hyper-v-on-windows-or-windows-server#supported-vm-configuration-versions-for-long-term-servicing-hosts

opencore-2021-02-07-202655.txt

[chilledHamza]

I have same error with Debug version on my Haier Y11C laptop, here is the log opencore-2021-02-07-214439.txt

Actually, I get black screen (with boot chime being played in a loop) when I enable OpenCanopy with PickerMode : External property. I have unlocked BIOS, so if I enable CSM. OpenCore menu is shown but it's really slow and laggy. Enabling CSM isn't right solution anyway. With OC v0.6.5 I fixed by setting Resolution : 1366x768 (max resolution of internal display), and it worked well even with CSM disabled. updated to OC v0.6.6, issue is back now and even Resolution property have no effect now. that's the reason I went for Debug version to check logs and ended up with this ASSERT_EFI_ERROR I understand that I should create separate issue for Black-Screen, just trying to state whole problem and actually I didn't get positive response from my last reply Keypad. on Lenovo Y530 doesn't work #303.

I didn't get this ASSERT_EFI_ERROR once, so here is the log if you need it. with Resolution : Max opencore-2021-02-07-215002.txt

[vit9696]

Just a random update. Installed Hyper-V on my Windows 10 PC and I actually get much further. It starts calling the Kernel. See log attached. The biggest different (aside from the hardware) is this is Hyper-V config version 9 where as the other machine has 8.

Hmm, in this case I would rather leave this unchanged on our side. Basically "a fix" would be some hack workarounding a firmware bug. We do add such hacks, but mainly for real firmwares. If the firmware is software only and the bug is fixed in a newer release, it is better to leave it unmodified on our side.

At this step it is clear that older Hyper-V within the call to VmAllocateMemoryPool inside OcGetCurrentMemoryMapAlloc corrupts the pool allocated memory as soon as GetMemoryMap is called, making this memory no longer available for free. You can probably workaround it by changing FreePool here to gBS->FreePool, simply ignoring the memory corruption, but I do not want to merge it.

[vit9696]

@chilledHamza your PS2 issue was forgotten about. Sorry. Replied.

As for ASSERT, it is not in the log, so we need a photo. Create a separate issue for it.