Makes sense. I’ve trimmed them down a bit but do still have a few. Widener is really the only one I ever use nowadays, but I still have the Model 82/84 installed along with all the Amp Room stuff. Amp Room itself seems to also have some bits and pieces scattered in my account as their own plugins like a couple of the Marshall heads, but oddly I think the whole lot updates with one of the actual Amp Room updates. That’s how the new pedal plugins are going. When they show updates, they dont have an actual update button (same with the new Model 84 chorus pedal), but they end up updating when the suite does. The rest of their stuff I own like the API channel strip, the bus processor, etc I uninstalled awhile back once I started picking up the UAD stuff. After that I uninstalled all my Waves stuff, Plugin Alliance, etc..
It depends on what’s meant by ‘quite a few’.
I have the complete Weiss bundle along with maybe ten other assorted Softube plugins. To date I have not had any issues with the Softube Central app / Ilok while running Cubase / Nuendo.
Yes, 10+ is likely enough for the problem to occur. I’ve had a lockup also at the first Softube plugin, but that usually doesn’t happen.
I have 4. Would you believe after the Windows update I am right back where this started!!! C12 loads fine C14 is hanging on VST3s again!!! So………if I was to go to C/Program files/Common files/VST3 and made a copy of that folder…….then removed certain folders and VST3s until the problem stopped and work backwards from there??? I’m not seeing anything in the crash log that points to the culprit. I have updated all of the installers I can find. Would this an advisable way to get to the bottom of this??
You won’t find the problem in a logfile. The VST scanner process freezes. See my post above for a workaround. I don’t think there is another solution right now.
Does it do this every time? In particular (beyond the potential workaround @bnz posted), what happens if you just kill Cubase via Task Manager when it hangs, then immediately start it again? That has worked 100% of the times when it’s hung on me (only 3 times to date, though, all with Win 11 24H2 – none, yet anyway, with 25H2, but I’ve only had that since yesterday morning).
Yes, that would be a workable way of narrowing it down.
Hey bnz….your workaround is absolutely the way to go!!! Slate VSX is the villain. Very strange, as the updates are usually a bit more “showbiz” from Slate, but this one appeared in an email like a bit of a brain fart, with a quote that was formerly used……..smells a bit like sabotage!!?? Sure enough, VSX was waiting in the VST manager blocked list. The “System wide” VSX is still working fine, but the normal one in the Control Room is blank. Might see if there is a way to route through the system wide output until I can chat with the good folks at Slate. Thanks as always for the support people 
VSX working fine here on Windows 11 CB 14 Pro …
Is that on 5.1.7 ?
In my experience, its usually not specific plugins to blame where it always freezes. Its more a matter of what they do in the scanning initalization (like ilok checks). If you have multiple or many of such plugins (like the Softube ones which are also often updated at the same time), it’s more likely to freeze. It also may not freeze at all, but it seems that the culprits are always plugins that do the authorization check during scanning.
Yep. 5.1.7 Platinum.
Would you believe, I reinstated the VSX from the blocked-list and it is now working!!! Bit of a worry this just seemed to right itself (eventually), but I have enough ammunition to do a decent trouble-shoot the next time this rears its head.
Sometimes preference files and whatnot get ‘corrupted’ over time. A fresh reinstall might set you back a little, but it will overwrite anything that has turned into ‘junk’ so you can get back to work. The fun part is tracking down where the bad bits are..
Wise words, I imagine here are lots of bit of orphaned code milling about to get looked at and discarded that gums up the processes. I might have to find something to bite on and take the plunge!!!
There is something you can do which may give you a way of recovering when you have plugins that hang during scanning.
On Windows, in a command prompt type:
taskkill /f /im vstscanner.exe /t
On mac, in a terminal window type:
killall vstscanner
This kills the process that is scanning each plugin. The vstscannermaster (which launches the individual vstscanner processes) will think that the plugin has crashed and it will be added to the block list. This should allow Cubase to start, and then you can try re-enabling the plugins once Cubase has launched.
Hi Paul,
This command is really interesting, and I even see some use in a situation where Cubase is dragging its feet in this scanning process.
Why isn’t this command executed by Cubase (itself) after a certain amount of time? As you mentioned, Cubase would become functional, and we could see who the culprits are…
Could things be that simple, or am I just too unfamiliar with this whole process?
The short answer is that (a) we’ve not had time to do it and (b) moving the plugin to the block list isn’t the best option for all circumstances.
I have reworked parts of the plugin scanner in Dorico to add an automatic 30s timeout (though this isn’t always what is needed. If you have lots of plugins from one manufacturer which all have the same problem then that’s 100 x 30s to wait). It may be useful as a diagnostic though: install the free Dorico SE and that will show the scanning of each plugin so you can see the ones that are hanging.
I would like to improve the robustness of the plugin scanning in Cubase, but as ever it’s a matter of time and resources.
Thank you, Paul, for this very clear and frank answer.
You’ve nevertheless provided us with a command that can be useful in this type of situation and should probably be used sparingly. We all want the startup process to be as efficient as possible, even though it sometimes gets a bit muddy, and Cubase isn’t necessarily the one responsible.
We can always hope that the time and resources will one day be available, and this process is probably not the only one…
FWIW, I definitely wouldn’t want to see the default in this scenario’s being moving a plugin to the blocklist. Especially considering that, at least in the 3 cases I’ve seen of the hang over the last two weeks, just killing Cubase via Task Manager and restarting it, did not repeat the hang. Killing the VST scanner process as you suggested would have actually been more work, taking longer to look up the syntax than to just kill Cubase and try again, not to mention then having to check the blocklist and make changes there.