"Problem" with Slick EQ GE and Cubase 9.5.x

Official support for: tokyodawn.net/tokyo-dawn-labs
RELATED
PRODUCTS

Post

Hi,
to be frank, I don't know whether it is really a problem of Slick EQ GE, but I am clutching at straws at the moment...
The Problem: When closing a Cubase project that I've worked on, Cubase goes into some kind of deadlock, is marked as "inactive" in Task Manager and i have to kill it. Annoying. At first I suspected a faulty plugin, but after loads of testing and finally using WinDBG it is actually multiple plugins, amongst others (Tonebosters Track Essentials, SGA1566) Slick EQ GE.
I cannot reproduce the hang when just opening and closing the project immediately, only after n minutes of working on it (where is "n > 10" or so, don't know exactly)

The deadlock state presents itself like this in a windbg threaddump:

Code: Select all

0:081> ~*k
   0  Id: 2774.123c Suspend: 1 Teb: 00000000`00327000 Unfrozen
 # Child-SP          RetAddr           Call Site
00 00000000`0014b788 00007ff9`332d9252 ntdll!NtWaitForSingleObject+0x14
01 00000000`0014b790 00007ff8`e8588c7d KERNELBASE!WaitForSingleObjectEx+0xa2
02 00000000`0014b830 00007ff8`e82de576 D3D10Warp!ThreadPool::WaitWhileBusy+0xdd
03 00000000`0014b8b0 00007ff8`e82acba6 D3D10Warp!UMContext::FlushAllRenderingTasks+0xfc6
04 00000000`0014c150 00007ff8`e82aac38 D3D10Warp!UMDevice::Destroy+0xb6
05 00000000`0014c230 00007ff8`e82b8185 D3D10Warp!UMDevice::`vector deleting destructor'+0x28
06 00000000`0014c270 00007ff9`2ff20b7c D3D10Warp!UMDevice::DestroyDevice+0x55
07 00000000`0014c2b0 00007ff9`2ff233b8 d3d11!NDXGI::CDevice::DestroyDriverInstance+0x5c
08 00000000`0014c310 00007ff9`2ff1763a d3d11!CContext::LUCBeginLayerDestruction+0x7c
09 00000000`0014c360 00007ff9`2ff17982 d3d11!CUseCountedObject<NOutermost::CDeviceChild>::UCDestroy+0x19a
0a 00000000`0014c390 00007ff9`2ff2e2ab d3d11!CUseCountedObject<NOutermost::CDeviceChild>::UCReleaseUse+0xb2
0b 00000000`0014c3c0 00007ff9`2ff1b100 d3d11!CDevice::LLOBeginLayerDestruction+0x11f
0c 00000000`0014c3f0 00007ff9`2ff17ef5 d3d11!NDXGI::CDevice::LLOBeginLayerDestruction+0x10c
0d 00000000`0014c440 00007ff9`2ff17dab d3d11!NOutermost::CDevice::LLOBeginLayerDestruction+0x25
0e 00000000`0014c470 00007ff9`2ff17cf4 d3d11!TComObject<NOutermost::CDevice>::~TComObject<NOutermost::CDevice>+0x23
0f 00000000`0014c4a0 00007ff9`2ff17d74 d3d11!TComObject<NOutermost::CDevice>::`scalar deleting destructor'+0x14
10 00000000`0014c4d0 00007ff9`2ff584bb d3d11!TComObject<NOutermost::CDevice>::Release+0x44
11 00000000`0014c500 00007ff9`2ff14934 d3d11!ATL::CComPtr<IUnknown>::~CComPtr<IUnknown>+0x4b
12 00000000`0014c540 00007ff9`302b0921 d3d11!CLayeredObjectWithCLS<CBuffer>::CContainedObject::Release+0x2c4
13 00000000`0014c590 00007ff9`302f4859 d2d1!CHwSurfaceRenderTargetSharedData::~CHwSurfaceRenderTargetSharedData+0x1f5
14 00000000`0014c5c0 00007ff9`302f4907 d2d1!InitializableObject<RefCountedObject<CD3DDeviceLevel1,LockingRequired,DeleteOnZeroReference> >::`vector deleting destructor'+0x29
15 00000000`0014c5f0 00007ff9`302f4ed9 d2d1!RefCountedObject<CD3DDeviceLevel1,LockingRequired,DeleteOnZeroReference>::Release+0x47
16 00000000`0014c620 00007ff9`302f3991 d2d1!CD3DDeviceManager::D3DDeviceInformation::`scalar deleting destructor'+0x2d
17 00000000`0014c650 00007ff9`302709f4 d2d1!CD3DDeviceManager::~CD3DDeviceManager+0x71
18 00000000`0014c680 00007ff9`30306b90 d2d1!D2DFactory::~D2DFactory+0xbc
19 00000000`0014c6c0 00007ff9`30306b79 d2d1!RefCountedObject<D2DFactoryLocking<SingleThreadedTrait>,LockingRequired,DeleteOnZeroReference>::`vector deleting destructor'+0x14
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Program Files\Vstplugins\EQ\TDR VOS SlickEQ GE.dll - 
1a 00000000`0014c6f0 00007ff8`f122c931 d2d1!RefCountedObject<D2DFactoryLocking<SingleThreadedTrait>,LockingRequired,DeleteOnZeroReference>::Release+0x39
1b 00000000`0014c720 00007ff8`f12a2aa7 TDR_VOS_SlickEQ_GE+0x5c931
1c 00000000`0014c760 00007ff8`f12a5e3e TDR_VOS_SlickEQ_GE+0xd2aa7
1d 00000000`0014c7d0 00007ff8`f12a6007 TDR_VOS_SlickEQ_GE+0xd5e3e
1e 00000000`0014c800 00007ff9`36f04053 TDR_VOS_SlickEQ_GE+0xd6007
1f 00000000`0014c870 00007ff9`36f0ff71 ntdll!LdrpCallInitRoutine+0x6b
20 00000000`0014c8e0 00007ff9`36f0f59e ntdll!LdrpProcessDetachNode+0xf5
21 00000000`0014c9b0 00007ff9`36f0f945 ntdll!LdrpUnloadNode+0x3e
22 00000000`0014ca00 00007ff9`36f0f8c3 ntdll!LdrpDecrementModuleLoadCountEx+0x71
23 00000000`0014ca30 00007ff9`332bbced ntdll!LdrUnloadDll+0x93
..
24 00000000`0014ca60 00000000`16136f3a KERNELBASE!FreeLibrary+0x1d
25 00000000`0014ca90 00000000`1613802c VSTPlugManager!InitDll+0x330eb
26 00000000`0014cad0 00000000`161300f5 VSTPlugManager!InitDll+0x341dd
27 00000000`0014cb00 00007ff9`36d277ed VSTPlugManager!InitDll+0x2c2a6
28 00000000`0014cb30 00007ff9`36d26778 USER32!UserCallWinProc+0x25d
29 00000000`0014ccb0 00007ff9`36d39c17 USER32!DispatchMessageWorker+0x2a8
2a 00000000`0014cd40 00007ff9`36d399de USER32!DialogBox2+0x217
2b 00000000`0014cdd0 00007ff9`36d398a2 USER32!InternalDialogBox+0x11e
2c 00000000`0014ce30 00007ff9`36d39838 USER32!DialogBoxIndirectParamAorW+0x52
2d 00000000`0014ce70 00007ff9`36a9c85d USER32!DialogBoxIndirectParamW+0x18
2e 00000000`0014ceb0 00007ff9`36aa79e0 COMDLG32!CFileOpenSave::Show+0x37d
2f 00000000`0014d0f0 00007ff9`36aa2eb4 COMDLG32!_InvokeNewFileOpenSave+0xf0
30 00000000`0014d150 00007ff9`36a92cea COMDLG32!_CreateNewFileOpenSaveInProc+0xe8
31 00000000`0014d1a0 00007ff9`36a6e2ff COMDLG32!NewGetFileName+0x15e
32 00000000`0014d200 00007ff9`36a6ed10 COMDLG32!GetFileName+0x10b

33 00000000`0014d260 00000001`41c3be0a COMDLG32!GetOpenFileNameW+0x70
34 00000000`0014e320 00000001`41c123eb Cubase9_5+0x1c3be0a
...
48 00000000`0014ff60 00007ff9`36f41461 KERNEL32!BaseThreadInitThunk+0x14
49 00000000`0014ff90 00000000`00000000 ntdll!RtlUserThreadStart+0x21
For the other aforementioned plugins the pattern is the same. Always thread 0, always VSTPluginmanager, the plugin and severall calls to DirectX-Libraries and the "waitforSingleObject". Most other threads seem unsuspicious and have way shorter call stacks.

I already contacted Jeroen/TB (quick to answer but "cannot reproduce the problem") and Steinberg support (after long long wait: " we think it is the fault of the directX components, not our problem"), I've posted in the Cubase forum.
Apparently I am the only one on the world with this problem...

This problem existed pretty much since I got my shiny new computer with Win 10 a few months ago. No problem on my old system with Win7 before. All updates installed, graphic card driver current, already tried the "dism /scanhealth; scf /scannow" procedure.

I am wondering whether this might be a problem of the Plugin framework used. But weirdly enough, with other TDL plugins (Nova, Slicke EQ M) i didn't encounter the problem.

The next step, which I dread, is reinstalling Windows (which I never had to do for like 12 years or so using Windows), but maybe one of the smart guys at TDL has a hunch...

Thanks for every hint...

Edit: I should add that so far I cannot reproduce the problem so far with tests in S1 or Reaper, so it is actually very Cubase-specific, even if Steinberg doesn't want to acknowledge that.

Post

Hi, same problem for me.
Yesterday, I have updated to Cubase 10.
I will report it if the problem still exists.

Post

Same bug in Cubase 10 (Windows 10) with all my TDR plugins (Kotelnikov-GE, NOva-GE, SlickEQ-GE, Slick-M), all in last version.
Cubase freeze when I close or replace a TDR plugin in the rack of the console.
This bug has been there for at least 1 year.
So I can not reasonably use these plugins for working and I'm very disapointed because these plugins are very pleasant.
I'm very anxious that they finally become usable in Cubase.

Post

This is interesting, thanks for reporting. Do you get the same with other plugins?

I currently have no idea what causes it, but if it's something that relates to our own code, we'll fix it of course.
Fabien from Tokyo Dawn Records

Check out my audio processors over at the Tokyo Dawn Labs!

Post

DomDomDom wrote: Thu Nov 22, 2018 9:51 am Same bug in Cubase 10 (Windows 10) with all my TDR plugins (Kotelnikov-GE, NOva-GE, SlickEQ-GE, Slick-M), all in last version.
Cubase freeze when I close or replace a TDR plugin in the rack of the console.
This bug has been there for at least 1 year.
So I can not reasonably use these plugins for working and I'm very disapointed because these plugins are very pleasant.
I'm very anxious that they finally become usable in Cubase.
Hmm, this is not exactly my behavior. I can insert the plugins and work on the project, but when I close the project, Cubase goes into a deadlock...
edit: although, on second thought, I remeber one time I encountered the problem when I unloaded a plugin from the insert rack, but I cannot remember whether it was Slick EQ or a Tonebooster plugin...
Last edited by fese on Sun Nov 25, 2018 5:26 pm, edited 1 time in total.

Post

FabienTDR wrote: Thu Nov 22, 2018 8:21 pm This is interesting, thanks for reporting. Do you get the same with other plugins?

I currently have no idea what causes it, but if it's something that relates to our own code, we'll fix it of course.
To be fair, I am relatively sure that my problem is not especially related to your code. For starters, I've only experienced the problem with Slick EQ (GE), not with Slick EQ M, Kotelnikov or Nova.

Cubase support claimed that is was the problem of an old Direct-X Library, probably because the calls to those d3*/d2* methods in my stack trace. I have pretty much proven them wrong by test installing a fresh Windows 10 from a newly created install image with nothing on it but Cubase 9.5.41, RME drivers and Slick EQ GE and Toneboosters V3 Plugins, and doing tests in Reaper and Studio 1 where I had no problem.

It also happened only with VST2 plugins so far.
I don't think my setup is in any way special, an Intel 8700k-System with Windows 10 and a Fireface UCX.
It is really annoying and I cannot use some of my favorite plugins if I don't want to kill Cubase everytime i close a project.
And I hate surrendering to computer problems...

Could you tell me what version of which VST-Framework you used for Slick EQ? Is it different than that for your other plugins? I am trying to find out whether there is some similarity between those plugins that cause the problem.

Post

This gets weirder and weirder. I just did a test row where I inserted sevral Slick EQ and TB instancesand then did the following:
1. open the project, keep it playing for 15 minutes - close it - no hang
2. open the project, open a few plugins windows, close them, keep it playing for 15 minutes - close it - no hang
3. open the project, open a few plugins and tweak some knobs, keep it playing... you know the drill.

I haven't been able to create the situation in a testing scenario, only when I am really working on a mix, that is switching between different plugins, opening windows and closing them, doing this and that.

I have loads of memory dumps and thread dumps lying around, if anyone is interested. I am not a developer so my debugging skills are sadly nil...

Post

I seem to recall that once there was an issue with a new version of Cubase, working on a project from the previous version. Doing a "save as" of the project, or something like that (I am not in front of that PC now), seemed to update it and fix the problems. I don't know if this makes sense to you, but there's no harm in trying.

Post

pumafred wrote: Sun Nov 25, 2018 7:04 pm I seem to recall that once there was an issue with a new version of Cubase, working on a project from the previous version. Doing a "save as" of the project, or something like that (I am not in front of that PC now), seemed to update it and fix the problems. I don't know if this makes sense to you, but there's no harm in trying.
Thanks, but I did test with a a complete fresh install of windows 10 and Cubase 9.5.41, made a new project and it still hung on project close :(

Post

OK, so there is someone else with the same problem, except this time it seems to be Limiter6 (the old one, as far as I can see)

Code: Select all

.  0  Id: 1c9c.9f4 Suspend: 0 Teb: 00000000`002b1000 Unfrozen
 # Child-SP          RetAddr           Call Site
00 00000000`0014d718 00007ffc`cb4b9252 ntdll!NtWaitForSingleObject+0x14
01 00000000`0014d720 00007ffc`ab238c7d KERNELBASE!WaitForSingleObjectEx+0xa2
02 00000000`0014d7c0 00007ffc`aaf8e576 d3d10warp!ThreadPool::WaitWhileBusy+0xdd
03 00000000`0014d840 00007ffc`aaf5cba6 d3d10warp!UMContext::FlushAllRenderingTasks+0xfc6
04 00000000`0014e0e0 00007ffc`aaf5ac38 d3d10warp!UMDevice::Destroy+0xb6
05 00000000`0014e1c0 00007ffc`aaf68185 d3d10warp!UMDevice::`vector deleting destructor'+0x28
06 00000000`0014e200 00007ffc`c7870b7c d3d10warp!UMDevice::DestroyDevice+0x55
07 00000000`0014e240 00007ffc`c78733b8 d3d11!NDXGI::CDevice::DestroyDriverInstance+0x5c
08 00000000`0014e2a0 00007ffc`c786763a d3d11!CContext::LUCBeginLayerDestruction+0x7c
09 00000000`0014e2f0 00007ffc`c7867982 d3d11!CUseCountedObject<NOutermost::CDeviceChild>::UCDestroy+0x19a
0a 00000000`0014e320 00007ffc`c787e2ab d3d11!CUseCountedObject<NOutermost::CDeviceChild>::UCReleaseUse+0xb2
0b 00000000`0014e350 00007ffc`c786b100 d3d11!CDevice::LLOBeginLayerDestruction+0x11f
0c 00000000`0014e380 00007ffc`c7867ef5 d3d11!NDXGI::CDevice::LLOBeginLayerDestruction+0x10c
0d 00000000`0014e3d0 00007ffc`c7867dab d3d11!NOutermost::CDevice::LLOBeginLayerDestruction+0x25
0e 00000000`0014e400 00007ffc`c7867cf4 d3d11!TComObject<NOutermost::CDevice>::~TComObject<NOutermost::CDevice>+0x23
0f 00000000`0014e430 00007ffc`c7867d74 d3d11!TComObject<NOutermost::CDevice>::`scalar deleting destructor'+0x14
10 00000000`0014e460 00007ffc`c78a84bb d3d11!TComObject<NOutermost::CDevice>::Release+0x44
11 00000000`0014e490 00007ffc`c7864934 d3d11!ATL::CComPtr<IUnknown>::~CComPtr<IUnknown>+0x4b
12 00000000`0014e4d0 00007ffc`c7c27735 d3d11!CLayeredObjectWithCLS<CBuffer>::CContainedObject::Release+0x2c4
13 00000000`0014e520 00007ffc`c7c5f929 d2d1!CHwSurfaceRenderTargetSharedData::~CHwSurfaceRenderTargetSharedData+0x1f5
14 00000000`0014e550 00007ffc`c7c5f9d7 d2d1!InitializableObject<RefCountedObject<CD3DDeviceLevel1,LockingRequired,DeleteOnZeroReference> >::`vector deleting destructor'+0x29
15 00000000`0014e580 00007ffc`c7c5fead d2d1!RefCountedObject<CD3DDeviceLevel1,LockingRequired,DeleteOnZeroReference>::Release+0x47
16 00000000`0014e5b0 00007ffc`c7c5e7c9 d2d1!CD3DDeviceManager::D3DDeviceInformation::`scalar deleting destructor'+0x2d
17 00000000`0014e5e0 00007ffc`c7bbfb34 d2d1!CD3DDeviceManager::~CD3DDeviceManager+0x71
18 00000000`0014e610 00007ffc`c7c00a00 d2d1!D2DFactory::~D2DFactory+0xbc
19 00000000`0014e650 00007ffc`c7c009e9 d2d1!RefCountedObject<D2DFactoryLocking<MultiThreadedTrait>,LockingRequired,DeleteOnZeroReference>::`vector deleting destructor'+0x14
*** WARNING: Unable to verify checksum for Limiter6-x64.dll
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for Limiter6-x64.dll - 
1a 00000000`0014e680 00000000`2ef0e4fa d2d1!RefCountedObject<D2DFactoryLocking<MultiThreadedTrait>,LockingRequired,DeleteOnZeroReference>::Release+0x39
1b 00000000`0014e6b0 00000000`2ef20de8 Limiter6_x64!VSTPluginMain+0x1a4da
1c 00000000`0014e6e0 00000000`2ef1dc1e Limiter6_x64!VSTPluginMain+0x2cdc8
1d 00000000`0014e730 00000000`2ef1ddb5 Limiter6_x64!VSTPluginMain+0x29bfe
1e 00000000`0014e780 00007ffc`ce2c4063 Limiter6_x64!VSTPluginMain+0x29d95
1f 00000000`0014e7c0 00007ffc`ce2cff81 ntdll!LdrpCallInitRoutine+0x6b
20 00000000`0014e830 00007ffc`ce2cf5ae ntdll!LdrpProcessDetachNode+0xf5
21 00000000`0014e900 00007ffc`ce2cf955 ntdll!LdrpUnloadNode+0x3e
22 00000000`0014e950 00007ffc`ce2cf8d3 ntdll!LdrpDecrementModuleLoadCountEx+0x71
23 00000000`0014e980 00007ffc`cb49bced ntdll!LdrUnloadDll+0x93
*** WARNING: Unable to verify checksum for VSTPlugManager.dll
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for VSTPlugManager.dll - 
24 00000000`0014e9b0 00000000`059e6f3a KERNELBASE!FreeLibrary+0x1d
25 00000000`0014e9e0 00000000`059e802c VSTPlugManager!InitDll+0x330eb
26 00000000`0014ea20 00000000`059e00f5 VSTPlugManager!InitDll+0x341dd
27 00000000`0014ea50 00007ffc`cbf4786d VSTPlugManager!InitDll+0x2c2a6
28 00000000`0014ea80 00007ffc`cbf467f8 user32!UserCallWinProc+0x25d

Post

fese wrote: Mon Nov 26, 2018 7:32 pm Thanks, but I did test with a a complete fresh install of windows 10 and Cubase 9.5.41, made a new project and it still hung on project close :(
Ah, memory coming back. Did you try trashing Cubase’s Settings (or was it Preferences) file? (After backing it up, of course.) let Cubase create a new one.

Post

pumafred wrote: Wed Nov 28, 2018 1:32 am
fese wrote: Mon Nov 26, 2018 7:32 pm Thanks, but I did test with a a complete fresh install of windows 10 and Cubase 9.5.41, made a new project and it still hung on project close :(
Ah, memory coming back. Did you try trashing Cubase’s Settings (or was it Preferences) file? (After backing it up, of course.) let Cubase create a new one.
I use a completely new profile. No old settings, that was my idea. No help...

Post

Interesting stuff

*** WARNING: Unable to verify checksum for Limiter6-x64.dll
*** ERROR: Symbol file could not be found. Defaulted to export symbols for Limiter6-x64.dll -

This looks like a debugger attempting to connect to the DLL. Why does it do that? (or do you run a debug edition of Cubase?)
Fabien from Tokyo Dawn Records

Check out my audio processors over at the Tokyo Dawn Labs!

Post

FabienTDR wrote: Thu Nov 29, 2018 2:54 am Interesting stuff

*** WARNING: Unable to verify checksum for Limiter6-x64.dll
*** ERROR: Symbol file could not be found. Defaulted to export symbols for Limiter6-x64.dll -

This looks like a debugger attempting to connect to the DLL. Why does it do that? (or do you run a debug edition of Cubase?)
That is just me having opened the memory dump of Cubase in windbg and having a look at the thread stacktraces. This is how I finally found out which plugins caused the problem.
And of course windbg cannot find a symbol file for Limiter6, i don't have it :)
I can provide the memory dumps, if that helps...

Post

It seems that this problem may be related to older versions of VSTGUI and DirectX. At least a developer of another plugin I had the same problem with gave me a beta version of his plugin compiled with VSTGUI 4.3 (instead of 4.0.x) and that fixed the problem, I never had another hang with this plugin since.
Hopefully, those who use VSTGUI may have the possibility to fix the problem.
As far as they do not depend on an earlier version of VSTGUI (<4.3), they can update to 4.3.
Those who do not use VSTGUI (or those who would like to know more about this issue) should check a diff between VSTGUI 4.2 (or 4.0) and VSTGUI 4.3.
The following file, especially… and its ~D2DFactory destructor in particular (+ the “useCount” usage in v4.3):
lib\platform\win32\win32support.cpp
If one uses VSTGUI, it should then be worth starting by debugging this destructor.
There is a commit to this file which might relate to the problem (" fix too early unload of the D2D libraries when multiple frame objects are created"):
https://github.com/steinbergmedia/vstgu ... 1a68ba51ef

Post Reply

Return to “Tokyo Dawn Labs”