Lmms: ZynAddSubFX won't open GUI in rc7

[EtornaZ]

This just happened to me yesterday, It started when I opened a project and tried opening one of the Zyn synths in the project. LMMS froze up for a few seconds before unfreezing and not letting me play notes in the piano-roll in LMMS. However, once I clicked the "Show GUI" button again, it let me play the synth, but it had reset itself.
Now it's doing this whenever I try opening any instance of Zyn in LMMS.

[musikBear]

OS ?
Cant reproduce on winxpSP3

[EtornaZ]

I'm on Windows 10

[GingkathFox]

Zyn does something like that to me sometimes, though as far as I know it opens fine. Sometimes when playing a melody in the PR or SE and clicking "Show GUI" in Zyn at the same time, LMMS will freeze for a second and either:
Open Zyn properly with no errors, or
Open Zyn with the preset reset to the default.

[musikBear]

Oh wait - have you @EtornaZ looked in the 'tray' (alt+TAB)?
Zasfx will sometimes open the GUI in tray, and it has to be 'brought up' with a click inside tray'ed programs. Was that it?

[EtornaZ]

@musikBear Just tried it and it didn't work.

[DomClark]

Can you try opening the Zyn GUI, open Task Manager, go to the "Details" tab (you may need to click "More details" first if you don't have any tabs), and see if there is a "RemoteZynAddSubFx.exe" process running?

[DomClark]

Is this after opening the project mentioned in #4677? The Zyn GUI uses a separate process so I could see it being related.

[EtornaZ]

@DomClark Yes, that is when it started.

When I open Zyn, the task manager shows this for about a second.

Then that disappears and Zyn acts like I said above.

[DomClark]

In that case I would guess that this is fixed by https://github.com/LMMS/lmms/commit/2569760b869dfb9ddac4fe9a68b9b7838975e42a. Do you still experience this issue in rc8?

[EtornaZ]

Yes, I do.

[musikBear]

the extreme low-tech guess...
It is open, but it is out of view -Far to the right on your HiRes screen.. (?)

[DomClark]

We finally found the cause of this after some lengthy discussion on Discord.

Another application had installed a version of zlib1.dll into C:\Windows\System32, which was loaded instead of the version that ships with LMMS. This alternative version used a different CRT DLL to that of ZynAddSubFx, so the two CRTs had different file descriptor tables. Zyn opened a file using _wfopen, then passed that file descriptor to gzdopen from zlib, which passed it to lseek from the other CRT. This other CRT didn't recognise the descriptor, so aborted with STATUS_INVALID_CRUNTIME_PARAMETER.

We got Zyn to work again by removing the offending zlib1.dll, but this is not an ideal solution as it may cause problems for whichever program put it there in the first place.

This bug occurs because we get Zyn to load zlib by setting its current directory to LMMS's root install directory when it is launched. Windows prefers to load libraries from the system directory over the current directory for security reasons.

Possible workarounds:

• Disable SafeDllSearchMode via the registry, which causes the Windows XP and earlier behaviour to be used for loading libraries, which prefers the current directory over the system directory. I think this is a bad idea as it impacts the security of the whole system.
• Keep Zyn and zlib (and possibly other required libraries) in the same directory; either we put a copy of the libraries in plugins, or put Zyn in the root LMMS directory.
• Use a manifest file to instruct Windows to look for zlib in the correct directory.
• Link zlib statically rather than dynamically.