This has now been confirmed by the iLok devs. They are working on a fix.
Those of you who have not had an issue, it’s because you’re not using any plugin that used the very latest toolkit when built.
Plus a number of other coincidences.
Cheers all.
4 Likes
@Phil_Pendlebury Are you in contact with PACE or any host or plugin developer about this? I have a couple of bug tickets running, but I doubt that anyone will push the information when the fix is available. I haven’t even received any confirmation that this is a PACE issue. If you hear anything about a fix version being released, it would be perect if you could inform this thread.
1 Like
Yes, I am and yes of course I will.
2 Likes
Hey Phil, how lovely to hear from you and fanx for the info. I think in my case it was the “perfect storm” with various updates and housekeeping all arriving at the same time. With the help of the good folks on here i have nailed it and have enjoyed a “drama free” week.
Are you still out in the dust, or back in Blighty?
1 Like
Glad you got it sorted Glenn, the perfect storm, indeed those days happen eh…
Yes, still in the land of sand. 
1 Like
It’s an easy to resolve issue in terms of rebuilding the plugins with the older toolkit which I did last week as a workaround, and I gather a proper fix will be coming along as well. It only presented for me when installing the .40 DAW updates.
3 Likes
I haven’t updated .40 due to major bugs when using Atmos. This isn’t a problem that happens only in the .40 versions, it’s happening in .32 as well and I suspect pretty much every Steinberg software using the vstscanner and vstscanner master, including Dorico where I first noticed this.
2 Likes
Just an FYI as Softube just recently updated all their plugins again and a new ilok update is out. Installing ilok 5.10.3 didn’t resolve the issue just in case anyone was curious.
3 Likes
Cubase 14 win11 pro.
I have the up to date ilok dongle software installed (checked a minute ago while refreshing zdt).
I own 12 Softube products, just downloaded the Softube updater, clicked “update all”, all 12 products updated (Marshalls Germaniums etc).
Zero issues.
Newest Cubase 14 update starts right up. All plugs fine.
1 Like
Thanks for trying. You likely aren’t affected with “just” 12 ilok plugins scanned. See above on explanations what is happening exactly and when. It’s not happening consistently and is some sort of a timing issue depending on how many plugins are scanned in a short amount of time following each other and specific ilok versions installed or compiled into the plugins.
48 ilok dongle licenses. 12 are Softube.
The thing on this, at least in my case (on Windows 11 25H2, currently with Cubase Pro 15.0.6), is that this hang on VST3 scan only happens occasionally. I only found out about the latest iLok update through this thread today, so didn’t have it installed yesterday. But I had the hang on starting yesterday, and only one plugin (which does use iLok) had been updated. But that was the first hang on start I’d had in some weeks (I’ve only had 5 or 6 in the last two months, and I have a load of iLok-based plugins due having everything from PSP Audioware, plus some from UAD, including a Spark subscription, which uses iLok Cloud), and I’d had a number of iLok-based plugin updates (and a few new installations) during that period.
My current totals show 54 cloud (all UAD Spark), 72 authorized to my system (approximately 8 of those products aren’t actually installed, so wouldn’t be scanned), and 32 to a dongle (I think only 2 of those products are installed as most are for very old VST2 versions of products that I didn’t install on my new system, and some of those products don’t even exist at this point).
I do wonder if dongle versus cloud and/or system authorization might also make a difference in this behavior.
1 Like
Below is a powershell script (save for example as “test_vst3_loop.ps1”) that repeatedly runs the vstscanner.exe bundled with Cubase on the same plugin if you are interested to play around with this. It also allows to test for this problem if not so many plugins are installed and specific developers for the issue.
Adjust the lines in the configuration block at the top to match your system and execute in the Windows terminal. I have tried this on a few ilok cloud plugins, but I don’t have a lot plugins that support ilok cloud (my perpetual UAD plugins don’t support ilok cloud).
Here are a few sample results for licenses on ilok cloud that didn’t expose the probem for me:
- Process.Audio Decibel
- Pulsar Smasher
- Pulsar IPA 25
- Slate Digital Heatwave
- Soundtheory Gullfoss
Here are some results with the license on an usb ilok3 (I have terminated after like 150 iterations if nothing happend, I’ve had the freezes happen from iteration 1 to iteration 130, it varies wildly. It could be that in repeated tests, some of those that didn’t freeze in my sample test, may still have the problem):
- Liquidsonics Seventh Heaven Pro does does not freeze (as expected)
- Softube Abbey Road RS127 Box freezes
- Softube American Class A freezes
- Process.Audio Decibel does not freeze
- Soundtoys EchoBoy does not freeze
- Pulsar IPA 25 does not freeze
- Relab Development LX 480 v4 does not freeze
- Oeksound Soothe2 does not freeze
- PSP VintageWarmer2 does not freeze
- SSL FlexVerb does not freeze
- Sonnox Oxford Inflator does not freeze
…so far it seems it’s primariy Softube stuff that exposes this (for me). They also freeeze for me if I move the Softube license to my machine (and not the dongle). Maybe the other developers have patched it in the meantime. If I recall correctly (I might be wrong, it’s been a few months since I did these tests in more detail), others like Soundtoys used to have this as well. I may have installed updates in the meantime though.
<#
.SYNOPSIS
Runs the Steinberg VST Scanner in an endless loop and validates the output.
.DESCRIPTION
1. Configurable paths for Cubase components and the target VST3 plugin.
2. Executes vstscanner.exe against the plugin.
3. Parses the output (which is often concatenated XML) to verify validity.
4. Updates a status line in the console showing the iteration count, plugin name, and vendor.
#>
# --- CONFIGURATION ---
# Adjust these variables to match your system paths
$CubaseComponentsPath = "C:\Program Files\Steinberg\Cubase 15\Components"
$PluginPath = "C:\Program Files\Common Files\VST3\Decibel.vst3"
$ScannerExe = "vstscanner.exe"
# --- PRE-FLIGHT CHECKS ---
$ScannerFullPath = Join-Path -Path $CubaseComponentsPath -ChildPath $ScannerExe
if (-not (Test-Path -Path $ScannerFullPath)) {
Write-Error "CRITICAL: Scanner not found at: $ScannerFullPath"
exit
}
if (-not (Test-Path -Path $PluginPath)) {
Write-Error "CRITICAL: Target Plugin file not found at: $PluginPath"
exit
}
Write-Host "Starting VST Scanner (Debug Mode)..." -ForegroundColor Cyan
Write-Host "Scanner: $ScannerFullPath" -ForegroundColor Gray
Write-Host "Target: $PluginPath" -ForegroundColor Gray
Write-Host "------------------------------------------------"
# --- EXECUTION LOOP ---
$counter = 0
while ($true) {
$counter++
$processInfo = New-Object System.Diagnostics.ProcessStartInfo
$processInfo.FileName = $ScannerFullPath
# We wrap the path in escaped quotes to handle spaces correctly: "C:\Path With Spaces..."
$processInfo.Arguments = "-p `"$PluginPath`""
$processInfo.WorkingDirectory = $CubaseComponentsPath
$processInfo.RedirectStandardOutput = $true
$processInfo.RedirectStandardError = $true # Capture errors too
$processInfo.UseShellExecute = $false
$processInfo.CreateNoWindow = $true
$process = [System.Diagnostics.Process]::Start($processInfo)
# Read both streams to ensure we catch everything
$stdOut = $process.StandardOutput.ReadToEnd()
$stdErr = $process.StandardError.ReadToEnd()
$process.WaitForExit()
# Combine output for checking
$fullOutput = "$stdOut $stdErr"
# --- PARSING ---
$isValid = $false
$pluginName = "Unknown"
$vendor = "Unknown"
# We use a simpler regex that just looks for the tags, ignoring the XML structure
# This handles the "concatenated XML" issue better.
if ($fullOutput -match "<name>(.*?)</name>") {
$isValid = $true
$pluginName = $matches[1]
if ($fullOutput -match "<vendor>(.*?)</vendor>") {
$vendor = $matches[1]
}
}
# --- OUTPUT ---
if ($isValid) {
# Success: Overwrite the current line
Write-Host -NoNewline "`r[Success] Iteration: $counter | Name: $pluginName | Vendor: $vendor "
}
else {
# Failure: Stop overwriting and print the detailed error to help you debug
Write-Host "`n"
Write-Host "[FAILURE] Iteration: $counter" -ForegroundColor Red
Write-Host "The scanner did not return valid Name/Vendor tags."
Write-Host "---------------- RAW OUTPUT START ----------------" -ForegroundColor Yellow
Write-Host $fullOutput
Write-Host "---------------- RAW OUTPUT END ------------------" -ForegroundColor Yellow
# Pause so you can read the error before it loops again (optional)
Start-Sleep -Seconds 2
}
# clear variable for next run
$fullOutput = $null
}
2 Likes
I may try the script at some point if I have some time. Based on the early descriptions of the problem (i.e. relating to newer iLok libraries from PACE that had the bug, and programs compiled with that/those? versions exhibiting the problem), I suspect it will be some newer, or more newly updated, PSP plugins on my system. (I don’t have any active Softube plugins – while I got the two freebies Steinberg made available to Cubase users, they ended up not being anything I’d be likely to use, so I didn’t install them on my new system, though the authorizations did transfer over when I did my bulk iLok authorization transfers).
The one that got updated yesterday was PSP StereoAnalyser2 (not available to the general public yet, only to people who picked up PSP StereoAligner2). StereoController2 got updated today, as well, but I’m not sure if I’m likely to get a chance to use Cubase today.
If you happen to have more PSP plugins than just VintageWarmer2, you can go into your PSP user area and sort your plugins by release date (which is really the date of last update), to get some idea of the date range that may be relevant for this. I see VintageWarmer2 was updated fairly recently (October 9th), so I’d think that, if yesterday’s update to PSP StereoAnalyser2 did cause the hang, and the issue on PACE libraries only started earlier this year, that VintageWarmer2 (if fully updated to V2.10.6) should also cause it (assuming it would definitely occur within the 150 iterations). On the other hand, if you have a version of VintageWarmer2 that pre-dates the libraries problem, that could also avoid it. The ones I see from that were updated this year, in order of most recent to least recent updates, are:
- stereoAnalyser2
- stereoController2
- stereoAligner2
- VintageWarmer 2
- preQursor3
- X-Dither
- NobleQ
- DRC
- TripleMeter
- BussPressor
- Wobbler
I’ve got 11 permanent UAD plugins, but I believe the only one that is from this year is the Showtime 64 Tube Amp (which they gave out as a freebie at some point). The only other brand plugins (as opposed to libraries) I have that are actually installed are a couple from Eventide (one of which is definitely new this year – not sure on the version I have of the other) and one from Antares (definitely not new, though I’m not sure if the specific version installed on my new system since it’s conceivable it was updated from the one on my old system). There is also Synchro Arts RePitch 1, but I think they replaced the iLok authorization with their own (or maybe Landr’s) software protection scheme in the version I have.
1 Like
Unfortunately, I don’t have any of these. Only Xenon and BinAmp in addition to VintageWarmer2. I just reran the script on VintageWarmer though and it didn’t freeze up to iteration 500.
I have also tried BinAmp and couldn’t make it freeze as well (up to iteration 500).
I don’t necessarily think the update date of the plugin necessarily has something do with this, but more like how it was built. Some developers update toolkits more often, others don’t and others like Liquidsonics roll back if there are problems with newer ones.
It’s also possible that the last ilok update delivered at least a partial fix. I have written to PACE and their support stated that the issue was mentioned was supposed to be fixed with the last update and asked for a specific error description of my remaining problem.
1 Like
Yes, I understood that part on the libraries it was built with, which was why I was thinking about the date range of the plugin update releases (since they are usually built relatively shortly prior to that).
In any case, I tried running the script tonight (at least 150 iterations for each attempt) with several PSP plugins, both from the date range and outside of it, as well as Eventide’s Temperance Reverb Lite, UAD’s Paradise Guitar Studio (which would be Spark for me), and a few random plugins that were not iLok (e.g. Kontakt 8, because one of the times I had the VST3 scan freeze was after an update to Kontakt 8). All passed.
One thing that struck me about this script as a test, though, is it is scanning WAY slower than an actual VST3 scan at Cubase startup. My VST3 scan typically takes anywhere from about 5 seconds to maybe 15 at most (at least if it doesn’t hang). Of course, most of the time, there aren’t any updated plugins, but it’s still in the same ballpark when there is an update of a plugin or two. The UAD plugin went through a couple hundred iterations before I even noticed it was going so fast, but the PSP ones maybe did 2-3 iterations a second, and even Kontakt 8 was on the order of a second per iteration. Thus, if the speed with which plugins are being scan comes into play, this may not be as likely to get a hang as the actual startup scan would.
It’s also worth noting, though, that I did update the iLok manager today, so if that made a difference for whatever iteration of plugins I have with respect to the build side of the iLok libraries, it’s conceivable what might have hung on this test yesterday might not today.
1 Like
Yes, it’s possible that the Powershell script is slightly slower than what might be happening in a C++ application. However, in principle, it’s just an endless loop calling vstscanner.exe from Cubase which is more or less exactly what Cubase is doing in the vstscannermaster. So the script-overhead is essentially just in the loop which shouldn’t be a lot. If your impression is that the scan is much slower, you might be fooled by the plugins that Cubase skips due to the existing VST3 plugin cache (where it doesn’t rescan if the file hasn’t changed). Also, I have been able to reliably reproduce the lockups with it.
Without rolling back and comparing, my impression is that the last ilok update may have actually improved things as I can reproduce the lockups only with Softube plugins now it seems.
1 Like
In the script there is also the overhead of calling vstscanner.exe for each iteration, though, versus what I’m guessing is the relatively rapid fire checking of directory and/or file dates to see which plugins need to be scanned. In other words vstscanner.exe is actually doing a lot more per unit of time when processing all plugins than when processing a single named plugin.
FWIW, my thinking on this (which may well be wrong) is that it might be getting into a deadlock situation where something isn’t finished before something is started, but progressing to completion of that first something can’t happen because the second something is using something it needs, but the first can’t finish because the second has something it needs. Basically, some kind of bug in handling shared resource contention in parallel processing.
Part of the reason I was thinking along these lines is that I never once saw the problem on my older, slower Windows 10 system, but I was seeing it immediately (i.e. the first time I started Cubase) on my new Windows 11 system, which not only has a much faster CPU (and faster memory, and …), but also an PCIE5 M.2 NVME SATA system disk, versus a SATA SSD system disk on the old system. Of course, there were also more plugins to scan that first time, but fewer and fewer in the subsequent occurrences, to the point where my most recent case likely only had one plugin to scan (or perhaps one iLok plugin and a small number of non-iLok plugins as there may also have been a few NI updates between Cubase uses).
1 Like