POLL: Is C6 hanging on exit for you?

for me it ONLY happens when I have BFD in a project . I’m working 100% in x64 and have been working pretty solidly now for 3 months and the only time this ever arises is when BFD is in a project. I’ve taken to using superior drummer for most things now and when I do use BFD i quickly render as audio, however sometimes it’s not possible in the earlier stages so this is when this issue become a problem.

After track laying the last 2 days the singer came in to do vocals and I had to force quit cubase between songs, it doesn’t look good in front of clients having to do this.


exactly, or add some debugging mode where user see what’s going on on shutdown. just like when its loading you see what’s going on. when a user is forced to end task there’s no log file with any useful info to help pinpoint the problem.

but somehow other software manage to get around something like this.

and opening a ticket for something like this will be a nightmare, since first level support will want solid proof of what the problem is, going through endless troubleshooting doing basic things…

I’ve got a recent new install of C6.51 64 bit on Windows 7 and a very recent install of BFD2 64 bit. Apart from a jBridged Groove Agent3, I’m only using 64 bit software. I’ve been through brissyproducer’s four steps and I’ve not had any crashes or hangs with BFD2. I know this doesn’t help, but just wanted to register the fact that BFD2 isn’t causing any issues with my software/hardware setup, on either my desktop or my laptop.


just for the record:

You can configure cubase to not load anything on startup.
When launching cubase, not loading anything, and simply quit the app again, cubase crashes…

so, it can’t be a VST plugin issue, as there is no project loaded whatsoever, thus, no VST plugin instantiated, which could have been asked to close and never returns…

it must be something other. audio drivers or midi drivers… well, I own several DAWs and audio apps, none of them have a problem quitting.

Cubases device plugins (automap, steinbergs own SKI remote, anything)… well, even after deleting/uninstalling these device plugin dlls, cubase crashes on exit…

I hadn’t seen this until now - waiting forever for a response is just bad programming. The longest any application like this should wait would be around 1 second, if not 500ms or less.

And as the previous poster just stated, and as I have as well, a project with no plugins will also hang on exit - that points directly to a design flaw in Cubase’s exit procedure.

I’ve tried it with the Cubase “default” project with nothing in it and had it hang. It isn’t a plugin or 32-bit bridge issue. It’s just poor programming in Cubase itself that causes it to wait “forever” instead of closing the connection itself.

I have no such problem with ProTools on the same system, same controllers, same ASIO drivers. Wouldn’t it be ironic if it were an ASIO issue (Steinberg’s own protocol), and ProTools (and Sequoia, etc) worked better than Cubase in this regard?

It’s worth doing anyway. I’ve submitted one, and tech support has already responded that they’ve forwarded this issue to development. I was emphatic in explaining how this issue will never have a 100% repro, and if Steinberg only fixes issues that customers can find for them, with a perfect repro, then half of all the software bugs they encounter will never be fixed.

yeah, but remember…50% of users have zero issues. so something on your system is making it hang.

also I would guess that for Steinberg this is a non issue, since its 3rd party that makes it hang. why should they modify the exit procedure (in their view). as Chris Beuermann said…this has been going on for years and for years they just keep telling people things instead of modifying anything.

so in the end they might work your ticket and refer you to the 3rd party that’s causing the issues. though for people having problems its still worth trying I guess…

I’d just like to add that my system and cubase shuts down fine :slight_smile:


No. That is an incorrect assumption when every other vst/ASIO DAW on the same system exits gracefully every time and always has on other systems as well. Any decent software developer knows bugs in complex code are not always 100% repeatable.

One of the reasons Steinberg never fixes anything is responses like yours. If enough hobby users say it isn’t a problem the company figures they’ll make enough in upgrades and sales to users that never notice bugs they can ignore the pro users that do.

I’m actually on your side but trying to point out the reasoning Steinberg might be taking, since they’re not saying much.

maybe the’re all on vacation right now? lol

Well it’s a weird one then as I’ve been working flat out for the past 3 months and as I said this ONLY happens for me witH the x64 BFD 2 in a project.

I’ve been working on lots and lots of different types of music and putting my DAW through all kinds of different tasks and this only occurs for me with BFD.


is there anyone who is having the hang on exit,NOT using ANY cracked plugs?

BFD 2 is the culprit on my system and it’s all legit.


I’m using a legit version of Eastwest/Quantum Leap - Symphonic Orchestra Platinum and it’s causing my Cubase to hang on 95% of exits.

Running Cubase 6.5.1 on:
MacBook Pro 17"
2.3GHz Intel Core i7
16GB 1333MHz DDR3 RAM

Is Steinberg EVER going to fix this annoying problem??? It hangs on exit even if I open Cubase and do not load any projects in. After nearly 1 year of this crap enough is enough. FIX THE PROBLEM STEINBERG!!!

i was using cubase 6(one of the updates)and disnt have the hang issue for at least a year,just recently started to happen.

Yes, as some have said, it could even happen when no VSTs are loaded at all. In my case it’s the Midisport 8x8 interface, that, when used in a project, makes Cubase hang.

I keep having to pop in here every few pages or so and repeat myself, but that’s cool. :slight_smile:

That is incorrect. It is NOT anything 3rd party that makes Cubase hang. Let’s all please stop saying that it is. It isn’t.

Here is living proof that the shutdown issue in NOT plug-in related, Virtual Inst/VST related, project related, peripheral related, external synth related, video engine related, USB/FW issue related, jBridge related, VSTBridge related, 32bit vs. 64bit related, and on and on and on.


Furthermore… (repost alert!)

I have found something interesting. There are stretches where I will launch and close Cubase several times a day. With all this closing and opening, the sample editor raster gets screwed up. So to alleviate this, I frequently delete my defaults.xml file, and replace it with a back up. Well, I have never had a hang with a fresh defaults.xml file - and furthermore, Cubase seems to be fine for a certain amount of launches/closes after replacing the xml. I dont have a number, but it is more than just a few. After a certain amount of launches/closes, then it will all of a sudden hang. Then the next three or four times it wont, then it will. And back and forth. Until, I delete the defaults.xml file, and replace it with the back up. Then, no hangs for many launches/closes.

Maybe some of you want to try this. Start from scratch: delete your defaults.xml file, launch Cubase, let a new defaults.xml get created, and set everything to the way you like it (pref and key command files, ‘always on top’, etc). Close Cubase (all of the changes you just made need to be written to the defaults.xml file - that happens when you close Cubase) and immediately make a copy of the newly created defaults.xml file. Place that copy in another folder, and leave it there as a b/u - don’t move nor delete it. When you experience a hang, let Cubase close completely (gone from the TM), and then delete the defaults.xml file that Cubase uses (from the app data folder), and c&p the b/u. And see if you experience any hangs over the next several launches/closes. If it takes a while to experience a hang, this is a step in the right direction. If that’s the case, when you finally do experience a hang - repeat the process: delete the defaults.xml file from the app data folder, and c&p the b/u again. And see if you experience any hangs over the next several launches/closes.

I’d be interested to see anyone’s findings.

I agree. I spent hours on this on my system and even with NO plugins in the CubasePlugins folder, it crashes. Also note my wording here - it’s not really a hang - it’s a crash. And note the response from Cubase support “If you initialize your prefs, how many times can you use it before it hangs?” So they know exactly what the scenario is, but are for some reason unable to apply a fix that will not wreck the functionality of Cubase for half the users.

We should consider another thread : “If Cubase crashes on quit for you, are you using an external MIDI interface” Actually, I could run a Limesurvey on this and ask some pertinent questions e.g. what system, what version, plug-ins, midi - and since the responses would be anonymous, we could get some good data. What do you think?

Interesting idea and perhaps one factor, but I had Cubase hang only a day or two after a completely fresh install and only minimal preference customizations.

But since it does in fact seem to have an effect, my guess is after some time, Cubase’s preferences start to impact how/when it closes certain processes - possibly midi device drivers (since that seems to be a common thread here as well).

If I were investigating Cubase’s code, I would look at the sequence of modules and processes Cubase is exiting, writing off to disk, and drivers it closes at exit, and whether these are sequential, or allowed to overlap. i.e. - if you are letting some device driver exit routine run until you get a call back from the driver, but allowing another process to exit before it completes, the app will hang indefinitely, and could make it hard for the OS to kill the task by other means.

I now close the session (ctrl-w), wait until it closes down all tracks, then wait 3-4 seconds and hit the “x” to close Cubase, and it rarely hangs. Ctrl-q causes frequent hangs. That seems to imply Cubase isn’t elegantly handling the shutdown sequence, and since closing a program is partly a matter of timing and waiting for one process to finish before moving on, that seems like a logical conclusion. If you have a sample-VI loaded (BFD was mentioned here a few times), that may be affecting whether Cubase gets luck and ends up on the right path to shutdown correctly.
If it were programmed correctly, it would have only one option, and it would do it correctly regardless of what VIs are loaded, or what USB or ASIO interfaces/devices are connected.

ProTools doesn’t have this issue on my system, most likely because it doesn’t shutdown part of the program before it has completed all required tasks and closed all open drivers (and if there is no response from slower drivers, it probably just cuts the connection - seems simple enough).

This is where I have to chime in and issue a rather emphatic and irritated challenge to Steinberg:

Issues like this are why the pros I work with don’t consider Cubase and Nuendo professional DAWs. Cubase (and Nuendo) have some great features, but those features don’t make up for instability issues, like not being able to shutdown without rebooting the system, or trashing preferences every couple of days. I never have had to trash ProTools’ preferences, and have scored many projects for the past 18 months in PT8, 9 and now 10 without a single crash, lost project, trashed/corrupted preferences, or hang on exit. ProTools lacks Cubase/VST’s lower cpu usage, lower latency capabilities and better midi editing, but at the end of the day, one has to evalutate what saves more time (and hence, is more profitable) - a few more features, or 100% stability. The latter wins everytime in a pro environment.

After several years with Steinberg, I gave up and moved to ProTools, fed up with lingering bugs and lack of interest from Steinberg in fixing them. I’m back giving it a go only because I think I can gain some time with the better midi editing in Cubase 6.5 over ProTools, but with DP8 just around the corner, Cubase may not have a place in my studio for long.

We aren’t here to win your interest, you are here to win our ours.

The ball is in your court Steinberg. Win us over with better stability and consistency, or we’ll find move our work and credit lists to someone who will.