N.I. plugins problem with Cubase 13 ?

LukasL · 2024-04-16T13:25:01+00:00

There was an error rendering this rich post.

Hello - today morning I run some updates via NI acs and now some plugins are reported to be incopatible or blocked. Cubase 13 put them on the blocked list - reactivation causes crashes and error messages about unstable Cubase.

I've tried running audacity as it is able to load some VSTs and it says these are incopatible:

C:\Program Files\Common Files\VST3\Bite.vst3

C:\Program Files\Common Files\VST3\Choral.vst3

C:\Program Files\Common Files\VST3\Dirt.vst3

C:\Program Files\Common Files\VST3\Driver.vst3

C:\Program Files\Common Files\VST3\Enhanced EQ.vst3

C:\Program Files\Common Files\VST3\Flair.vst3

C:\Program Files\Common Files\VST3\Freak.vst3

C:\Program Files\Common Files\VST3\Passive EQ.vst3

C:\Program Files\Common Files\VST3\Phasis.vst3

C:\Program Files\Common Files\VST3\RC 24.vst3

C:\Program Files\Common Files\VST3\RC 48.vst3

C:\Program Files\Common Files\VST3\Raum.vst3

C:\Program Files\Common Files\VST3\Reaktor 6.vst3;5653544E6952367265616B746F722036

C:\Program Files\Common Files\VST3\Reaktor 6.vst3;5653544E52366A7265616B746F722036

C:\Program Files\Common Files\VST3\Replika XT.vst3

C:\Program Files\Common Files\VST3\Solid Bus Comp.vst3

C:\Program Files\Common Files\VST3\Solid Dynamics.vst3

C:\Program Files\Common Files\VST3\Solid EQ.vst3

C:\Program Files\Common Files\VST3\Supercharger GT.vst3

C:\Program Files\Common Files\VST3\Transient Master.vst3

C:\Program Files\Common Files\VST3\VC 160.vst3

C:\Program Files\Common Files\VST3\VC 2A.vst3

C:\Program Files\Common Files\VST3\VC 76.vst3

C:\Program Files\Common Files\VST3\Vari Comp.vst3

After forcing Bite.vst3 to be enabled in the audacity, another message showed saying: VST3 module error: boost: filesystem::directory_iterator::construct: (this part is freely/vaguely translated from my native langue) The level of system call is not right [system:124] and then a path to the user's documents\Native Instruments\User Content\Bite.

The message/behaviour is the same for dirt, driver, freak etc. etc. I can somehow enable (Bite.vst3) without getting this message, but applied to a part or whole track in the audacity it does nothing - no window, nothing.

I'm not sure if it is connect with the update itself (it was about 23 items as far as I remember), but it does not affcte all NI plugins.

Find more posts tagged with

DAW

Windows

Komplete

Accepted answers

All comments

LukasL

For now it seems like it is a problem for the logged user, removing his (win roaming profile folders) Steinberg folder and/or Native Instruments folder did not help. But running under my admin account is not affected - maybe something with the user's priv? He had no problems a week ago...

LukasL

BTW as stated elsewhere (MSDN reference MSDN:SHFileOperation) 124 = 7C = The path in the source or destination or both was invalid.

User's documents are redirected (my are not) to the server via gpo, the path shown in the error dialog was not an UNC path - it pointed to his "home directory drive"

Anyway - is there a way to see why these plugins got blocked - I know this is not strictly a Steinberg phorum - but indeed the plugins in trouble are NI origin though.

LukasL

incompatible - lol missing p

this is from windbg - one of the cubase crash dmps

EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 00007ffa5afd53ac (KERNELBASE!RaiseException+0x000000000000006c)
   ExceptionCode: e06d7363 (C++ EH exception)
  ExceptionFlags: 00000081
NumberParameters: 4
   Parameter[0]: 0000000019930520
   Parameter[1]: 000000000014d998
   Parameter[2]: 00007ff9e52403b8
   Parameter[3]: 00007ff9e2590000

PROCESS_NAME:  Cubase13.exe

ERROR_CODE: (NTSTATUS) 0xe06d7363 - <Unable to get error code text>

EXCEPTION_CODE_STR:  e06d7363

EXCEPTION_PARAMETER1:  0000000019930520

EXCEPTION_PARAMETER2:  000000000014d998

EXCEPTION_PARAMETER3:  00007ff9e52403b8

EXCEPTION_PARAMETER4: 7ff9e2590000

STACK_TEXT:  
00000000`0014d710 00007ffa`48a96720     : 00000000`0014d998 00000000`0014dc00 00000000`00000000 00007ff9`e418f052 : KERNELBASE!RaiseException+0x6c
00000000`0014d7f0 00007ff9`e4192609     : 00000000`0014d998 00000000`00000000 00000000`00000000 00000000`00000000 : VCRUNTIME140!_CxxThrowException+0x90
00000000`0014d850 00000000`0014d998     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : Bite+0x1c02609
00000000`0014d858 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`0014d9d0 : 0x14d998

LukasL

Today - I went through with another user and it behaves the same. With my admin account (testing with "Bite") it works. I did not find any evidence why it fails - no clues in the registry either, deleted all user's steinberg and native instruments folders (ie. appdata/Roaming and in the user's documents). I have taken some snapshots with sysinternals processmonitor which I'm reviewing just now.

I know - and already wrote it - this is not a steinberg phorum - but some other NI plugins works no problem, cubase as it is works ok, it only blacklists above mentioned plugins (the list was taken from audacity though - but I think it covers the problematic ones). So I'd like to ask if there is any way to debug why the plugins got blacklisted? Apparently there is something with permissions - but it was not a problem some time ago... but why?

PoorFellow

@Jeremy_NI , I don't know if you have any wisdom to dispense here ?

LukasL

This is from audacity - note the UNC path to user's documents folder (as I mentioned their doc folders are GPO redirected). Cannot find a way to get any debug info from cubase.

When I parsed process monitor log files I've noticed, there was a pattern when vstscanner went throught the registry - scanned HW, asked for many keys in these paths HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{F7F1ED05-9F6D-47A2-AAAE-29D317C6F066} (=ProgramFiles/Common) and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\{FDD39AD0-238F-46AF-ADB4-6C85480369C7} (=user's personal files = documents). Then it opened \Software\Microsoft\Windows\CurrentVersion\Explorer\SessionInfo\[session num]\KnownFolders under HKU. After this it attempted to create \\unc\Dokumenty\Native Instruments\User Content\Raum (or any other name). And the last line before MS's werfault.exe kicked in was QueryDirectory \\unc\Dokumenty\Native Instruments\User Content\Raum with result INVALID LEVEL. FileInformationClass: FileIdExtdDirectoryInformation

According to pm the full command was:

C:\Program Files\Steinberg\Cubase 13\Components\vstscanner.exe "-p" "C:/Program Files/Common Files/VST3/Raum.vst3" "-licenseLevel" "25000" "-hostName" "Cubase"

My UNC path contains backslashes (obviously) and targets a hidden share (ie with $ in the name).

This seems to be in par with the error message given by audacity vst loader - INVALID LEVEL.

stack.txt

Appending stack trace - i can see vst3 file as well as vstscanner.exe - I do not know which one manipulates with the directory, but I can not comprehend why would vstscanner work with the "Native Instruments\User Content\Raum" directory - so I assume this is something NI vst3 handles on it's own....

Anyway - maybe this is some edge case - but seems like it happened after the last update and until I'd done it - there was no blacklisted (NI) plugins...

HTH

Lukas

Richard Vetro

I am using Cubase 13.

I do not have a problem with blacklisted NI effect Plugins in the VST Manager.

LukasL

OK - some progress so far:

I've managed to get some of mentioned VST3 files from an older installation. I put Bite.vst3 back - and voila - it works.

Not working bite.vst3: file version 1.3.3.22, product version 1.3.3
Working bite.vst3: file version 1.3.1.34474, product version 1.3.1

Latest version reported by NIA 1.3.3 from April 2024 - previous was from Feb 2023 (a year appart?).

So the crucial question to the NI is - what you have changed that it fails while iterating [User's Documents Path]\Native Instruments\User Data folder?

The mystery continues (as I do not have older version of all plugins - not mentioning we are missing the factual rolled out updates themself).

LukasL

Sorry - could not help it - but everything seems to lead to someting in the InitDll function (off Bite.vst3 for example). I do not have a large debug facility (and experience) to explore it more. But it seems there could be some error while calling https://en.cppreference.com/w/cpp/filesystem/directory_iterator/directory_iterator- it may be just used to find some user content directory for the plugin by it's name or something... My windbg always ended somewhere in the initdll function.

Moreover this is another error message I've captured

As far I do not know what actions are performed during the init - I may only guess if it is something with UNC paths being scanned/iterated (see other screenshots) as our user's documents are (GPO) redirected to a server share.

I have not gathered any other error message so far… But something had changed from version 1.3.1 to 1.3.3 - because version 1.3.1 works on the same computer for the same user.

LukasL

I'd like to ask op/moderator to change the topic name to something else - not to state the NI's plugin are not compatible with Cubase
There seems to be some difference in case the user has it's documents folder (hence native instruments/user content folder) on an older server or a server supporting SMB2. In the first case there is a call to QueryDirectory with FileInformationClass: FileIdExtdDirectoryInformation, this ends with an error INVALID LEVEL (eq. invalid system level = 124). I do not have full details why it is called - but I bet it is to search for files in the user content directory of loaded plugin. Now - if the user has it's documents on a SMB2 compatible share - the same call ends with NOT SUPPORTED. When in the first case it means a crash (which may be catched as an exception in some try/catch statement) - in the second case it goes on - with another QueryDrirectory (FileInformationClass: FileFullDirectoryInformation) - and it gets info about the current directory "." and a link to upper directory (="..") in response. Next call is responded with NO MORE FILES - so this looks like classic FindFirst/FindNext scenario (with wildcard mask *). Then the path (native instruments\user content) gets closed. So it seems like it is not able to cope with the INVALID LEVEL response. It is weird - as I think this is only to look up previously saved user settings.
I run these VST via vsthost (nice piece of software) in the trace enabled version - so I could trace down / or peek inside where this happens:
[pre]
00:00:06.439 0x19C0 Unhandled exception 0xE06D7363 at 00007FFFDA0ACF19
CS:RIP=33:00007FFFDA0ACF19 SS:RSP=2B:000000000014DD70 RBP=000000000014E1C9
Flags=0000000000000206 MXCSR=0000000000001FA0
DS =000000000000002B ES =000000000000002B FS =0000000000000053 GS =000000000000002B
RAX=0000000003770400 RBX=0000000087B003B8 RCX=00000000DA550000 RDX=000000000014DB98
RSI=000000000014DFF8 RDI=0000000019930520
R8 =000000000014D7D0 R9 =000000000014DC90 R10=0000000000000000 R11=000000000014D6B0
R12=000000000014E0F0 R13=0000000000000000 R14=000000000014E260 R15=0000000000000000
Stack Trace:
00007FFFDA0ACF19 (KERNELBASE): RaiseException + 0x69
00007FFFBD446720 (VCRUNTIME140): CxxThrowException + 0x90
00007FFF86A52609 (Bite.new): qt_qmlDebugSetStreamVersion + 0x9970a9
00007FFF86A54A39 (Bite.new): qt_qmlDebugSetStreamVersion + 0x9994d9
00007FFF84F56D36 (Bite.new): InitDll + 0x1fa26
00007FFF84F58DD9 (Bite.new): InitDll + 0x21ac9
00007FFF84F545ED (Bite.new): InitDll + 0x1d2dd
00007FFF84F2CB53 (Bite.new): qt_startup_hook + 0xee73
00007FFF856406C6 (Bite.new): InitDll + 0x7093b6
00007FFF84F34A5C (Bite.new): qt_startup_hook + 0x16d7c
00007FFF85640C5B (Bite.new): InitDll + 0x70994b
00007FFF84F34EFE (Bite.new): qt_startup_hook + 0x1721e
00007FFF85354B83 (Bite.new): InitDll + 0x41d873
00007FFF84F35017 (Bite.new): qt_startup_hook + 0x17337
00000001400740C1 (vsthostBridge64): CVSTMADll::InitDll + 0x21
0000000140074A00 (vsthostBridge64): CVSTMABasePlugIn::HasCorrectFormat + 0x100
00000001400150D3 (vsthostBridge64): CSpecPlugInHost::Creat
[/pre]
It would be nice it there was some patch/change to bypass this call or just to handle the possibility something went wrong. We are unable to change our infrastructure instantly - so it would be too difficult to circumvent this situation in a timely manner. Whatsmore - I do not believe this is a standard behaviour of search by wildcard rutine, or maybe it is a rare edge case - I do not know, but it could trigger anytime it is quering any directory content on a share. Not mentioning - the former versions had no issues.

PoorFellow

I'd like to ask op/moderator to change the topic name to something else - not to state the NI's plugin are not compatible with Cubase

Done.

Jeremy_NI

https://community.native-instruments.com/discussion/comment/151062#Comment_151062

We don't support programs like vsthost and that could be the source of the problem here. Hopefully you found your way around it. If not, please get in touch with our support here: https://bit.ly/NI_support_other

LukasL

Hello Jeremy_NI, I hope you have noticed the original title of this thread. I was not describing my troubles with vstbridge at first. As Cubase has no (to my knowledge) debug output of why it blacklisted some plugins - I had to turn to some other host. So I used vstbridge for this - plus it has a lot less fuzz going around so I could concentrate on the relevant.

At the end I have found out it is not Cubase problem at all - so I asked op to rename the thread. On the other hand I have discovered that some change in your plugins made it calling slightly (perhaps newer) API calls when it deals with searching user's settings at it's startup.

I was hoping someone would check the code and implement some workaround - as it is not obvious that it is a compatibility problem, but maybe a problem with used (file) library versus some underlaying (Win) API calls.

Anyway - there at least two ways around - first - the simple one - to use an older version of the plugin, second - maybe change our infrastructure (as I have another users (on newer machines) pointed to a modern-ish share - and there is no problem).

But I was little curious if NI could investigate or take care of such a edge case here.

Jeremy_NI

https://community.native-instruments.com/discussion/comment/159977#Comment_159977

This is why I gave you a link to support.

Quick links

Unanswered questions