Plugin blacklisted by Nuendo, not found by Reaper

Windows
1

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"?>
<plugin>
<path>Plugin64.dll</path>
<error>dll does not export the required &apos;GetPluginFactory&apos; function</error>
</plugin>
</code></pre>
** 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"?>
<vst2xplugin>
<path>Plugin64.dll</path>
<subCategory>Fx</subCategory>
<cid>...</cid>
<editorCid>...</editorCid>
<name>Plugin64</name>
<vendor>...</vendor>
<sdkVersion>VST 2.4</sdkVersion>
<vendorVersion>...</vendorVersion>
<latencySamples>0</latencySamples>
<canDoublePrecision>0</canDoublePrecision>
<audioInputBusCount>1</audioInputBusCount>
<audioOutputBusCount>1</audioOutputBusCount>
<mainAudioInputArr>3</mainAudioInputArr>
<mainAudioOutputArr>3</mainAudioOutputArr>
</vst2xplugin>
</code></pre>
** So... no errors, I guess??

Anyone have any ideas?

2

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.)

3

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.

JuceCompileSettings
JuceCompileSettings.png566×907 55.4 KB

4

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

5

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

6

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.

7

Hey Fellas,

first of all apologies for the long silence. I just finally got news back that the version with statically linked MS runtime library does work on the demo PC.

I am wondering, though. According to Fabian’s post (linked by RustyPine above), the runtime should be installed by default on Windows10 systems.

Is the issue then, that the particular Win10 update which contains the runtime hasn’t been done on this machine yet? It’s well possible, since this PC is usually kept off the internet.

Or is it possible that the installed runtime is not compatible with the plugin DLL because I am building with VS2013?

Thinking about a generic, long-term solution for users which might run into this same problem… I suppose the only clean solution is to provide an installer for our Plugin.