Plugin blacklisted by Nuendo, not found by Reaper


Hey guys.

Our plugin works fine on most PCs (VST2 build) and Macs (AU build).

Recently, the PC in our demo-room was updated from Windows7 to 10. From that moment on, the Plugin stopped working on that PC.

  1. Plugin64.dll gets black-listed by Nuendo 8 and cannot be re-activated.
  2. Plugin64.dll does not get detected by Reaper, even after several re-scans and cache clears.
  3. Plugin32.dll gets detected in Reaper and works, but in bridged mode. Nuendo no longer supports 32-bit plugins so it doesn’t get detected there but I guess that is expected.

Like I said, the Plugin works fine on mine and other Windows10 PCs, so I don’t know why just this one computer has issues.

First I though this may be a windows permissions thing. However the account they are using has admin rights, which they used to install both DAWs, copy the plugin’s binaries, etc.

Looking around the forum I found this thread: Cubase 9 blacklists plugins
So I used the vst-scanner tool on our Plugin. The result wasn’t very helpful:

* vstscanner on Plugin32.dll
** No output (does that mean no errors, or that the tool didnt work?)

* vstscanner on Plugin64.dll
<pre><code class="xml">
C:\Users\...>vstscanner.exe -p Plugin64.dll
<?xml version="1.0" encoding="UTF-8"?>
<error>dll does not export the required &apos;GetPluginFactory&apos; function</error>
** This seems a VST3-specific thing (GetPluginFactory). I guess vstscanner is meant for VST3 plugins, so not relevant for our plugin.

* vst2xscanner on Plugin32.dll
** No output (does that mean no errors, or that the tool didnt work?)

* vst2xscanner on on Plugin64.dll
<pre><code class="xml">
C:\Users\...>vst2xscanner.exe -p Plugin64.dll
<?xml version="1.0" encoding="UTF-8"?>
<sdkVersion>VST 2.4</sdkVersion>
** So... no errors, I guess?? 

Anyone have any ideas?


Are you linking to the Microsoft C++ runtime library statically or dynamically? (If it’s the latter, maybe the system doesn’t have the library dll installed.)


Up till now I always linked dynamically, as per default (see screenshot of my JUCE build config).

I just changed the Runtime Library setting to “Use static runtime” and sent the resulting VST binary to my colleage. Let’s see what she says.

With the static runtime I was unable to build as AAX, though.


You’ll have to make sure the Runtime Library setting is the same when building the AAX SDK.

But in any case it’s better practice to use the dynamic runtime these days: IMPORTANT BREAKING CHANGE: JUCE will now use dynamic linking for the Windows runtime by default


But then you have to start ensuring the end user machine has the separate runtime installed…Sigh.


Yeah, it’s an obnoxious issue for sure :stuck_out_tongue: At least it’s not too difficult to bundle the redistributables into one’s product installer.