I’m currently in a strange situation.
Our plugin works fine on mac au and vst, and the release version on Win vst.
But failed to be started by hosts when using a Debug build(Visual Studio2010).
The condition is that, the hosts does know there’s our plugin in the path, but it somehow refuses to load our plugin.
Cubase then just put us in the blacklist, ie C:\Users\xxx\AppData\Roaming\Steinberg\Cubase LE AI Elements 6\Vst2xBlacklist Cubase Elements.xml .
The host didn’t enter our .dll at all, I set breakpoint at the entry place DllMain and in some other constructors.
In fl studio, it would list our plugin as it were correct, but when starting it, the host would report an error.
Any suggestion on what I’d better do next? I don’t want to debug release version using many fprintf to a log.
The Windows API LoadLibrary returns 0 with error code 998, so I make it break on the first time meeting the Access Violation exception.
The problem is because of some static initialization, so it never comes to the entry point of the dll.
I have a static juce::String array and used a String::Empty inside the init list, which made this error.
By any chance could this exist within the newest JUCE 4.2? I have just tried one of the samples (not modified by me in any way) - the NoiseGate VST. Release .dll loads fine, while the Debug version cannot be identified as a VST plugin at all (I tried a few different VST hosts). I’m talking about the VST2, not tried VST3 yet. The same issue tiwht GainPlugIn by the way… I built using VS 2015.
I just isolated the issue to be setting the linked runtime library to Multi-threaded Debug DLL (I copied the whole Release configuration as the working one and changed the runtime lib from Multi-threaded Debug to Multi-threaded Debug DLL (+ I had to remove _DEBUG from the preprocessor of course not to get linking errors for some missing Windows Dbg functions) - the latter setting makes the resulting .dll not to be recognized as valid VST plugin, even if I don’t add the _DEBUG into the preprocessor).
Is it the forementioned entry point case?
Btw: when Multi-threaded Debug (static, not the DLL one), it’s working fine as well.
I tried running the plugin on other PC with MS VS 2015 installed as well with the same results, unfortunately (just to confirm it’s not some win runtime dll missing).
This is normally entirely expected if the user hasn’t installed VS or the Microsoft’s redistributable C++ runtime. If your runtime isn’t static then your .dll will depend on Microsoft’s C++ runtime .dlls.
These are automatically installed when installing VS so running the plug-ins on the same machine as you built them should always work fine. If you are running them on another machine then you need to use the static runtime.
Thank you for the answer, but I think I emphasized in my post, that I have VS 2015 installed (+redistributables as well btw) on BOTH machines, and the issue occurs on BOTH machines as well.
So if my last post wasn’t clear enough, let me show it like this:
PC no 1 (with VS 2015 installed) -> Multi-threaded Debug DLL not working (I tried many hosts), Multi-threaded Debug (static) working
PC no 2 (with VS 2015 installed) -> Multi-threaded Debug DLL not working (I tried many hosts), Multi-threaded Debug (static) working
Of course I can use the static one, but I’m just curious with the default settings don’t work to (while do work for others, at least to devs who created those VS projects with these settings).
I perfectly understand the diff between dynamically linked vs static. And as I’m trying to test it on my development boxes, I expected no obstacles (at least not on the very beginning and with the most simple plugins).
Btw. Even the JUCE sample plugin host built with Debug failed to load Multi-threaded Debug DLL VST plugin. And of course I don’t get any errors/warnings while building.
The problem has gone. I tried not only running, but also building in debug mode on different PC - and it build and ran properly with the Multi-threaded debug DLL. Now on the first PC I uninstalled VS 2015 and installed it again (Community Edition) and - voila - plugin built with the Multi-threaded debug DLL are recognized as vst plugins.
I still don’t know what it was. VS for some reason was building wrong .dlls, when the Multi-threaded debug DLL was set (though not compile/link errors/warnings). I didn’t check it at first as I couldn’t even think of VS building incorrect binaries without giving any warnings/errors.
