Disabling the flag may or may not be the right solution, but the first thing is to understand exactly why that flag is breaking your app. Filing a bug would be a good first step.

Disabling the flag is how we need to fix this for older DLLs on MSVC and mingw.  Can you help me understand what the purpose of a bug report to winehq is? I certainly don't mind writing one, but this issue is "solved" for other DLL compilers.

Quoting the PR-thats-leading-to-burnout from our gracious user:

> "Address Space Layout Randomization (ASLR) is a security technique that randomizes the location of several key memory areas in order to make it harder to use memory corruption exploits (Wikipedia). Sadly, several old VST dlls crash when ASLR is in use (see bug #7830). This PR adds linker flags to disable ASLR when building RemoteVstPlugin Windows executables. The main program (lmms.exe) is still built with ASLR enabled"

Note that this regression aligns with both mingw AND wine addition of DYNAMICBASE features.  Finding this regression actually FINALLY allows these VST plugins to work with MSVC which they never have before, so we're actually very excited about this flag.  What's hard for me to speak on behalf of -- please accept my apologies here -- is that I'm not a very "good" C/C++ developer despite my tenure on the LMMS project -- so, if this crash could be avoided through other means I'm not sure, however I'm also not sure how far down the rabbit hole we would need to (or should?) go for this to be properly explained (nor whether or not I'm qualified to understand or explain this).

LMMS has an external plugin system, we load a plugin for handling the IPC stuff and that plugin -- which we call RemoteVstPlugin[32|64].exe -- is responsible for starting and interacting with the DLL.  In the case of the Synth1 instrument mentioned in an earlier email, the plugin plays a single note fine, but crashes when a second note is played.  Using a debugger on this is difficult due to the the lmms -->  remote plugin --> vst plugin, however as a project maintainer, I trust and follow the findings of this musician/developer helping.

The TL;DR of this is in our Discord #dev-forum thread here: https://discord.com/channels/203559236729438208/1383830615429877851 (invite link available via https://lmms.io/chat) where the OP and I have spent weeks trying various things to isolate this regression.

Mingw even mentions the possibility of this breaking things in their changelog, quoting:

https://www.msys2.org/news/#2021-01-31-aslr-enabled-by-default

> 2021-01-31 - ASLR enabled by default 
> 
> About 5 months ago we started backporting patches to our binutils 2.35 to allow enabling ASLR support via various flags. We also enabled these flags in our build system, so any package in our repo that was updated in the last 5 months has ASLR support enabled.
> 
> We've now updated to 2.36 which has ASLR enabled by default. Ideally you shouldn't notice any changes, but in case this leads to problems all of it can be disabled/reverted via linker flags:
> 
> mingw64: -Wl,--disable-dynamicbase,--disable-high-entropy-va,--default-image-base-low
> mingw32: -Wl,--disable-dynamicbase 
>  
> Note that this is only a temporary workaround and some of these flags will not be available forever, so you should either fix your code or file a bug in case you suspect a toolchain issue.

As an argument AGAINST this flag for winebuild, mingw DOES warn against this flag as being a candidate for future removal, however since MSVC makes no mention of removing this build option on the Windows-side, I'm hopeful that mingw mimics Microsoft's lead on this platform.

https://learn.microsoft.com/en-us/cpp/build/reference/dynamicbase 

I'd be happy to write-up a bug report if you think it's helpful, but I'm not certain I'll have PE (or even LMMS code) knowledge needed to "explain why this flag is breaking our app" aside from the high-level fact that these DLLS we talk to are often older than Vista when this feature was added.