Full disclosure:
For years, we used to use VMProtect to protect parts of the code in the DLL.
We haven't been able to update VMProtect since shortly after the Ukraine war started due to the whole thing with US + Russia sanctions and VMProtect blocking US/UK purchasers from buying or updating the product. (VMProtect is created by a Russian developer, actually.)
We decided to move to another solution, Themida, for protection, which we did in the last update.
For the majority of users, this hasn't been a problem. The situations in which Ephinea doesn't launch with Themida are niche at best. e.g. Winlator on Android, Intel Mac with a launcher, etc.
I've got a Windows machine I can run VMs on as well as an M4 Mac that I can run VMs on, so I can set up a Linux build or whatever, if that works.
For me, my testing with DLL updates is generally: "Works on x86 Windows? Yep. Works on my M4 Mac running a Windows VM with free version of VMware Fusion? Yep. OK, ship it." Linux and whatever other setups are community supported and not something we, as the Ephinea developers, officially support. Even though Matt created a guide for getting things to run on Linux, Linux and other non-Windows setups are NOT officially supported by Ephinea developers, but we try to help get things going whenever possible.
That said, if anyone has a quick way to reproduce this issue that is somewhat easy, I can try to play with options that Themida has and see which one is causing the problem. I've already allowed the program to run under a VM, so it's not that.
Failing to get a quick reproduction going on my end, perhaps there is someone with one of these setups who may be available for me to test different compilations of the DLL with options toggled on or off to see if the error message goes away.
Will look into it further when I have either one of those things.