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.

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.

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.

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.

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!!

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 managed to reproduce this issue, both on my wife's, and on my laptop.  I am having to post this on my smart phone, from the spare room..
 
Sonar did not send a crash dump - the system for reporting these is obviously flawed.

Jlien X

Bristol_Jonesey

Jlien X

Bristol_Jonesey
FWIW, I am managing to successfully open up older projects in X3 and continuing to develop them, so this is not a common issue.  

Do you use track folders and are their sizes (heights) minimized and saved with a screenset? What happens when you open the project or switch screensets? Do you still see the folder size minimized? My projects created in X2a (with a project template in X2a) show folders in double-row height, while it doesn't happen in a project created in X3.

Yes, I use minimized Track folders and always in a saved/locked screenset and they open as they should do.

 
Ah, I've just discovered that this happens to all projects in X3 (maybe also in X2?). But to make it happen, you need to enable Auto Track Zoom and make the non-current tracks unminimized. When you switch back from another screenset, the folder tracks are unminimized as well, to match the size of the non-current tracks. Will submit a bug report.
 
(edit: btw, this has nothing to do with crashing Sonar)
 

Interesting.
 
I'll try and replicate this tonight when I get home

"All that said, I think Sonar is a great product and incredible value for its price. I honestly believe - and I know I'll be hit for that now - it's sold way too cheap."
 
Definitely send in a feature request for this, we'll see what we can do :)
 
In all seriousness, I appreciate your feedback and understand. The title was just a little jarring.

Well I hope you get it together Steven with Cake nowdays 'cos all of us want to see some conclusion to your efforts, what you are doing sounds important to me. I hope you are going to help each other out in the spirit of cooperation and friendliness and forget the past.
 
And BTW you aren't the first person peeved about not getting issues reopened. I worked in a QA dept for a software company myself and I tried to get issues reopened on a daily basis because developers would reject them. Once they were closed they were closed.... It was easier to fly to the moon to reopen them (too many existing stakeholders). So when I was sure the developers (etc) were wrong I merely created a new issue until they were forced to deal with it. Now Cake are listening I hope you are doing the same (believe me it would help them to start new issue and start again from scratch completely)...
 
I shall continue to encourage you :)
 
Cheers...