EastWest 'Play' VST Crash/Hang

Audio Plugins
1

Hey, Juce people, with a special hello to those of you developing VST hosting apps on Windows.

I’ve been having an issue with the EastWest ‘Play’ VST plugin (Version 2.1.1 of play_VST.dll) on Windows. It hangs my current app, and simply shuts down the Juce example plugin host app (juce/extras/audio plugin host).

I’m building the Juce example host app out of a juce folder fresh from the git tip at of this morning 05.23.2011, 10:30am CSD.

I can debug to the call to LoadLibrary() from within my app. Trying to step over this call hangs the process:

AudioPluginInstance* VSTPluginFormat::createInstanceFromDescription (const PluginDescription& desc)
{
...
     const ReferenceCountedObjectPtr <ModuleHandle> module (ModuleHandle::findOrCreateModule (file));

static ModuleHandle* findOrCreateModule (const File& file)
{
...
     f (! m->open())

bool ModuleHandle::open()
{
...
     hModule = PlatformUtilities::loadDynamicLibrary (file.getFullPathName());

void* PlatformUtilities::loadDynamicLibrary (const String& name)
{
...
     result = LoadLibrary (name);

HANG.

When I hit pause in the debugger I get an Alert dialog from Visual Studio which states:
“The process appears to be deadlocked (or is not running any user-mode code). All threads have been stopped.”

When I attempt to load this plugin with the Juce example host, I see the same behavior, except instead of a hand, the app simply exits.

The thread ‘Juce DSound’ (0xe50) has exited with code 16 (0x10).
The thread ‘Win32 Thread’ (0x10e0) has exited with code 16 (0x10).
The thread ‘Juce Timer’ (0x2e4) has exited with code 16 (0x10).
The thread ‘Win32 Thread’ (0x320) has exited with code 16 (0x10).
The thread ‘Win32 Thread’ (0x1014) has exited with code 16 (0x10).
The thread ‘Win32 Thread’ (0xd30) has exited with code 16 (0x10).
The program ‘[3756] Plugin Host.exe: Native’ has exited with code 16 (0x10).

My app from last year, before I switched to Juce VST hosting, does not have an issue with this plugin. Neither does any other host app that I’ve found to test with.

I have gone over my code many times, but have not been able to find any leads. Since the Juce example plugin host is also having problems with the play_VST.dll, I’m thinking this probably isn’t a result of my code. Has anyone else seen this issue?

This is especially interesting, since elsewhere on this forum it is mentioned that the EastWest Play plugin is built with a qt interface around a Juce engine.

2

Are you sure it’s not crashing deliberately because of some kind of anti-debugging copy-protection code they’re using?

3

That’s one of the first things I thought of, as I have vivid memories of dealing with Themida in Native Instruments’ products, which prevents them from loading if a debugger is detected running on the system. This makes it a huge PITA to debug host/plugin issues.

This EW Play issue, however, is reproducible with a release build on a machine that doesn’t even have a debugger installed, let alone running.

4

Hi,

Sorry for late reply… I’m not a regular visitor around here :oops: , and this issue has been brought to my attention just last week.

XiGo, what version of juce do you use? I’m guessing it’s 1.52 or newer right? I can reproduce this problem here with juce example host from 1.52 and 1.53, but the one from version 1.51 works fine (no crash when loading Play VST). The problem seems to be related to PACE protection we are using. “Raw” builds of our plugin work fine, but as soon as we wrap them with one of the PACE tools, things fall apart with juce host (we can’t reproduce the problem with other vst hosts, we also haven’t received any other complains about similar problems happening on user systems). I’ve reported this to pace support, but Jules, can you think of any changes between 1.51 and 1.52 regarding vst dll’s loading that could affect this ?

cheers,
Bart :wink:
EastWest Sounds

5

Wow, that’s a tough question - it’s far too long ago and far too many changes to be able to think of anything, I’m afraid!

6

[quote=“jules”]
Wow, that’s a tough question - it’s far too long ago and far too many changes to be able to think of anything, I’m afraid![/quote]

Yeah, I’ve tried to get through a git log and see if I could spot something, but uhhhh… so much stuff happened between these two releases 8)
I just thought, that it may “ring a bell” for you or something :wink:

cheers,
Bart :wink:

7

No luck on my end with this issue, and moving back to Juce 1.51 isn’t an option. Looks like I’ll be needing to block plugins that are post 1.51 Juce based and using PACE Anti-Piracy. This calls for a sad face emoticon. :cry:

8

One of the weird things I noticed is that I get crashes with juce example host + PACE protected plugin only with the prebuilt hosts (which are available in extras/prebuilt folder in juce source code packages or on sourceforge) for juce versions 1.52 & 1.53 (1.51 one works fine). If I rebuild the host (no matter from which version/git revision) it works perfectly fine. I’m using visual studio 2005 with updates KB926601 + KB932232 . Jules, can you reveal with what visual studio version those prebuilt host applications are compiled with (and if 1.51 and 1.52 were build with the same vstudio version) ?

cheers,
Bart :wink:

9

I’ve been mostly using VC2008 for building things like that. It’s all very odd - this must be some dodgy anti-hackery bodge that the PACE drivers are doing. Maybe they have some kind of heuristic that looks at which system DLLs the host app links to, and blocks hosts that could call certain functions?

10

Here’s what I’m finding with Juce 1.53’s extras/audio plugin host:

Build with Visual Studio 2005 using the VisualStudio2005 project: successfully loads play_VST.dll
Build with Visual Studio 2008 using the VisualStudio2008 project: crashes on attempt to load play_VST.dll
Build with Visual Studio 2010 using the converted VisualStudio2008 project: crashes on attempt to load play_VST.dll

This is on a 64bit Windows machine running Vista Business w/ SP2.

Project settings issue? I’ll start poking around and see if I can scare anything up. If anyone else has any ideas, please throw them at me. I’m far from a Visual Studio project settings expert.

11

On the suggestion of a 3rd party developer involved in this issue, I changhed my VS2010’s NXCOMPAT project setting.

Project Property Pages -> Configuration Properties -> Linke -> Advanced -> Data Execution Prevention (DEP)

Switching to /NXCOMPAT:NO seems to fix the problem.

I built the Juce Example Host off of Juce 1.53 using VS2010 and was able to load and use play_VST.dll.

Next step, to try my app with this project setting and hope there isn’t any unexpected fallout.

Thank you, 3rd Party Developer Involved With This Issue!

12

Jules, can you please, please fix this ASAP. It still crashes on Windows 8 in 32 bit. 64 bit is working,

I traced it down to the LoadLibrary routine but can't figure out why it crashes there.

Switching to /NXCOMPAT:NO does not fix the problem on my machine.

13

When I changed Switching to /NXCOMPAT:NO in the property pages advanced section it fixed the problem. Putting in the command  line did not fix the problem. Anyway you can delete these posts if you wish.

 

14

You can put /NXCOMPAT:NO in the introjucer's "extra linker flags" setting and it should work.

15

I having a similar problem with “DirectWave vsti.dll”.
I am using latest JUCE with VS2017/Win32 and I’ve tried /NXCOMPAT:NO.
It crashes on LoadLibrary

Any suggestions?

16

Actually I worked it out. The exception was just Visual Studio and turning off that exception let it continue fine.

LoadLibrary crash hosting VST2 "DirectWave vsti.dll"