Softube failing is on Softube… I do think they just updated the Softube Central.
Once in a while C14 says it hangs on “VST3 scanning”, when indeed it is looking for its license to be approved (for windows take a look in the Task Manager).
1 Like
Yep, I tried running Softube Central yesterday after posting above, and it sat there for like 2 hours trying to ‘retrieve iLok licenses’ or whatever its last step is. Got absolutely nowhere. iLok was indeed updated a bit ago, UAD has no trouble connecting, everything works inside Cubase, Wavelab, etc. Its the crappy Softube Central manager that doesn’t.
Tried running it again about 20 minutes ago, sure enough, there’s a new update and I can finally update my plugins yet again (didn’t they just update them earlier this week or last?).
I read a comment on a Gearspace thread the other day from one of the Softube reps. He acknowledged that the Softube Central app is flaky at the moment. Apparently they’ve loaded a bunch of new functionality (mostly under the covers) and the app has become unstable as a result.
They’re working on it…
Yeah its working with this mornings update at least..
Not sure when they did this, but looks like I got some ‘new’ plugins they split off from some other stuff. Amp Room (or one of them anyways) now comes with a Rat pedal and what I am assuming is an HM-2 pedal (the Doom Church). Also now have a ‘Model 84 Chorus’ taken out of the Juno plugin.
Hi Guys….massive thanks for the amazing knowledge. It was Soft Tube Central. I tried to download it and it just fell to pieces!!! Couldn’t get Daemon to work and the Ilok account was disconnected. All good now….(everything crossed). Good work!! 
5 Likes
Interesting. A problem with an internet-based dependency causes Cubase to fail to start up.
1 Like
This is why Cubase should have a Timeout during the startup process to avoid it being dependent on external servers (the most critical currently Softube and Waves), if these fail during the license verification, Cubase is in trouble…
1 Like
Except that Cubase (nor any DAW) can monitor what a VST is doing. Some DAWs attempt to “sandbox” plug-ins in order to minimize the impact of plug-in crashes, but Cubase no more knows a specific plug-in is sitting in an idle state waiting on a 3rd party service response than it does if the plug-in is performing spectral filtering on FFT bins. A VST is an executable, and there’s no standard API call from the DAW into the VST to say “Hey buddy, you doing OK? Everything alright?” And even if there was, the plugins that are so poorly written that they lack basic error trapping and connectivity recovery very well may report back “all good, just working.”
It’s not Cubase’s job to attempt to monitor what a VST is doing. It’s the user’s job to choose to purchase VSTs by vendors whose development process includes proper error handling when non-critical services can’t be reached (if they use them).
1 Like
Interesting! I have the same problem since this morning. I don’t have the latest version of Ilok installed (I am on 5.10.1), but the problem in my case seems to be the latest versions of Gullfoss and Kraftur plugins (both using ilok). Soundtheory support said that they can reproduce the problem, but they also hinted that maybe Cubase has some problems with latest ilok version. Still waiting for a solution.
2 Likes
If it stalls at “Checking Licenses” i’m fairly confident it’s the Steinberg Licensing System, since Cubase doesn’t really know what a VST is up to when initializing them.
So - i’d start with downloading the latest update of the Steinberg Activation Manager | Steinberg and installing that. Perhaps also try and refresh your licenses by holding down shift when clicking the “Refresh” icon in the top right of the activation manager software ..
But - if it happened directly after an iLok / pace update, thats somewhat of a smoking gun. Anyway, doesn’t hurt to try the above either way ..
1 Like
While I have not experienced any problems, it may help to know that all my (iLok) activations are on a (physical) USB iLok.
1 Like
I had this issue a while back and I remember a post saying disconnect all unused network drives, that worked for me.
1 Like
Same here! Software manager issues aside, my actual iLok licensing is pretty smooth, and I honestly don’t even know it’s there until I have to register a new plugin and add it to the key. I’ve ‘lost’ software licenses before forgetting to deactivate before trashing an old HD or retiring a computer. The $50 key is the best way to go.
1 Like
Succumbing to peer pressure, I just updated to the latest iLok Activation Manager on both my MBP M3 Max and Studio M3 Ultra, both running macOS 26.0.1.
No issues at all.
2 Likes
Back when I had a failing system disk on my old Windows 10 computer, Cubase’s plugin scanning during startup could take forever on the first start after a boot (after the first start, the plugins would be cached in memory). Quite often, I’d see CrashLog entries due to NI plugins, especially Kontakt and Guitar Rig, but those plugins would work fine in the session. A Steinberg engineer in the Dorico forum shed some light on that, saying that Cubase would wait some defined amount of time, then assume the plugin had hung and create the log entry, but it wouldn’t actually abort. And because the NI plugins eventually did return to Cubase – they just took a very long time to scan all their dependencies – they didn’t actually have a problem, other than the time taken for the scan due to the very slow hard disk response time.
Thus, if this scenario really is something that is dependent on external servers, be it iLok or otherwise, it must be that the code within the plugins’ authorizations does something that only checks once and doesn’t abort if it fails but rather just waits (since restarting Cubase right after killing it when it is hung like this works okay).
That’s good that a plugin vendor is able to reproduce it. Maybe a little surprising, too, though, if they can reproduce it reliably in that, at least in my experience, this only happens in a minority of Cubase starts.
It’s not stalling at Checking Licenses, though. That is early in the Cubase startup, and it gets past that. It stalls at the VST3 plugin stage. The Checking Licenses is just what shows up as a sub-process of Cubase in Task Manager. Not sure why that is, unless there is Cubase just considers the VST3 initialization as part of this.
Everything is fresh on my system as this is a new PC build for Windows 11, and I had to reinstall all software (though thankfully not all library sample files!).
That is what some others have suggested, and my iLok Manager is the latest, too (since I had to reinstall it on my new system), though it may also have been current on my Windows 10 system as I may well have updated it prior to deactivating my licenses on the old system. I’ve only experienced the hang on the Windows 11 system, though (and only in a minority of my Cubase starts, too).
FWIW, I don’t have any of those. This is a new system, so the only “network drive” is OneDrive, and it is used for OneNote and a subset of my Office files (not for anything connected to Cubase).
My physical iLok is quite old, and only a very small minority of the software I still run supports it. All my activations, except UAD Spark, are local to my system, though. UAD Spark doesn’t allow that, though, due to its subscription nature. (I got a free year with a plugin purchase I made late last year or early this year.)
Keep in mind the problem doesn’t happen every time. I’ve only seen it three times to date across probably 15-20 Cubase starts. But it’s also possible it may be specific to Windows 11 since I think everyone who’s mentioned having the problem thus far has also mentioned their being on Windows 11 (and I never saw the issue on my old Windows 10 system, though it’s probably been on the order of 3 weeks since I used that.
1 Like
I would add that they couldn’t abort it; at least not effectively - and it my mind, shouldn’t even try. The hosting app (e.g. Cubendo) would have no idea what other peer/child processes are instantiated by the plugin, and thus, could leave orphaned processes. Or even worse, if it forced-closed a process based on a timeout, it could cause other issues in itself. If the original vendor plug-in was that poorly written to cause the issue in the first place, then SB making a development decision to force-close it on purpose without knowing what orphaned processes were left behind in memory could actually be detrimental.
I know you’re not saying that, but my post was in reply to different posts which seemed to suggest some manner of auto-termination when a timeout threshold was reached during the scanning process.
I’ll leave that point be since it doesn’t solve your issue, and the OP was marked solved, so….
3 Likes
Me too 100%. No issues.
I can’t remember the last time I had a Cubendo startup hang.
1 Like
FWIW, I was just adding some information. In particular, it may be relevant here that Cubase is NOT creating CrashLog entries in this case. That is, if there is still a timeout that would do this (like there was when I got the information, which I suspect may have been with Cubase 13), then whatever logic caused it to do that previously must not be being triggered.
I see that the OP did mark it as solved, but the general problem (as opposed to his specific issue) isn’t since that solution related to Softube – e.g. I don’t have any Softube anything installed on my new system.
2 Likes
Do you guys with this problem all own quite a few Softube plugins?
I have been chatting and isolating the issue with @Ulf and it seems to be primarily an issue when a lot of Softube plugins are scanned in a very short amount of time (for my computer). Softube do the ilok license check during scanning which seems to lock up the scanner process at some point when it scans a lot of Softube plugins. Some sort of ilok+timing issue. The Cubase/Dorico plugin scanner unfortunately is unable to recover from it. I have had one single time since then where a lock-up happend at a plugin from a different vendor. But for me its mostly been Softube plugins.
So far, Softube has unfortunately not really reacted to my problem description. @Ulf wanted to create an internal Steinberg ticket to make the scanner more robust wrt. to unreliable vst3 plugin behaviors.
Here is a workaround I have found:
In the Windows Task Manager, end the process “VST 3 Plug-in Scanner.”
After that, it will continue scanning.
If it gets stuck again, repeat the process.
Then, in the Cubase Plug-in Manager, reactivate the skipped plug-ins in the blocklist.
Unfortunately, Cubase does not show where it got stuck, so you either have to guess whether the scan is continuing or check the vstscannermaster.log file located at:
%APPDATA%\Steinberg\Cubase 14 and observe whether it hangs or not.
Technically, I don’t really think Softube Central is to blame here as the installation manager, but the fact that an ilok license check even takes place during plugin scanning which is ought to work quickly without much latency. But that is just from my my observation without knowing the internals. It doesn’t seem to happen as often when its only a couple of Softube plugins in the VST3 folder.
1 Like
I don’t have any on my new system (and I never saw the problem on my old system. However…
This may make sense, despite my having no Softube plugins. In particular, I do have a UAD Spark subscription (came free for a year with a plugin I bought late last year or early this year), and that makes all the UAD native plugins available, and there are 52 of those, all of which use iLok Cloud licensing (the 10 UAD plugins I own are licensed on my local system, like the rest of the plugins I have that use iLok for software protection).
While I never saw this on my old PC, that PC would be a lot slower – i7 5820k vs. Core 9 Ultra 285k, and also using a SATA SSD for the system disk, whereas the new one uses uses an PCIe5 M.2 NVME drive (“up to 560 MB/s” versus “up to 14,800 MB/s”, respectively). If RAM speed enters into the equation, there would also be a difference there (DDR4 2133 vs. DDR5 6600).
This only happens a small minority of the times Cubase starts on my system (still only 3 times total, but I’ve only started Cubase a few additional times this week, whereas last week, which is when I saw the three hangs, I started it a bunch of times). It has not happened in starting Dorico for me, but I’ve only started Dorico a small number of times, and just to verify that it was working and was reflecting my migrated preferences.
The workaround that works for me with Cubase when this does happen is to just end the Cubase task and start Cubase again. It has never (to date anyway) hung on startup twice in a row on my system.
1 Like