N.I. plugins problem with Cubase 13 ?

LukasL

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.

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

1. 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
2. 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.
3. 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]
4. 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.