Why tell me Steinberg why? Why you can’t for the Christ’s sake, make this product stable with any VST? Why it has to crash every time when I record something spectacular I am proud of? I was using Cubase 11, it was crashing. Now evealuating Cubase 14 - it crashes less, but on the other hand at more unpredictable and more undesired moments. I am angry, desperate, sad and .. I have no idea what I am even more.
My question - the Cubase crashed 30 seconds after the track was recorded. I started Cubas again but the backup file is much older, of course the new recording is missing. Where do you store recorded tracks? Hopefully NOT in the product file itself? Tell me that I can find my best song of the world (this was NOT just a tribute). Thank you
Hi,
Please, attach the *.dmp/ups file, so we can have a look, where does the crash happen.
It’s probably not ideal to try and explain this when you’re so upset, but 3rd party VSTs are other people’s code. Some DAWs purport plug-in sandboxing which can help, but that can’t make a poorly written plugin “good.” The only reason I’m trying to explain this is because if you’re blaming SB (or Ableton, or Avid, or Apple, etc) for a poorly behaving plugin, then you’re missing the opportunity of fixing the root cause of the issue, which I bet is what you’re really after. The crash file Martin as asked for will help forum members help you.
Regarding the recorded track, if it actually got recorded, then it should still be in whatever folder you’ve set Cubase to use for audio; so hopefully that will be recoverable.
The product is stable, it is that it is just not really a very good idea to try and trigger VST plug-in’s live, on vastly underpowered systems (such as what I use), and even if I had a decent system, it’s not really something I personally would engage in, hence why I use a keyboard that has MIDI out over both DIN and USB, since I trigger a hardware module while playing and the DAW simply records the performance data, of which I later playback using virtual instruments, that these days at least, actually sound better than hardware.
I know the future may be virtual but if you want reliability, Steinberg even say themselves that plug-ins are almost always the main reason for system crashes, and this is not simply due to the fact of poor coding, crashes can still occur, even when using the latest VST version (it is 3.7.9 I believe).
Steinberg should develop a VST3 or ASIO Driver validation utility that runs a test on plug-ins and drivers and flags any that fail.
DP has a validator and I have had a situation where Cubase was crashing due to a buggy ASIO driver and I didn’t realize where the issue was until the driver failed validation in DP11.
Once I replaced the interface, the crashes ceased. DP also has a VST Validator which predictably failed some plug-ins (usual suspects that were problematic at the time, like iZotope and Native Instruments).
The plug-ins would fail and not show up in the Browser, so the issues were avoided by simply disallowing the user from using them in the DAW. Sucks, but IMO the best way to force developers to put more effort into prompt troubleshooting and bug fixing.
Ok I am cooled down. I understand that the VST plugins can be hell, the same way how drivers can suck in Windows even if the publisher is certified. In the past I had more problems with Addictive Keys, I switched to Kontakt8, it got much much better. Also in general the Cubase survives when I close the notebook lid, it wakes up and it works… In cubase11 it was not the case. Crashed always.
My notebook is the best hardware that DELL could have offered 1-2 years ago (XPS with i7, 64gb RAM). But I think that this is the issue anyways - notebooks CPUs suck hard… The performance is incomparable with desktop CPUs. So I guess i will just assemble some desktop PC for Cubase and give it a shot.
Btw Cubase crashed at closing the video preview (yes I have video track in my project and I like this feature A LOT).
You could try this free utility to help you manage your VSTs
Steinberg afaik does a check on first scan of a VST3 plugin, and if it detects something, the plugin will land in the blacklist. But it only can validate the VST3 interface, not what is happening inside a plugin (e.g. all GUI-related things, OpenGL, internal preset management and so on). That is impossible.
Only way around that would be sandboxing, which of course has its own downsides (performance overhead e.g.)
You should upload the Cubase crash dump here, as Martin Jirsak suggested (from your Documents\Steinberg\CrashDumps-Folder. If it is caused by a plugin, we can tell which one, if it is a Cubase-problem, Martin can forward that to Steinberg.
That doens’t really address the ASIO drivers.
Have a couple interfaces here that will even be available in DP because the driver fails the validator, but Cubase will use it and have random crashes, lost audio device errors, etc. all the time because of it.
So, MOTU has figured out a way to run some sort of validator when you select a driver which allows DP to know that there is an issue with it, while Cubase just lets you use anything.
There are also some known buggy plug-ins (that I have access to) that Cubase will validate and allow you to use, but DP will fail with its validator… So, whatever Steinberg is doing… it is definitely not the same thing as what MOTU is doing (which seems far more comprehensive, and far more accurate in detecting problem audio drivers and plug-ins).
This has always been the case since I first tried DP11 back in 2022 or so. Can be infuriating if you’re used to (or willing to) just deal with issues and power through it, but otherwise can save a lot of grief (and perhaps some money, since you’ll know pretty quickly if an audio device is jacked up and can just return/exchange it ASAP for a different device).
I honestly had just chalked up the ASIO bugs to “Cubase instability,” and it literally had me looking at alternative DAWs.
Cubase VST ‘back in the day’ MADE you test your audio hardware when you first ran the application.
It did a whole run through testing input and output, showed you the buffers, how much was lost, etc.. Basically if you didn’t have a card with an ASIO driver, it always told you ‘your device is going to suck under MME’ and would warn you but it would still let you go on afterwards hah. Although if it had enough trouble with your card, sometimes it would disable recording, output or even both if the card was THAT bad hah.