Need more info for stack trace
Now with Win10 Dashboard the stack trace only provide a snippet of the error which is included in the error lines. However with the new dashboard this is the only information that is provided on the dashboard. It's not enough for devs :(
Can you include in this user voice entry the specific details of what is missing? we are working on improving these reports, and the more specific information we have about issues the more we will be able to add.
The traces on errors for our app all appear to be snippets They don't lead back to our code. This is not helpful as we are unable to determine where in our app the error originated.
I made an application that symbolicates the stack traces in the Windows Dev Center:
@dmitry, hockeyapp is different than Dev Center reporting. Soon with Visual Studio Mobile Center, they'll have better crash reporting / analytics as well for UWP.
I am using UWP HockeyApp for crash reporting. Sometimes I get crash reports with non-existing offset information. I contacted HockeyApp and got response that it's how Native Windows Symbolicator deobfuscate those memory address and it can't be improved on their side.
Jeff Boulanger commented
I totally agree with this. We have a windows 8 application (we have yet to move to 10) on the store, and we get little to no information that is helpful in determining why a customer receives a hang or crashes. Literally 1 line in the stack track, no offset number, just HANG_QUIESCE, or a very large callstack with only windows stack trace information and nothing about our application. This is our number 1 error and we want to resolve it, but are unable to determine a course of action due to this limitted information. I've posted on the forums a couple times, no help. I've tried to open a support ticked on the dev center, again, no help (was redirected to the same forums I had posted in).
Yeah, bottom line is the .Net Native stuff results in exception traces that are 100% useless. I've reported this to the App Insights team (same problem in those "stack traces" as well) and have been told the HockeyApp folks are going to be working on unwinding the .Net Native call stacks. Not sure what this means for people wanting to use AI. Seems like we'll have to import & wire up two SDKs now to get everything we were previously getting with one. #notOptimal
The problem is pretty much summed up already, just wanted to give my 2cts.
When UWP apps are compiled native, we do never get any helpful StackTrace, be it in Dev Center or be it in the Application Insights portal on Azure. The StackTraces are mostly not available or just show the offset.
Even if we do handle the unhandled exceptions in app and ask users to send the reports, they are pretty much useless:
at GalaSoft.MvvmLight.Command.RelayCommand.Execute(Object parameter)
InnerException: System.NotImplementedException: test exception...
Please do fix that, Symbols are in the AppxPackages, and allow us to get the StackTrace again!
Stack traces does not contain symbol names from our libraries in the unified Dev Center even though PDB files are uploaded, only offsets are included. here I have posted the detailed problem in msdn forums:
Alex Mitchell-Robinson commented
Dump files at the very least.
Since the new dashboard, a lot of developers have crashes without stracktraces. And without stacktrace we can't understand and correct these issues...
I should clarify a little, in summary, I do my best to catch all my errors within the app, I have 0 crashes to date, I am currently having to rely on users sending me an error via email since the error is caught and the app doesnt crash. I think it would be benifical to the user and the developer. Developers would always get an accurate error list and users would not need to email the developer the error.
AppHub currently will show the Crash Count and Stack Traces for those crashes. Even though I do implement error handling within my app, when an exception is caught I am forced to have the user email me the error. Showing the stack trace to a user is not a good option but without the stack trace its much harder to find the root cause of the issue. If we could submit our errors to an API (the same one that the phone uses to report our crashes) then we could easily catch our errors, show the user a message but then not rely on the user emailing us about the error and not have to worry about showing users our stack traces or other important data that we need to find the error.