How can we improve the Windows dev platform?

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

76 votes
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Alexey Perezhogin shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    working on it  ·  Windows dev platform team responded  · 

    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.

    13 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Tim commented  ·   ·  Flag as inappropriate

        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.

      • Dmitry commented  ·   ·  Flag as inappropriate

        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  ·   ·  Flag as inappropriate

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

      • Brandon commented  ·   ·  Flag as inappropriate

        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

      • MSiccDev commented  ·   ·  Flag as inappropriate

        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 UniShareUWP!<BaseAddress>+0x7ee830
        at UniShareUWP!<BaseAddress>+0xdcb62b
        at UniShareUWP!<BaseAddress>+0xd32d4e
        at GalaSoft.MvvmLight.Helpers.WeakAction.Execute()
        at GalaSoft.MvvmLight.Command.RelayCommand.Execute(Object parameter)
        at UniShareUWP!<BaseAddress>+0xc14c2c
        InnerException: System.NotImplementedException: test exception...

        at UniShareUWP.ViewModel.MainViewModel.<get_AboutCommand>b__211_0()

        at UniShareUWP!<BaseAddress>+0xbe50d2

        at UniShareUWP!<BaseAddress>+0x7ee6e0

        Please do fix that, Symbols are in the AppxPackages, and allow us to get the StackTrace again!

      • x0zerocool0x commented  ·   ·  Flag as inappropriate

        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.

      • x0zerocool0x commented  ·   ·  Flag as inappropriate

        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.

      Feedback and Knowledge Base