My PC just crashed right before I wanted to save. Ofcourse, lost a few important minutes (important because the tweaks gave JUST the right sound and now I can’t get that back).
My question is - how do we debug the crash produced by Windows? It just says App crash. Is there a way to get to the bottom of the crash?
Hi,
No, there isn’t. But most likely, it was a plug-in crash (when it crashes while tweaking a sound). Make sure, your plug-ins are up-to-date.
I used to have VC++ so I thought I could attach it to the Cubase app and debug it runtime but it will significantly slow everything down so I doubt if it’s a viable scenario.
I was hoping Steiny would have a tool for devs to debug crashes quickly. If they can release the tool privately I could use it to debug the crashes myself.
Another crash happened yesterday and today… Thats 2 crashes in two days…
Yesterday i was tuning the sound, today (just now) i was clicking through the undo history…
It would be nice if we could get a feeling of confidence and safety when we make music…
This is too unstable.
(If it comes from cubase, nvidia, dell, intel, my neighbor with a disruptor, the cat that comes to visit sometimes, here or there…p)- i dont really care, i just want to resolve this;)
Yup. I constantly feel like I’m rolling the dice when performing some operation like offline process. “Any moment now this thing could crash…”
(If it comes from cubase, nvidia, dell, intel, my neighbor with a disruptor, the cat that comes to visit sometimes, here or there…p)- i dont really care, i just want to resolve this;)
EXACTLY. It’s always some plugin’s fault. Even when I’m not doing anything and cubase hangs in the middle. Getting more productivity out of Cubase is worth a lot more than new features.
As a somewhat experienced C++ programmer, I firmly believe that all problems have a cause, and there is always a way get to the bottom of something. It’s just often very tedious.
Actually, about that… you can, in fact, attach the visual studio debugger to cubase. Both while it’s running and just after it crashes. It’s just that it’s not going to tell much, unless you are willing to try to look at the disassembly of the executable file… even then it’s not likely to help you fix it. I also doubt that Steinberg would appreciate people poking around in their assembly code much. (Even if it’s to try and diagnose errors…)
Still, there’s log files, right!? Maybe those can help?
Nope. Cubase does not keep logs. (None that I have ever been able to find, at least.)
If we did have logs it could help enormously. We could maybe see if it was always crashing right after loading a particular plugin, or right after accessing a particular configuration file, etc…
Still, even without a debugger or logs, there is still some detective work we can do to sort things out a bit more…
I have encountered 4 types of crashes so far, and a few (semi)solutions to those crashes.
That’s about the extent of the “debugging” we can do. I would say it’s about as ‘manual’ as you can get!
It sucks, but it’s better than nothing.
Solution: Contact plug-in vendor. Cubase is a host. Same as Microsoft (as a host) is nit responsible for all crashes, which happend in Windows.
Again, if the crash is in any plug-in, Steinberg/Cubase cannot affects it.
Most often: plug-in crash. See above.
Most often: plug-in crash. See above.
Admittedly, contacting the vendor is preferable to just not using the plugin, even if 99% of the time they will not be able to do anything. You got me there. This is the right thing to do, as gives them valuable feedback on how to improve, should they choose to listen. Heck, they might even have a workaround already discovered! Though, in a narrow view, that pretty much boils down to just not using the plugin. At least for me. Good luck getting a freeware’s vendor to respond! (Now, if this was caused by an NI or Waves plugin, then I would be all over them for sure!)
I know plenty well how difficult it is to design a good plugin system, having attempted to do so in the past. It is not easy, and Steinberg has done an excellent job implementing the plugin system for Cubase, not to mention designing the VST standard itself. I know fully well that a crash in a plugin is not the fault of the host. I’m not really here to blame anybody for anything. However, the frequent crashes are a problem for most of us users, regardless of who is responsible. (I’ll also just mention that part of a plugins stability is the design of the API itself, and while VST was excellent for it’s time, it might not be the most robust platform today. Not that I am a fan of the others.)
Pretending, for a moment, that there are absolutely no bugs in Cubase itself whatsoever… 
Suppose I’ve got a massive project with hundreds of plugins loaded… and it is crashing randomly when in use, but with no particular action preceding the crash. We can assume, since we have decided from the start to rule out Cubase itself, that it is caused by a plugin. We now know we must either contact it’s vendor for a solution, or to just remove the plugin.
What ‘vendor’ do we contact? Which plugin was the cause?
This is where debug tools, or a log could help. It could help, but as far as I know, we don’t have them. So that’s not an option.
That’s why I mentioned isolating the issue by removing all plugins, reinstalling, then and adding them back. (After testing each.)
That’s about the only way to track down a faulty plugin without any other leads!
Unless you know of a better way?
If you do, thank god!
I’m not usually a “+1” guy, but as someone who has purchased many plugins (I’m 100% legal), and has run into bouts of instability, followed by hours lost to determining the offending suspect, I feel that I must.
Even if the cause is because of a bug in a plugin, that bug may be benign until a new Cubase release. I ran into a slew of these when I moved from Cubase 7 to 8. And, it’s not always the small independent guys either. I’ve had issues with Celemony, Slate and Plugin-Alliance products.
The best solution would be a “sandbox” approach, so if the plug in crashes, it gets knocked out, there’s a visual indication that this has happened, but the project survives.
Second best approach would be a crash indication pointing to the offending plugin.
I know that this not necessarily an easy thing to do. But, now, the user that has made the biggest investment in plugins is the one the most likely to experience issues.
@MindWeaver and @js1 Thank you, my words exactly!