Latest Waves Shell + VST3 + HostDemo Crash

Pretty sure we got an waves VST3 issue. If you download/update latest Waves Central, update the products, and try to scan for VST3 in the host demo. it will crash.
Same in our own host.
If this is a known issue I apologize.
I tested on Windows 10 in 64bit (64bit host)

If there’s a crash, could you at least post a stack trace?

Sure (For what it’s worth):

WaveShell-VST3 9.91_x64.vst3!00007ffeefd50480() Unknown
WaveShell-VST3 9.91_x64.vst3!00007ffeefce676d() Unknown
WaveShell-VST3 9.91_x64.vst3!00007ffeef8e1c74() Unknown
WaveShell-VST3 9.91_x64.vst3!00007ffeef8e37c4() Unknown
WaveShell-VST3 9.91_x64.vst3!00007ffeef8e5ec0() Unknown
Plugin Host.exe!juce::VST3Classes::DLLHandle::releaseFactory() Line 1207 C++
Plugin Host.exe!juce::VST3Classes::DLLHandle::~DLLHandle() Line 1137 C++
Plugin Host.exe!juce::VST3Classes::VST3ModuleHandle::getAllDescriptionsForFile(juce::OwnedArrayjuce::PluginDescription,juce::DummyCriticalSection & results, const juce::String & fileOrIdentifier) Line 1323 C++
Plugin Host.exe!juce::VST3PluginFormat::findAllTypesForFile(juce::OwnedArrayjuce::PluginDescription,juce::DummyCriticalSection & results, const juce::String & fileOrIdentifier) Line 2797 C++
Plugin Host.exe!juce::KnownPluginList::scanAndAddFile(const juce::String & fileOrIdentifier, bool dontRescanIfAlreadyInList, juce::OwnedArrayjuce::PluginDescription,juce::DummyCriticalSection & typesFound, juce::AudioPluginFormat & format) Line 168 C++
Plugin Host.exe!juce::PluginDirectoryScanner::scanNextFile(bool dontRescanIfAlreadyInList, juce::String & nameOfPluginBeingScanned) Line 99 C++
Plugin Host.exe!juce::PluginListComponent::Scanner::doNextScan() Line 525 C++
Plugin Host.exe!juce::PluginListComponent::Scanner::ScanJob::runJob() Line 541 C++
Plugin Host.exe!juce::ThreadPool::runNextJob(juce::ThreadPool::ThreadPoolThread & thread) Line 348 C++
Plugin Host.exe!juce::ThreadPool::ThreadPoolThread::run() Line 42 C++
Plugin Host.exe!juce::Thread::threadEntryPoint() Line 104 C++
Plugin Host.exe!juce::juce_threadEntryPoint(void * userData) Line 120 C++
Plugin Host.exe!juce::threadEntryProc(void * userData) Line 81 C++

So I’m pretty sure Waves broke something in their latest release, but I have a feeling they will never admit that.
To recreate update waves, clear known plugin list, scan for VST3

OK, but I really don’t know what you think we could do with that… There’s nothing in the stack trace that gives any clue about why their plugin is crashing or what we could change to avoid it.

Hi, I know
I was thinking more along the lines of what Fabian did the last time; send them an email suggesting that they take a look at this issue on their end, and remind them that you have a pretty large user base, and that the issue might affect multiple hosts.
If I send in a request as one, small company they usually just ignore it.

Yep, fair enough. We’ll give them a shout.

…btw did you try a release build? Could just be something as simple as them increasing their anti-piracy protection when the app is being debugged.

Yes, I got a crash report from a user (release build and built with Juce Master) and then tried with juce Tip (develop) to make sure.
So my release was working just fine with waves, they created update and it broke. So there is no change in juce that could cause this. If they should blame Juce it has to be some kind of subtle, unknown, compatibility-thing that has been there for months.

Investigating this now.
First the crash during scan. I got this response from Waves:

After debugging your host, I found that the problem lies with the fact that we get Release() call for the plugin after ExitDll() was called.

Tried to make this change in juce_VST3PluginFormat:

  if (ExitModuleFn exitFn = (ExitModuleFn)getFunction("ExitDll"))


  if (ExitModuleFn exitFn = (ExitModuleFn)getFunction("ExitDll"))

The plugin still crashes when loaded though. but that is a different issue…

1 Like

Update: After making this change the plugins load fine in the Juce Demo Host.
(The other crash is related to me doing something special on the UI)
Now will this affect other plugins negatively?

Only tests with a variety of other plugins will tell!

Thanks! This change makes sense, it’s clearly wrong to try to release an object after the DLL has been unloaded, and I can only guess that this is a typo which luckily didn’t cause any issues in most plugins. I’ll sort it out right away…