Hi,
I’m new to Juce but a few times now over the past few weeks I received this error that I can’t solve and I have to roll back to older saved work before the error started. It seems related to post-build processes (sorry if this is called something different). It seems that it stops writing the moduleinfo.json when vst3_helper.exe runs after build.
I’ve tried copying the .vst3 to the plugins folder but it won’t run without the moduleinfo.json which is present, only it’s blank… I also deleted the builds folder but that doesn’t work.
I’ve tried all Windows versions from 7.0.6 onwards but it still creates the error.
Thanks for taking a look.
The error:
Severity
Code
Description
Project
File
Line
Suppression State
Error
MSB3073
The command copy /Y C:\Users\Jeremy\Desktop\SoftClipperTest\Builds\VisualStudio2022\x64\Debug\VST3\Abusive.dll C:\Users\Jeremy\Desktop\SoftClipperTest\Builds\VisualStudio2022\x64\Debug\VST3\Abusive.vst3\Contents\x86_64-win\Abusive.vst3 del /s /q C:\Users\Jeremy\Desktop\SoftClipperTest\Builds\VisualStudio2022\x64\Debug\VST3/Abusive.vst3\Contents\moduleinfo.json if not exist C:\Users\Jeremy\Desktop\SoftClipperTest\Builds\VisualStudio2022\x64\Debug\VST3/Abusive.vst3\Contents\Resources mkdir C:\Users\Jeremy\Desktop\SoftClipperTest\Builds\VisualStudio2022\x64\Debug\VST3/Abusive.vst3\Contents\Resources C:\Users\Jeremy\Desktop\SoftClipperTest\Builds\VisualStudio2022\x64\Debug\VST3 Manifest Helper\juce_vst3_helper.exe -create -version 0.1.0 -path C:\Users\Jeremy\Desktop\SoftClipperTest\Builds\VisualStudio2022\x64\Debug\VST3/Abusive.vst3 -output C:\Users\Jeremy\Desktop\SoftClipperTest\Builds\VisualStudio2022\x64\Debug\VST3/Abusive.vst3\Contents\Resources\moduleinfo.json :VCEnd exited with code -1073741819.
It looks like the plugin is crashing when it is loaded to write the manifest. Other than the missing manifest, it looks like the rest of the plugin has been built successfully.
To debug this, you could manually copy the plugin from the build directory to the install directory, and then load it in the host of your choice while a debugger is attached.
Thanks for the reply… I’ve been using Reaper to debug with the Local Windows Debugger function in Visual Studio. I’ve also tried moving the vst3 into other directories to run in Reaper and Ableton but it seems like it doesn’t run without a proper manifest/modulinfo.json.
I’ve tried disabling the manifest generation by removing it from the post-build events but then it deletes the existing one. I don’t have a copy of the manifest before all of this started happening so without it, the daw doesn’t recognize the .vst3 and it doesn’t show up.
I will also mention that both times I got stuck like this was after incorporating 3rd party modules or introducing classes, but there really isn’t anything in the output or the errors to point me towards the source of the issue.
The moduleinfo.json is optional (but recommended!). Hosts should be able to load the plugin when the moduleinfo is not present.
I think it’s more likely that the plugin is crashing immediately when it is loaded, causing Reaper and other hosts to blacklist it.
You could try debugging with the JUCE AudioPluginHost. You can force the plugin to be scanned and loaded by dragging and dropping the plugin’s .vst3 folder onto the main window of the AudioPluginHost. Then, you should be able to step through the code and find out exactly what causes the crash.
If you make sure the debugger is attached before dragging the plugin into the host, you should be able to see the crash in the debugger and work out what’s going on.
I just had the exact same thing happen to me; turns out my plugin was crashing during scanning (due to some recent changes, but I could no longer build it because of the manifest generation step). More info:
I was able to attach the AudioPluginHost and get a call stack and some other info, which is infinitely more useful than what I was working with before.
I’ll see if I can’t sort this out, will check back either way.
I encountered this too. I did a build check on my code and out of the blue it crashed like that.
It pointed to the o:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets
line 160 <Exec Command="%(PostBuildEvent.Command)$(_BuildSuffix)" StdOutEncoding="%(PostBuildEvent.StdOutEncoding)" StdErrEncoding="%(PostBuildEvent.StdErrEncoding)" Condition="'%(PostBuildEvent.Command)' != ''"/>
Just rebuilding also hits that error.
Windows10 VS2022 + Projucer
I have no clue, but I could make it work thanks to GIT. Previous commit worked. So I copied last version files over the working commit and it built.
Then after a pull request it failed again.
Or build runs and after a minute with no changes it doesn’t.
EDIT:
Ended up recreating new project and moving my code.
It was some recent changes in my code causing a dangling pointer during the creation/destruction that happens when the plugin is scanned - nothing in the juce code (if that’s what you’re asking). In any case, I removed the manifest step so that I could debug it being scanned inside the AudioPluginHost, and I quickly located my problem.
I ran into this issue this week and with no real error logs to go on, it took forever to figure out what our problem was.
It turned out that we were deleting all the files in the juce SpecialLocationType::tempDirectory on start up, which was deleting the VS2019 post-build script (also stored in AppData/LocalTemp/) and therefore throwing the whole thing in the garbage.
Very random reason but maybe leaving a note here will help down the line.
Hello everyone, I’m getting a very similar error and I can’t really understand what is causing it. I just know that it is crashing at startup in some part of the code I don’t really understand. More details can be found here: Post build error [MSB3073] in Visual Studio.
This has happened to me a few times so I’m posting the “fix” for it here - mainly so that next time it happens and I search for it, I can find my own solution!
The issue is caused by a slightly circular dependency in the building of the VST3. The post-build script for the VST3 project runs a program called juce_vst3_helper which does the final packaging of the VST3 after the DLL has been built. To do that, it actually loads in the DLL. However, if you’ve written a bit of code that causes the loading of the DLL to go pop, then the helper crashes and Visual Studio reports that the VST3 build failed. There is no useful output in the build log to explain what happens - all it does is list the post-build-script and says it failed.
Now the solution:
Right-click on the VST3 project and set it as your “Start-up project”
Right-click on the VST3 project again and select “Properties”
Select “Debugging” in the left column
On the “Command” option, click the browse button, and set it to point to the “juce_vst3_helper” executable - you’ll find this in the build/Debug folder of your project.
From the output log of your last failed build, find the line that mentions the helper, it will look something like “error MSB3073: Debug\juce_vst3_helper.exe…”
Copy the parameters passed to that line into the “Command Arguments” setting in the VST3 properties. It will look something like “-create -version 0.0.0.0 -path…”
Click OK on the property page and run your build - it will try to build, fail again, then ask if you wish to run the last successful build - click “Yes”.
The debugger will now run the helper and crash at the offending bit of code.
Fix the code and it should now compile just fine.
I hope that helps - if so, feel free to buy me a pint at the next ADC
The most recent situation was a statically initialized variable that depended on another statically initialized variable. Ancient code that worked fine for ages until an unrelated change made the compiler logic decide it would be better to initialize them in a different order. The classic tale of “How did this ever work?”
@reuk gives a great list of more general things that might go wrong. So far, I’ve encountered issues that fall into both the “missing dependency” and “runtime crash” categories.
I encountered a similar problem. I found that it was because juce_vst3_helper.exe also needed dependent libraries (such as onnxruntime.dll, etc.) to run when checking the Demo.vst3 plug-in. Copying the dependent libraries to the same directory as juce_vst3_helper.exe can solve the corresponding problem. Leave a note here, maybe it will help someone else.
