Since this came up recently, I decided to write a little tutorial on how to analyze Cubase Crash dumps on Windows 10 (and probably 11, too). This can be helpful if you want to find out if it is a specific plugin that is the culprit for the crash.
Before you do that, have a look at the windows event log, though, sometimes there is an error message in the Windows->Application section that says something like “The Application Cubase crashed in the module ‘WaveShell1-VST 10.0_x64.dll’”. Then you know the problem dll already.
DISCLAIMER: I don’t claim to be an expert in debugging binary programs. This is just what I taught myself to get to the bottom of some Cubase crashes. If in doubt, better upload the crash dump here in a post and let good old Martin Jirsak do his work!
Download the “WinDbg Preview”-App from the Microsoft Store (Microsoft Apps), start it and from the File menu, select “Start Debugging” and “Open Dump File”. Then browse to the Crashdump directory in “Documents\Steinberg\Crashdumps” and open the dmp file.
In the command line of the “Command” window, type “.ecxr” and “k”, this will show the stack trace of the module that crashed:
At the bottom of the screenshot you see the Name “Transient_Master”. This is the name of the plugin that most likely crashed. If you don’t see the name of any plugin in the stack trace, the crash probably happened somewhere in Cubase itself.
A couple of years ago, I encountered the dreaded “Cubase hang on project close” problem. The culprit is usually a plugin. But how to find out? In this case, start WinDbg, but Select “File->Attach to Process” and then select Cubase. Do this when you already closed the project and Cubase hangs. Now just type “k” in the command window. You then get a stack trace, which can be really long. In there, search for a plugin name that you used in the project. Most likely, this is the culprit for the hang.
(This is an old excerpt from C9.5 . The problem was the TB_Compressor_V3 plugin, which was built with an older version of the VSTGUI SDK which contained a bug. The dev switched to a newer version and the problem was gone. )
Windbg then analyzes the dump and spits out a lot of text, most of which is not relevant for us, but if you check the section around “MODULE_NAME”, it can give you a hint in which DLL the problem happened, for example:
I think that’s indeed ‘outdated’ info.
Just let that ‘analyze’ function run and if an ‘interesting exception’ is found, it will show at least which plug-in is to blame
It’s not outdated info, it works in WinDBG Preview just as it worked in old WinDBG, and gives you pretty much the same result.
It is of course simpler to just click on the “!analyze -v” text.
I just wanted to thank you for putting this up. I analyzed the crashdump. For me it was Komplete Kontrol. I reinstalled it and it seems to be working now. Thanks again so much. This was driving me insane.
Hi,
I followed instructions from fese and I managed to open the CrushDump once , but when I wanted to open other dmp file (after WinDbg restart) it stopped to read dmp files, Now everytime
I want to open any dmp file I have nothing but this
