It could possibly be Waves. There were some extensive threads about waves issues a few days ago.
Here is a KB article to read and troubleshoot about waves compatibility.
My best guess is this is the problem. Please send a dump file with the crash and make sure you list the CWBRN number. Without that we are shooting in the dark here.
 
Regarding logging, we have very extensive logging in our beta application, but that degrades performance so its stripped out of the final release version. Windows has some event logging stuff that I have been meaning to investigate, but ultimately it will incur some finite overhead. In a realtime app like SONAR we wouldn't want to risk this. Ultimately however if you have a crash, the dump file normally has enough information to find what caused the crash in many cases.
 
You should be able to rule out waves by skipping all the waves plugins in your project. Another thing you can try and do is rename one of the waves shells to eliminate mixing and matching the plugins. If you rename the vst3 waveshell only the VST2 plugins will load. In X3C I have enhanced the migration code to handle some more corner cases that would potentially miss migration and lead to VST2 and VST3 waves plugins loaded which is bad. If your crashing stops by renaming the VST3 waveshell then we know that this is potentially your issue.

Noel, thanks for the response. The thing I'd like to see with syslogging is like this: It can be enabled or disabled when necessary. Filtering or levels of syslogging could be enabled, which would allow, for example, errors only, driver information only, Plug-in information only, Sonar.exe only, etc. Sometimes a crash will happen without warning, but other times it helps to see what was going on with the app just seconds before the crash. For me, this could improve my own troubleshooting with plug-ins failing, drop-outs, etc. If there's something Sonar doesn't like, we can fix it sooner than waiting until another release, coupled with this unseen error turns into an actual bug or problem later.
 
Windows event logs, to me, aren't typically useful for anything other than Windows, but I go through those things as well. Unix-based systems tend to thrive on syslogging and debugging tools, which is more what I'm used to.
 
Obviously, this would require extra code to be written to produce specific types and variances of errors, but at least, for the savvy, or even support, but it would be helpful to those of us who are willing to perform quite a bit of troubleshooting prior to calling Support, it would be handy. In my case, I work sessions at night (I have another daytime job). I'm never at my DAW during the daytime or Support hours, so that kills my access to such help.

I did an upgrade from X2 and was having alot of crashes caused by Amplitude.  Since that was pointed out to me in a different post I have gone into my existing projects , deleted the Amplitude plug in saved and then re added the plug in and I no longer crash as much.  Like the upgrade didn't handle the plugin well.
 
FYI

meh
I did an upgrade from X2 and was having alot of crashes caused by Amplitude.  Since that was pointed out to me in a different post I have gone into my existing projects , deleted the Amplitude plug in saved and then re added the plug in and I no longer crash as much.  Like the upgrade didn't handle the plugin well.
 
FYI

FWIW, that crash was in no way whatsoever related to X3. The crash data goes back to X1 Producer Expanded actually (since we started the automated Fault Reporter). I've tried reaching out again to see if I can find someone at IK Multimedia who can make use of the collected info (we can't proceed any further since it's not our product obviously and therefore have no source code etc.).
 
One thing I've personally picked up from looking at a lot of the fault reporting data we capture is that a lot of repeat offenders tend to be third-party plug-ins that are out of our hands. Noel and the rest of the guys have been pretty on top of squashing stability bugs in SONAR itself. VST3 implementation has sparked a new interest from plug-in devs in SONAR though, so this is excellent for all users alike since we've been communicating a lot with other companies. 
 
I have a few ideas rolling around in the back of my head regarding improvements to fault reports and how we can return some relevant information to customers more easily. For example, I would have loved you to have seen that a bunch of those reports referenced Amplitube 3 as the crash so you could have analyzed it without any interaction from Cakewalk and need to dig through crazy log files. I think we can get closer to that in the not so distant future :)

Brian we already have all of that and more in our beta builds, with specific logging granularity controls. Its pretty sophisticated and testers can turn off all logging or just specific elements. However even with all logging disabled there is a finite cost - I'd say easly a 15-20% hit in some code. There are extra conditional checks in the code and different things computed in logging enabled build so its definitely not something we'd want to ship with without careful thought. 
 
>>Windows event logs, to me, aren't typically useful for anything other than Windows, but I go through those things as well. 
 
I wasn't talking about the windows event logs. I'm referring to newer logging API called event tracing that was first added in Vista. This is a lightweight built in trace mechanism and designed for runtime logging. It creates compact binary etl files that can only be decoded by the vendor. If we do something it would be along those lines. However I need to evaluate the cost of this as well - nothing is CPU free and in realtime applications this is an important consideration.   

Could the logging function be installed as a separate app which interfaces with Sonar? One that could be uninstalled after an issue has been resolved and the program could use some efficiency. A simple toaster message could inform the user that it's running on ever start of Sonar.
 
If it's just too much to be worth it, I understand. I wasn't invited to test the Beta versions, so I'm not familiar with the facilities those have, but maybe there's some way that error messages can be understood by the user. For example, if a crash was caused by a plug-in, Cakewalk would be able to decipher that, but the user may never know, and it does take a long time for crash-responses from Cakewalk. It's frustrating to wait on something like that and still never knowing the outcome because Cakewalk doesn't share that information or inform the user what the issue might be without calling Support.
 
Thanks!

Hi guys.
 
First of all, thanks a lot for all your help. I'm also very happy to get direct support from Cakewalk staff. Very cool!
 
I've updated the thread title as the situation has improved a lot already. I think I've narrowed down the reasons for my stability problems (yes, once more the plugins!)
 
Here's what I've found / changed:

• Despite saying I don't use 32 bit plugs, there was one left in a muted backup track in a scratch track subfolder. The reason it did not cause problems in X2a was that it was configured to use jBridge. The new plug-in scan and the recommendation to reset all plugs changed that back to BitBridge. I had read that but unfortunately forgot it in the heat (sorry!) ... so once I had found that troublemaker, the random crashes were gone ...
• I got 2 more crashes when fiddling with FabFilter plugs while at heavy load and playback (e.g. changing oversampling). This made me discover that the FabFilter plugs were not auto-upgraded to VST3 although present in my system , probably because there are more VST2 plugs with slightly different names (e.g *SC ) than there FF VST3 plugs. So I manually replaced all FF VST2 with FF VST3 and dialed the same settings and since then no more crashes (fingers crossed it stays like this!)
• One more thing I had to do was to manually upgraded my custom plugin layouts as they did not longer display the WAVES VST2 plugs (which was a bit cumbersome as I have quite a few now), but now there's basically no way to mix VST2 and VST3 which did eliminate the WAVES GUI issues  I saw earlier...

 
Been mixing for a couple of hours ... no glitches, no crashes ... Times are good again!
 
Thanks again, Cake, and all the other helpful souls out there!
 
 
 

Excellent, I'm glad you were able to troubleshoot this! It can get very complicated with all the permutations of plugins you can have. I've posted this in some other threads but here is a link to a KB article that describes the Waves issue.
 
Now regarding the Fabfilter plugins, they do not support auto upgrading. You can talk to the vendor if you would like that capability. The tricky thing is that auto migration has to be planned in advance by the vendor, since it requires the VST3 guids to be authored in a very specific way. If the vendor already has shipping VST3 plugins it would be hard to change since it would break compatibility. OTOH Fabfilter doesn't have any problems running both VST2 and VST3 versions at the same time.
I'd be interested in knowing what crash you had with the older VST2 Fabfilter plugins since we havent seen issues with them.
 
As I posted on the other thread I will look into auto migrating plugin layouts that contain migratable VST2 plugins so you won't necessarily have to reauthor older layouts containing waves plugins.