Better way to handle projects that won't open due to a crashing plugin. Here's an example and a workaround that I use:I have a current project that won't open because it's complaining about the following plugin:
FabFilter Pro-MB (Mono).dll
This happens to be the VST2 version of the FabFilter Multiband Comp. I have several instances in a large project. I don't know which instance is causing the crash. I'll use this plugin name in the following workaround.
Currently one has to load the project in safe mode and go through an extremely tedious task of going through the plugins one by one and disabling all the ones called "FabFilter Pro-MB (Mono).dll"
Here's a better workaround for now.
Rename your plugin in the folder where it exists to "FabFilter Pro-MB (Mono).old" or whatever .extension you want.
Open the Cakewalk project as normal, it will complain about not finding the plugin, however the project loads fine and the instances of FabFilter Pro-MB (Mono) are still on my tracks.
Disable each instance in Cakewalk.
Close Cakewalk.
Rename the plugin extension back to .dll
Re-open the project. Cakewalk detects the new plugin and the project opens fine.
Re-Enable your instances of "FabFilter Pro-MB (Mono).dll" until the offending one causes a crash.
After the crash and subsequent task manager end process that I have to do sometimes on the Cakewalk exe, I can go back in the project, open the offending plugin instance and save the settings. It's still disabled at this point but I can open it and see and save the settings. Delete the plugin and re-add then load the settings.
It still crashed however ...hmmm
It turns out that I was using the mono version of the plugin on a stereo track.
The upshot of all this is that surely in this day and age there must be a better and slicker way to deal with issues like this and I think this needs a big overhaul in the Cakewalk code. Plugins need to run in a sandboxed environment maybe?
Hope this debugging workaround proves useful?