N.I. plugins problem with Cubase 13 ?

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.

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?

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.

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

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).

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.