Sonar error reporting is awful

In my first real project using X3, it crashed. I was hoping this was a thing of the past since updating from 8.5, but no. Still, it generates a minidump and asks me to submit a bug report. Great! Except... it failed due to a "connection problem", and offered no attempt to retry. Not very professional. Instead it gives me a link to submit a report manually.
 
I go to do this, fill in all the tedious stuff like serial number and version (hint - if your program is going to give me a link to click, encode this information in the link), then try to upload the minidump.... but it's too big and I get a "404 - File or directory not found." error at the end when I submit the file. I click back... and it's put me back at the beginning again. I think the details might still be there, but it's an annoyance.
 
Come on guys, this needs to be a smooth process for what is likely to be an already-annoyed user whose project just crashed.

I used to get those connection problems with the problem reporter quite often but now they seem to upload without problems. I had thought that maybe they'd fixed something at their end. 

I cannot see signatures using mobile, is the OP on X3e? I have not seen issues like this for some time now.

In hindsight I was just really frustrated that when I get a crash in Sonar, it was then followed by other annoyances. I know ranting on here isn't all that productive. So I apologise to anyone who feels their time was wasted by reading this!
 
To answer points above:
 

A simple option to save the dump and prompt the next time Sonar starts to try to send again would be great.

 
Totally. The error reporter is a great idea - just make sure the stuff goes into a queue and can be sent later. (I'd also suggest that the minidumps get zipped before sending - they shrink to about 10% of the size.)
 

What was the nature of the crash, by the way?
 
Were you using any 3rd-party 32-bit plugins, by chance?

 
The nature of the crash was that I changed a value in a plugin (the Play engine for EWQL Symphonic Orchestra, 64bit) and then Sonar crashed. I know people are quick to blame the plugin in such cases but it is actually possible to catch most exceptions and - if nothing else - point out where in the code the crash actually happened.
 
I don't think I was using any 3rd party 32-bit plugins, but even if I was, that shouldn't make Sonar crash - they run in a separate process, right?
 

I cannot see signatures using mobile, is the OP on X3e?

 
I don't have my software details in my signature, but yeah, I'm on X3e, 64 bit.
 

Automatic failed because you can't reach cakewalk servers for some reason. That's likely because a) Their server is down b) Internet connectivity issue which could be at their end, your end, or somewhere in-between.

 
I can go weeks without encountering any sort of connectivity problem to any other site. If I can't connect to their error-handling server, I'm going to be willing to bet a lot of money the problem is on their side. Ideally they will just make their system more robust so that it can try the operation again.
 

Did you give them steps to reproduce your issue?

 
It's not a reproduceable issue. That's why sending the minidump is probably more useful. I did send it - after zipping it to make it small enough to go through their web interface.
 

Personally I think you are far better off troubleshooting on this thread and see if your problem can be resolved in these forums.

 
I appreciate people are trying to be helpful but I'm not trying to find ways to fix this crash. It shouldn't happen, but it did, and the chances of me finding the cause and being able to fix it without stopping using either (a) Sonar or (b) the VST in question approach zero. What I am interested in is making sure that when these things happen, I can report them to the developers without hassle, so that at least there's a good chance that it might get fixed in future.

Thanks for the reply.
 
32-bit plugins need to use 'bridging software' to be able to run in 64-bit Sonar.  Sonar comes with something called BitBridge, which attempts to allow 32-bit VST plugins to run in 64-bit Sonar.
 
It doesn't always work, and MANY problems have been reported with 32-bit plugins causing crashed and also really wacky behavior when used in 64-bit Sonar.  That was why I had asked.
 
Another similar piece of 3rd-party bridging software is available - called JBridge, and for some 32-bit plugins, it worked better than BitBridge, at allowing them to run in 64-bit Sonar, but here to, MANY problems were reported with both crashes and weird behavior.
 
Soooo, generally speaking, it is the general consensus that if running 64-bit Sonar, then trying to eliminate all possible 32-bit plugin use is best.  Many of the more supported plugin vendors have released free 64-bit versions of many 32-bit plugins, so you might wish to check that for any that you really want to try to hang on to.
 
With regard to your thought that Sonar should be able to intercept and report on plugin failures, this is not always possible, as control can get turned over to the plugin for processing, and then it is the responsibility of the plugin to handle any exceptions - including reporting on them.   (as far as I know).
 
If you call Cakewalk Technical Support, and provide them with the report number for what you sent them, they may be able to give you more information to go on - which may include either a workaround, or they may have been in contact with East West folks and could possibly pass on information as to what happened and when something might be available to stop it from happening in the future.
 
Best of luck with the situation - I HOPE to be able to pick up some East West strings version, and am looking forward to getting access to better sounding solo violin sounds.  :)
 
Bob Bone
 

Yeah, it's possible to know which DLL has raised the exception and include that in the error report. This is something that can be coded in - I've done it for other applications. The minidump Sonar produces probably contains this information, but unfortunately it's not shown to the user, so they can't adjust their usage patterns based on it unfortunately. With this information, avoiding and pin-pointing dodgy plugins would become a lot easier.
 
Regarding 32-bit/64-bit, I know about all that (though no doubt that information may help others). I've seen enough 'Teleport Server has stopped working' messages to last me a lifetime. Giving up all 32-bit plugins is not going to happen unfortunately but I'll be avoiding them where I can, and that included this session.
 
In fact, it would be great to have a 'Safe Mode' that treats VSTs a bit like browsers treat their plugins, ie. by running each of them in a separate process, which makes it even easier to catch when one of them crashes. This would be done by basically running something like Bitbridge for all plugins, not just for those compiled for a different architecture.
 
(Incidentally I had to try about 15 times to post this message... does anyone else ever get repeated 'unexpected error' messages after a 30 second time-out?)

.. And I would love to see in built diagnostics and performance stats in Sonar of some sort. Maybe even sandboxing. It would slow the DAW down of course so it would have to be an option in preferences. I'd be surprised if this isn't happening to some minor extent already so QA can test.. And then stripped for the final build.

I expect much of the sonar codebase is too old to enable the modern error handling we've become used to...
Greetings from rainy Wales x

Try catch can be expensive.

You also don't catch crashes with C++ try/catch blocks.