23 May 2020 Client does not work with AMD SVM enabled

Some questions are better left unanswered. I also need to run the client in a virtual machine, currently tinkering with different versions of Windows 10 on the guest.

 

By some divine act I can run that version of Legends even with Virtualization enabled on an AMD based chipset and socket (X399, TR4), on a host level.
I did have troubles earlier running Legends inside a VM which seems to add up with the thread.

 

Thanks!

WIndows 10 LTSC 2019 - don't tell Microsoft probably closest thing would be Enterprise or Pro

 

Windows build 2004 killed my whole system, making me reinstall everything.
It seems maplelegends runs fine without docker installed and SVM enabled, but it's when docker is installed things change. I've used WSL2 this time around over hyper-v, hoping it would change anything, which sadly wasn't the case.

Disabling docker doesn't solve it either, although perhaps there is a way to disable WSL2 without the reboot hassle

 

Tinkered a tad around with various other sources of information on using legends in a VM, which led me to Regedit edits. These edits are only useful for when one is in an actual VM, but checked them out nonetheless. Found some threads from 2012 if not videos, but all failed to solve the problem still.

Disabling all hyper-v related services from automatically starting also failed thus far, but I did see that by using bcdedit hyper-v is set to automode despite never enabling the hyper-v function.
Perhaps this may offer a solution to some, as this method was mentioned earlier; making a second boot entry with hyper-v disabled.

I am rather certain a new version of ijl15.dll will solve the problem and hope the new client will just do that, as the previous version was working fine. In fact, if one replaces the customised ijl15.dll with a version straight of Intel, the game will attempt boot fine without any virtualisation issues. It's just that maplelegends requires the custom checks to boot.

I've no clue what check generates a false-positive, even tried to change the default PC name just in case that may have been the trigger. I simply hope this will be solved soon, as rebooting after a workday is tedious.

 

The latest patch booted without any BIOS changes required (virtualisation still enabled, docker running on WSL2)