Corrupted Project / "Cubase 6 Has Stopped Working" *SOLVED*

Fully updated Windows 7 64-Bit, Cubase 6.0.4, 32-bit
After working on a song for 2 weeks now, and manually incrementally saving .cpr files (title1, title2, title3), suddenly the project will not open now. As it is loading the audio channels/VSTis, I get an error message saying “Cubase 6 has stopped working” and it just shuts down. Sometimes it will hang while shutting down, forcing me to restart the machine. Most of my 10 incremental backups do not load – the first 3 do but that’s not very helpful. The fact that suddenly the most recent 7 of them won’t open suggests that a rogue VSTi is causing the issue (perhaps something that wasn’t present in the first 3 .cpr’s). The error message comes up when a 3rd party plugin is loading – so I remove that plugin from the VSTplugins folder and it is able to now load past that ostensibly rogue plugin, but now it freezes on a DIFFERENT 3rd party VSTi. I remove that one, and then 3rd, and 4th plugin causes the issue. The issue clearly can’t be 4+ plugins all “going bad” at the same time. FWIW, I have all my 3rd party plugins located in one subfolder in my c:\program files\steinberg\VSTplugins folder, and when I move that subfolder to the desktop temporarily (to bypass ALL suspected rogue plugins), the project DOES load, however all of the 3rd party VSTi’s are missing as expected. I then tried saving the project as a new .cpr, and then shut down Cubase 6, then put the 3rd party plugins folder back where it belongs, and then start up this new .cpr file, and the project still loads, but the 3rd party plugins are still missing even after putting them back to their native location. Weird. And yes I updated the plugin information in the “Devices” dropdown.


I’ve had trouble in the past with the memory being used up by plugins. If it all gets used up then for me Cb becomes unstable in the way you describe. Granted, I’ve been on XP/32bit in these instances but perhaps the same applies in W7/64? Watch the memory usage using the TaskManager and see. To avoid this problem I simply had to simplify my orchestral splits so I was using less memory in total.

I also took (and still take) the precaution of creating presets for each of my instruments’ settings per project so that if it all corrupts I at least I can reload the instrument settings which otherwise would be ‘hidden’ in the corrupt project file.

And, I keep all backups forever… I use alt-shift-S to save incremental versions very regularly as well as leaving auto-backup on 5 minutes with max versions. I also regularly save my own manual numbered backups with a comment so I know what I’ve done to the project. Belt and braces, that’s me. I manually transfer all my unused project files into a Development folder to keep the top level tidy. Hmm, I also regularly back up to 2 mirrored 2TB USB hard disks!!


Thanks for the reply Mike – and that’s not a bad idea at all. And to the memory thing, I have 16GB, and have only 3GB or so in use at the time of each crash. Doesn’t appear to be memory related.

Anyone else? I have this project due and have to finish it today! :frowning:

Also, the same crashing happens when I open the project file with Cubase 5, 4, and SX. I can’t account for whether it would or wouldn’t work in those prior versions, but the same crash happens nonetheless.

Note that 32bit plugins which are bridged are limited to 4G memory because they run in a 32 bit wrapper. Could any one of your plugins be taking up loads of that in another process? For that matter, I’m unsure if the 32 bit wrapper is for all plugins or just for one - thought it was one each but maybe not? Running out of ideas…


Well, I’m using 32-bit version of Cubase 6 – had enough woes with the whole JBridge thing and called it a wrap with 32bit C6. In using Windows 7 64-bit, I do get the 16GB of memory available – as u also stated, I’m not sure how it gets divided up either.

Ah, that would be something to do with it… You’re running Cb 32bit, you’re therefore in a single 32bit wrapper which will include the plugins as well. Now, if you’re hitting 3GB then maybe that’s the ceiling?? I know that on my XP DAW I’ve got the 3GB (PAE) BIOS switch on, yet I get crashes when I go above 1.5GB memory despite theoretically being able to use more of my total 4GB installed for each process.

Info from this MS website indicates that you would either have a 2GB or a 4GB limit on your 32bit process within 64-bit windows depending on the setting of the IMAGE_FILE_LARGE_ADDRESS_AWARE variable… I’m not an expert at all, doesn’t mean that much to me - you may find more if you search on Google about these things.


Update: After about 8 hours of tinkering, guessing, restarting, and toiling, I’ve found the ONE bad plugin, a 3rd party VSTi called Timefreezer. For the record, when the project file would crash while loading, it would happen while --according to the info bar – loading OTHER channels: other VSTi’s, audio channels, etc. This lead to confusion, as I was aiming my sights at THOSE channels/VSTi’s, and not Timefreezer, the actual problem.

For the record, Timefreezer works fine in different projects, just not this “corrupted” .cpr file. After unloading, saving, and reopening the project, I can subsequently open a fresh instance of Timefreezer, save the project & reopen it, all without a hitch.

Anyway, problem appears to be fixed. Thanks Mike for the support!

How did you identify the one bad plugin??? I’m having the same problem on 2 projects.

It’s as simple [and arduous] as the process of elimination.

In a nutshell:
Within my VSTplugins folder, I have a subfolder (and subsequent subfolders) called “3rd Party” where I keep any and all non-Steinberg plugins. Temporarily, I cut this subfolder entirely and pasted it to my desktop, then started the bad project file. Of course with the rogue plugin now missing, the project loads fine. I then guess by removing half of the plugins from the project, including both whether channel plugs or VSTi’s – of course they’re not currently active, so I can’t disable them or turn them off, only remove them entirely. PS, write down your choices on paper. I do this, then save as new .cpr file, something arbitrary like xyz. I then exit Cubase entirely, then move the 3rd Party plugin folder back to it’s original location. Then start Cubase again, using the new xyz project file. If the project still crashes during startup, you know that the bad plugin was in the other half of the suspect plugins, somewhere. If it loads correctly, that means that one of the plugins that you ex’d out in the prior steps was indeed the rogue plugin. Either way, you’re halfway there. Begin the process of elimination. Could take hours if you have dozens of plugins open in the file.
PS, of course you don’t need a subfolder named “3rd Party” as I do – you could do this with the entire VSTplugins folder instead, however I had a hunch that it was a 3rd party plug, and by moving the ENTIRE VSTplugin folder, I’d have had even more candidates to sort thru, namely the native plugs which were less likely to be bad IMO.

Thanks Cory, your post was of great help to me. My situation was not as arduous as yours. (Thank God). I first tried to move my separate VST folder (That is for Native Instruments exclusively). That resides in program files (separate from Steinberg VST folders). Most of the effects plugs were either Liquid Mix or UAD. Everything loaded up fine. I took all the VST Instruments out of the panel. Closed C6 put he VST folder back in Program Files and it’s all good. Thankfully I had made Audio files of all the VSTI tracks as I was composing. Still don’t know if it was One VSTI or a combination of all but I’m stoked to be able to access both projects again. Thanks for your post.

You got it buddy – very glad to be of help. This same problem has happened with a few projects thru the years, and each time it’s a different bad plugin that won’t load properly. Each time, however, the bad plugin will work fine in other projects, and in many cases will work fine if reloaded in the SAME project. But the one instance of the bad plugin in the “corrupted” file won’t load properly for whatever reason, so we have to narrow it down to discern which plugin, then unload it, save, then reload on the now-properly-working .cpr. Arduous to say the least.