More crashes with X3b than X2a (mostly solved: another plugin related issue)

You might want to try and reinstall X3 over your current X3 installation.  Perhaps some file is corrupted.  And/or try running scandisk for disk errors in files / sectors.  Then reinstall X3. Other than that it would be a mystery, X3 is pretty rock solid.

Thanks for trying to help.
 
Further info ...

• No Microsoft updates (DAW is off the net, so no auto-updates)
• the project that I work with is using Kontakt 5 samples, which take about 3.4 GB RAM (out of 32 GB); K5 is updated to the latest availabe version
• X3b was the 2nd last installed program (additive drums came after)
• Audio drivers are same as before (were not reinstalled)

 

Have you checked Reliability Monitor or Event Viewer to see what they report?

Just for experimentation's sake, do these crashes occur if you open a project in 'safe' mode, with no plugins loaded?
 
Many of the X2a and prior release crashes occur due to plugin issues, and within those, many of those are due to problems with some 32-bit plugins being loaded into projects in a 64-bit Sonar.  
 
BitBridge and some of the 32-bit plugins just do not seem to play nice together, and while folks have reported greater stability using 32-bit plugins with another bridging piece of software called JBridge, some 32-bit plugins can still fail in 64-bit Sonar.
 
IF this ends up being the culprit for you with X3b, then you might consider either swapping those 32-bit plugins out for 64-bit ones, or checking for 64-bit plugin availability for the ones you do have in 32-bit, or you could install a 32-bit version of X3b and use that one for projects that fail using 32-bit plugins in 64-bit Sonar, as 32-bit plugins will be more stable in a 32-bit Sonar.
 
Bob Bone
 

brconflict
I'm going to bust a vein if the answer it No, but...
 
Does X3b have a syslog or debug function, with the ability to enable and use it locally?? I'm genuinely asking for input here. Although I'm not currently having trouble with X3, not having this function in X2 was 50% of the reason I cursed X2 daily. I could have saved myself considerable frustration had I had this ability to review a Syslog. It's so backward to think that Support can resolve the occasional intermittent crash at the time of the incident. Crash reports don't go to Support (correct me if I'm wrong), so those don't help the user, especially if the issue isn't Sonar.

Brian,
 
I can't tell you how much I would appreciate this! This is a key feature for any power user of professional software, especially if it interfaces with 3rd party plugins and hence makes almost every system unique in some respect.
 
@ gswitz: I do agree that these crashes (although they seem rather random) probably have one common reason (and a user-readable log file would be killer in that respect!) ...
 
@ noel and bob: I had these random crashes in heavy duty projects first with X2a until I eliminated (almost) all 32bit plugs (and labelled the remaining ones with 32bit) - so there's definitely nothing 32bit used here ... but I do suspect that it might be coming from either WAVES (only a few plugs involved here, mostly S1), FabFilter (heavily used) or Kontakt 5 (2 instances) ...
 
I'll try to narrow down the potential troublemakers and hopefully can provide more info soon. I also need to go searching for crash dumps as Sonar just hung / froze but did not seem to write anything ...
 
 
 
 

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.

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 :)

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!

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.