Crash when scanning plugin


I’m working to create a Plugin Host, and for the most part all work as it should. But sometimes when I load or rescan plugins I face a crash in the JUCE_VST_WRAPPER_INVOKE_MAIN. For now it happen with Phoscyon demo plugin (windows 10 64bit) for example.

If someone has any clue I would be gratefull ! :slight_smile:

1 Like

EDIT : The same problem occurs with the plugin host code provided in the juce example.
We tested on 2 computers on Windows, with one computer it sometimes works, and an other one it fails all the time.

EDIT 2 : After more tests, we discovered that two plugins are “incompatible”. When they are both scanned it crashes.
We isolated the scan on a new folder containing only these 2 plugins , plugin A and plugin B.
When we remove one of the 2 plugins, the scan runs fine.
However, when they are together in the folder, it crashes.

We tried on a 3rd computer with different plugins and it looks like there is a similar issue with different plugins.

Example of the 2 plugins with the issue :


and Phoscion (demo)

Did you try to validate the plugins in question with @dave96’s pluginval
or Steinberg’s vstScanner to see if the problem is on your/PluginHost’s or their end?

See also

In FL studio, Studio One, or Reaper there is no problem to open them. But the problem that we have in our plugin host is the same there is in the plugin host given by juce

I tested with the pluginVal and there was no problem with the plugins either.

The devs of Phoschyon are not from a little company (D16) so the opposite would be surprising.
We also had similar issues on Mac with Ozone VSTs.
Thanks for your help

I didn’t mean to imply any of that… but honestly, in my experience size doesn’t matter in bug-free-ness anyway… :wink:
Individual developer experience matters, but in bigger structures the culture towards development and QA plays a much bigger role. But that’s now very off-topic, sorry about that…

I hope we/you can find the reason, what’s going wrong, let us know…

These plugins are DLLs that are all being loaded into the host’s address space. Part of that process involves resolving DLL symbols by name, so if you have DLLs with the same symbol, they can often get linked to the wrong one. You can usually avoid problems by stripping all symbols in your release build but in debug builds or non-stripped release ones it’s just a fundamental hazard of the way DLLs work, I’m afraid!

Hello Daniel and Jules,
I work with Jonathan. :wink:
@jules : we launched the exe directly outside visual studio (compiled in release mode) and removed the pdb files around the exe file. We have the same crash (we output the current plugin scanned in a log file) :frowning:

The pdb files aren’t relevant to this - exported DLL symbols are part of the binary itself.

@jules : Are you sure?

“With Visual C++ (and other Microsoft compilers) on Windows, symbols aren’t part of the binaries. Instead, they are stored in separate files called “Program Database” files (.pdb files). Just don’t provide the .pdb files.”

I’m not talking about debug symbols, these are the names of functions that the DLL exports. You can use something like DUMPBIN to see what’s in there.

@jules: I see, thanks for the clarification.
When we scan the 2 dlls separately , export the 2 plugins descriptions as xml files and merge these into a single pluginDescription xml file, then, we don’t have the issue anymore, and we are able to load them together using the KnownPluginList. What is the difference here?

I don’t really understand what you mean, but perhaps your problem is something other than the symbol name clash. I was just flagging that as a possible cause, since it does happen in this kind of situation.

To fill the KnownPluginList we can use the PluginDirectoryScanner or use an xml file. As the PluginDirectoryScanner does not crash when the two plugins aren’t load together, we can fill and export a KnownPluginList in xml and see the PluginDescription of both. We add merge the two xml, and load it in the KnownPluginList. And it works. Then we can create AudioPluginInstance of both plugins.

Maybe it’s more understandable with a sample of code :

Thanks for your fast answers !

@jules : Jules, if it is related to symbol name clash, why don’t the DAWs have this issue? And why do we have it with the PluginHost code? There is nothing we can do?

I didn’t say it’s definitely a symbol clash. But if it was, then it could be because the plugin host is being built with its symbols unstripped. Maybe try using a stripped release build of the host.

@jules : I was thinking you were referring to the symbols unstripped of the plugins, not of the plugin host. Compiling with /PDBSTRIPPED MSVC2017 option doesn’t solve the issue. :frowning:

Are these plug-ins protected by the same protection scheme?


Like I already said - this has nothing to do with PDB files or debug symbols! An EXE/DLL contains a list of its functions, and that’s what I’m talking about here.