• SONAR
  • How do I crash X3c? (p.4)
2013/12/04 12:22:22
Ryan Munnis [Cakewalk]
To talk about the crashes and the Fault Reporter for a moment, since I think it's useful information...
 
The focus of the Fault Reporter was to collect crash info so that we can resolve stability issues and have people not have to focus on that. This got rolled out in SONAR X1 Producer Expanded and after collecting a lot of data we've squashed tons of stability bugs.  More often then not nobody in support can resolve a fundamental crash, which can lead to dead ends between support staff and customers. We can always make suggestions on how to improve the stability of the system overall, but if there is a particular area of SONAR that is prone to crashes we might not know the root cause of it or if we do might not be able to return any info until an update is released.
 
The fault reporter collects .dmp files from your crash, parses and analyzes it against the debugging symbols for the build of SONAR being used, and logs internal reports for developers to investigate. It's a very smart system. When I send a crash report to Microsoft or Apple from the OS I always wonder what happens with the report after the fact. I wonder if they have a similar system or if it ends up in limbo somewhere. When you send one to Cakewalk, I know exactly what happens. It becomes useful information for us and our developers are very active at using that information to make the program better.
 
We've already resolved hundreds of stability issues between SONAR X1 Producer Expanded and SONAR X3 Producer as a result of the data we were able to collect. Some of these fixes were small, some major. It took time to collect data though. The initiative at spending time creating the system has paid off already and as things progress the situation is only improving. Ironically this initiative was started by someone in support who programmed the majority of the whole system. This is why we're always telling people to use the systems we have in place. It's not to push people along, it's because we know for a fact that asking someone to send a Fault Report through if they have crashes is the most useful and time-effective way we can help customers. Customer satisfaction-wise as well as in the reports we've collected, SONAR X3 has been a very stable product.
 
Anyhow, it doesn't hurt if you're experiencing a ton of crashes to get on the phone with someone in support. They may be able to extract some useful info as to the cause of the crash (such as if it's a plug-in, or a particular behavior) that you can avoid. There's no way we can give a blanket statement as far as "avoid x, y, z in the program" however since the set of variables between systems is essentially infinite.
 
I think ultimately if you're experiencing a lot of crashes, send some Fault Reports through if you're connected to the internet. If not, get on the phone with support and we'll take a stab at parsing the info manually so we can try to identify what is at fault and point you in the right direction, or if necessary, log reports internally the old fashioned way.
2013/12/04 12:31:23
dubdisciple
Sometimes I think some people are happiest being unhappy. I know things have not went exactly according to your liking, but continually casting shade on the person trying to help you seems counterproductive.
 
+1 to the post about dragging fx to another fx bin while playing
2013/12/04 13:01:03
SilkTone
dubdisciple
Sometimes I think some people are happiest being unhappy. I know things have not went exactly according to your liking, but continually casting shade on the person trying to help you seems counterproductive.
 
+1 to the post about dragging fx to another fx bin while playing




I used to be happy being happy. However now I'm unhappy being unhappy.
 
BTW I'm not "casting shade" on Ryan in particular. I'm pointing out that the whole system is broken. It seems the system has been improved (as Ryan explains) since this issue has been brought to CW's attention, however it has failed for this particular issue.
 
I would gladly submit a crash dump but hopefully someone else does since I'm not using X3c at this point. Maybe it isn't required since Ryan is saying the devs are looking into the issue (although see post #27 regarding devs being aware and looking into it). Keeping fingers crossed.
2013/12/04 13:42:51
Splat
FreeFlyBertl
lawp
i believe we need what is commonly referred to as a "known issues list"...




ideally, yes, but we'll never get an official up-to-date one (I reckon that's quite adverse for marketing to have something like that online) ...
 
so, here's the place to start the inoffical one ;-)




Somebody did the same thing last month.
 
Your original post "One thing I've come to realize is that X3c does not like projects or templates created in X2; using them will eventually bite you "...

So I shall start. This is an issue known to your environment and not mine.
Until you have specific steps to reproduce that can be recreated on other environments I will not regard it as an "known issue" rather an issue to do with your environment.
2013/12/04 13:55:58
Splat
So I've just completed reading this thread since my initial post. The way the thread has gone is pretty predictable, everything gets bent to peoples agendas (right or wrong). It really is only best to discuss about specific issues on a thread.
 
The only people who can give us a known issue lists is Cakewalk. If Cake confirm something as a known issue then I regard is as a known issue. If Cake has confirmed issues through their bug tracker then yes it might be a useful post assuming Cake is directly quoted.
 
If something is under dispute then Cake should be contacted directly.
 
Keeping track of bugs on a thread is near impossible (that's why you have to search and research everytime you come across an issue), and it's hard enough with real bug tracking software.
2013/12/04 20:31:41
icontakt
Andrew Rossa [Cakewalk]
We are working on a new patch, SONAR X3d, that will have lots of fixes and enhancements to an already stable program. 

 
Thanks for working hard on it. Will it be out by the year end?
2013/12/04 23:36:20
Anderton
Well, I've found a way to crash Sonar 100% of the time, and this is repeatable:
 
1. Install Sonar X3 on any laptop with an Intel processor having more than two cores.
2. Upgrade to X3c without upgrading to X3b first.
3. Open a Sonar project containing at least one virtual instrument and one VST plug-in.
4. Disconnect the laptop from its power supply.
5. Throw the laptop out of a second-story window with an unobstructed path to the ground.
6. Sonar will crash.
2013/12/05 00:23:14
Splat
Please close all windows and disable 64 bit engine.... ;)
2013/12/05 04:59:29
Bristol_Jonesey
Anderton
Well, I've found a way to crash Sonar 100% of the time, and this is repeatable:
 
1. Install Sonar X3 on any laptop with an Intel processor having more than two cores.
2. Upgrade to X3c without upgrading to X3b first.
3. Open a Sonar project containing at least one virtual instrument and one VST plug-in.
4. Disconnect the laptop from its power supply.
5. Throw the laptop out of a second-story window with an unobstructed path to the ground.
6. Sonar will crash.


Thanks for the heads up Craig - I was planning on doing this tonight!!
2013/12/05 05:53:50
worstcaseontario
Anderton
Well, I've found a way to crash Sonar 100% of the time, and this is repeatable:
 
1. Install Sonar X3 on any laptop with an Intel processor having more than two cores.
2. Upgrade to X3c without upgrading to X3b first.
3. Open a Sonar project containing at least one virtual instrument and one VST plug-in.
4. Disconnect the laptop from its power supply.
5. Throw the laptop out of a second-story window with an unobstructed path to the ground.
6. Sonar will crash.


I can confirm that this also works on desktops with AMD processors.
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account