Regarding viewing the crash.dmp files that can be found in:
You can also sometimes find various text based logs that might be helpful in the different directories found under:
These can be opened with any text editor.
For me, it’s pretty normal to find things unassigned, or hooked up wrong when I load up an older project (sometimes even from the same DAW version/installation!), where I was using totally different devices and plugins. In my case CuBase typically throws up the “VST Connections” window with things highlighted in red that can’t be assigned properly. At that point I have to point it to compatible devices, or leave them parked (unconnected).
In the case of missing devices or plugins, it still gives my track and lane data…it just might no longer have any input/output assignments (or the wrong ones).
Sometimes the project loads, and finds what it thinks should be a valid/working plugin (I.E. Wrong version, or maybe a plugin looking for a patch or library that no longer exists on the system). When it hands that plugin commands to load and initialize itself as intended…the plugin just might crash, and in some cases might bring down CuBase with it.
[*] Maybe I made a project with an older version of ARIA player, that is now updated and different.
[*] Maybe the project calls for a vstpreset that’s asking for a patch or preset in the plugin that has changed or no longer exists.
If you suspect a plugin might be crashing right out of the gate…try disabling ALL of the plugins in your VSTPlugin folder, and loading the project again. Of course it won’t be able to find the VST/VSTi plugins, but at least you’ll get messages to that effect instead of a CRASH. From there, you can reactivate plugins one by one until you find the culprit. (Note, always make sure to keep an untouched copy of your project somewhere as a backup…don’t be afraid to save more copies as you trouble shoot and make notes as you go).
So far in these cases, I can usually close out the problem plugin, save a new copy of my project, reopen it, and then rebuild the plugin instance.
I once tried to open a project that used an SFZ patch I had made to work with the ARIA player. Not only was the project built with a much older version of the ARIA engine, but I had also added and removed various patch libraries since making the problem project! When CuBase asked ARIA to open up all its patches, ARIA never found what it needed and became fundamentally broken. It was bad enough that it would throw up error messages and bring down CuBase when I hit ‘play’. At that point, I cleared the problem patch (discovered by looking at the ARIA engine crash logs), saved my instrument set from inside ARIA itself, exited the ARIA instance, and saved a new copy of the CuBase project.
For good measure I closed out CuBase, rebooted the system to start fresh, loaded my new copy of the project, checked the connections and let it roll a few bars in case something else is wrong as well, started a new ARIA instance, reloaded the instrument set, and at that point everything worked but my ‘missing patch’. Alas! I had remembered to save a copy of my missing SFZ along with the project…so I put that back into ARIA properly, and went back to work.
What if ARIA (or any other plugin) were crashing at a point that I couldn’t even see any useful error messages or get the project loaded, let alone salvage any of ARIA’s settings? That’s the point that I would have done as mentioned earlier, and deactivated ALL of the VST/VSTi plugins in CuBase, then methodically reactivated them one by one until I found the culprit. Etc…
You might need to save several copies of your project as you go…but the general idea is to pull out as much information as you can about what all you were using in the project last time it worked, and how things were set up in case you need to rebuild some plugin settings from scratch (or roll back to previous versions…install missing libraries, or whatever).
The point is…if a project loads, but doesn’t ‘crash’ until you try to play the project…you might be able to recover most of the project by weeding out the plugins and stuff one by one (and preserving as much as you can of that work in the process). If you can’t recover any data from the plugin, you can at least get the project loaded without the bad plugin information and rebuild that instrument later.
If it’s crashing out of the gate on you despite having launch a clean CuBase session (no VST/VSTi plugins active), and does the same on other systems, then I suppose rolling back versions until you can get the project open at least long enough for data salvaging is about all one can do?
You might find some other CuBase users you trust enough to try downloading your project from somewhere and opening it on their system.
These days, before I pack up a project for storage, or before I ‘update’ any of the software/plugins/or the OS itself, I take a moment to export all of the elements of the project (track by track, preset by preset) into the project directory. I’ll drop a text-file in the project directory that tells what plugins/patches I was using along with their version numbers.
If it’s a really important project that I know I’ll need to pull up again at some point…I just go ahead and clone all relevant partitions in the entire system to some backup media (or better yet a plug and play drive)…OS and all!
I like to make a second copy of the system partition, one that’s an identical clone, and second copy that’s had a sysprep run on the system partition (in case I have to run it on a different motherboard). While it might not be practical for you now…in the future, consider only purchasing an enterprise license of any OS you buy…that is NOT locked only to a specific motherboard. The idea is…you want something you can run a sysprep on and put in the closet, so you could hopefully plug and play it in any motherboard that’s relatively close, but not necessarily ‘a perfect match’ to what you made the project with.
What’s a $90 hard drive compared to weeks or months of working on a project?