I purchased VCV Pro some time ago and it has always worked well under Ableton Live Pro (it was still perfect last night). Tonight however it generates strange errors ( C++ error) What may have happened? (I also tried offline installation but to no avail) Can you help me? Addendum: If it helps, this happens: if I reply “ignore” to the C++ error, Ableton opens vcv and asks (VCV) me to log in, I try to do so but it tells me to download the licenses through the account because it doesn’t work. I do what is indicated by also inserting the proposed key but it still doesn’t work. Thank you Roberto
I don’t understand what you mean by “C++ Error”.
Pkease post the Rack error log or a screen snip of the error message.
What are the last few lines in the VCV log file ?
That look like a windows only error where VCV can’t find your documents folder. Maybe some new windows defender thing won’t let rack see the doc folder?
btw, there is an ancient controversy among programmers - “should you take the asserts out in a release build?”. Smart people disagree about this.
The correct answer is “yes, you should take asserts out in a release build”. The reason is that often the assert is benign, and while the programmer would like to know that it happened, it’s not worth causing crashing bugs to keep them in.
In this case, however, something bad would probably happen, so the assert isn’t making things any worse. That may be the case will all the asserts in VCV. In my own modules I always take them out of the release version.
I’m guessing this is an assert in the VCV Rack VST itself. Most Rack plugins aren’t built with the Microsoft C Runtime library.
A prompt to log in would seem to indicate that the Rack VST didn’t find the license file.
This is a case for VCV - Support (vcvrack.com)
You should look in the source file like I did. Then you, too, could be correct!
1 Like
Yah, Doh.
Failing SHGetFolderPathW(NULL, CSIDL_MYDOCUMENTS, NULL, SHGFP_TYPE_CURRENT, documentsBufW);
According to the docs, this API is deprecated. Rack is probably stuck with it because Rack still supports the EOL Windows 7.
Now that I’m looking at the Rack source, there is workaround for the issue:
- Set a RACK_USER_DIR environment variable pointing to the location where plugins and so on should go.
Set that environment variable in the global environment, and you should be able to get past this assert.
1 Like
Windows 10 or 11? Under windows updates see if there was a windows update run in that day between it working and not working. What else did you do on the system in that timeframe? Do you have a 3rd party anti-virus/security program installed?
Hello Yeager here: [33.758 info adapters/standalone.cpp:289 main] Destroying window [33.761 info adapters/standalone.cpp:291 main] Destroying UI [33.762 info adapters/standalone.cpp:294 main] Destroying library [33.762 info adapters/standalone.cpp:296 main] Destroying MIDI [33.762 info adapters/standalone.cpp:298 main] Destroying audio [33.762 info adapters/standalone.cpp:300 main] Destroying plugins [33.762 info src/plugin.cpp:370 destroy] Destroying plugin Vult Modules Free [33.762 info src/plugin.cpp:370 destroy] Destroying plugin Voxglitch [33.762 info src/plugin.cpp:370 destroy] Destroying plugin VCV Pro [33.763 info src/plugin.cpp:370 destroy] Destroying plugin Valley [33.763 info src/plugin.cpp:370 destroy] Destroying plugin Surge XT [33.768 info src/plugin.cpp:370 destroy] Destroying plugin Squinktronix [33.768 info src/plugin.cpp:370 destroy] Destroying plugin Impromptu [33.768 info src/plugin.cpp:370 destroy] Destroying plugin Grayscale [33.768 info src/plugin.cpp:370 destroy] Destroying plugin VCV Free [33.768 info src/plugin.cpp:370 destroy] Destroying plugin CharredDesert [33.768 info src/plugin.cpp:370 destroy] Destroying plugin Bogaudio [33.768 info src/plugin.cpp:370 destroy] Destroying plugin Befaco [33.768 info src/plugin.cpp:370 destroy] Destroying plugin Audible Instruments [33.769 info src/plugin.cpp:370 destroy] Destroying plugin VCV Core [33.769 info adapters/standalone.cpp:302 main] Destroying network [33.769 info adapters/standalone.cpp:306 main] Destroying logger END Tks Roberto
1 Like
Hello Lochino di Squinky I’ve been checked all dires in use of VS are excluded from defender
Tkhs Roberto
Hello Pachde; I obviously wrote to support at the moment and assume that it is a problem of interaction and consent of Defender on the folders used by VCV; I checked and unfortunately I have already excluded all the VCV folders in use. Thanks Roberto
Hello LarsBjerregaard, I checked, obviously carefully but W11 and W update including W Defender did not install anything in the period between “working” and “not working” and neither did I. It’s a very clean PC, there are no strange programs on it and navigation is always safe 
Thanks
Roberto
Does the workaround I mentioned with the RACK_USER_DIR environment variable get you past the assert?
1 Like
First of all I wanted to thank everyone who was interested in my problem, however it was solved in the following way: 1) I uninstalled everything 2) I have deleteted multiple application folders and registers 3) I installed in the folders proposed by the system also considering the Defender for the exclusions of folders under folders, finally I verified that Windows had no control over the folders where the software was installed. After all this procedure it started working normally again. (I remember however that nothing had been installed/modified when VCV crashed) Better this way! Thanks again everyone Roberto
2 Likes