Windows 10- Audio Application not generating a VST?

I am opening an existing JUCE Audio Plug-In made by another developer. When I run it, I get this error message in Visual Studio on Windows 10:

“Unable to start plugin.dll”

“plugin.dll is not a vaild Win32 application”

According to this:

I need to find the VST and open it in a DAW as Juce Audio Plug-Ins cannot be ran independently since they are VSTs/AUs/etc, not executable files (exe). I checked “Build VST”, it is enabled. I also checked the “VST” folder inside the Audio Application which I downloaded from Github and, confusingly, I seem to have no VST files. I built the Visual Studio project instead of running it, and it said it built successfully, which should mean that I have a VST file, right? I have these files in said VST folder:

  1. vstname_VST.tlog (folder containing numerous .tlog files)

  2. include_juce_audio_plugin_client_VST.obj

  3. vstname.dll

  4. vstname.exp

  5. vstname.ilk

  6. vstname.lib

  7. vstname.pdb

  8. vstname_VST.txt

  9. resources.res

  10. vc141.pdb

Is there something I am missing? There’s got to be a good way to open a VST and run it in a DAW, right? I tried opening some of the above files in my DAW (FL Studio) as well and rescanning (I am a music producer used to installing third party VSTs) and also searching manually for the VST by name, and I have found nothing.

Also I should point out that I believe my failure to discover a VST is on my part, rather than a bug specific to a certain developer’s project, as I have encountered this issue on multiple JUCE Audio Plug-In projects I have downloaded.

Well, as was explained by Timur in the tread you linked, the plugin is the dll -file. Put the dll you just have created in the same folder as your other plugins and let your Daw scan for new plugins. Hopefully it will detect the plugin as a valid one or at least show an error message if it thinks it isn’t.

To debug, first either build the Audio Plugin Host example and locate the built .exe or locate the installed .exe of your preferred DAW. I use the plugin host example 99% of the time because it allows me to see host-side errors with my plugin since I can see the full source code.

In Visual Studio, right click on the VST project in the Solution Explorer, and select “properties”. In the properties window that pops up, select “debugging”. Set “Command” to be the path to the .exe of your preferred DAW.

Now when you build and run the debugger, instead of trying to run the VST .dll (which can’t be done since it’s a DLL, not a program) it will launch your DAW with the debugger attached. Inside your DAW, make sure to scan your plugin’s build output directory to be sure the plugin is found. Load an instance of your plugin and the debugger will use the debug symbols from your build, meaning that you can set breakpoints in your plugin’s source code to see what’s going on inside.

Hopefully that helps.

Hi oxxxyyd, thanks for the reply. I had to reinstall Visual Studio 2017 for unrelated issues, but after the build succeeded (and with “Build VST”) still checked, a .dll was re-generated. I dragged it into my DAW (FL Studio)'s third-party generator VST folder, and it doesn’t show up in my VST list (or in any of the drop-down VST navigation menus in FL Studio) after scanning the same way I would scan normally after adding a third-party VST. Out of curiosity I then tried adding it in folders other than third-party generators: stock FL Studio effects folder, etc. I even set “rescan all plugins on”.

I have also tried adding the folder in vstname/Builds/VisualStudio2017/x64/Debug/VST into my VST folders which are searched through by FL Studio and that also failed to generate any recognition from FL Studio.

I also checked whether the files were being deleted by FL Studio, perhaps. No, after restarting FL Studio twice, the vstname.dll is still there, although FL Studio seems to ignore it.

And then I eventually managed to get FL Studio to recognize the VST. It turns out there is 1 VST folder in FL Studio that seems to allow VSTs, in C:…\Common Files\VST2, there are 2 FL Studio VSTs, I believe to be used by Rewire. I am speculating that since FL Studio already contained .dll’s in that file, other DLL’s are recognized, but since the other folders lacked .dll’s, FL Studio ignored the .dll in that location.

I am surprised honestly at how long it took me to get the configuration working properly, especially as in all the tutorials I read, getting a VST to be recognized by a DAW was effortless lol, in the main YouTube video I saw the guy didn’t even have to rescan for VSTs in Ableton Live, it worked seamlessly lol.

jonathonracz, thank you for the reply! After about an half an hour of trial and error inside FL Studio, I discovered that FL Studio apparently only recognizes DLL’s put in C:\Program Files\VST2, which I did not know was even a folder for VSTs. FL Studio refuses to recognize my DLL if put in any other FL-default folder (the stock effects/generators folders or third party effects/generators folders).

FL did recognize, however, the DLL when I set C:\Desktop\JUCE\vstname\Builds\VisualStudio2017\x64\Debug\VST as one of the searchable VST folders the second time I set this as a folder. Not sure why it did not work the first time, maybe user error.

Also thank you for the advice on how to set FL Studio to launch when I debug/build. I saw the same feature in XCode used in a tutorial video, except it was called “Scheme”, and whenever I Googled the issue of attempting the same in Visual Studio, I could only find search hits about debugging applications lol, not debugging with another application.