How to get Exception.StackTrace line numbers on Windows Phone


(update: I’ve written an updated blog post about this. Also I made it available on NuGet as package AsyncStackTraceEx. And published the source code under MIT license on Github.) 

Scenario: I’ve written my app and released it to users. Some of them have reported crashes but I don’t know where. So I released an update which captures unhandled exceptions and invites the users to email these to me, in the hope that I can figure out what’s wrong.

Problem: On Windows Phone it’s not possible to deploy the PDB alongside the EXE/DLL. Without it, Exception.StackTrace is unable to provide line-numbers, and so all my phone error-reports come back without line-numbers and I don’t know how to debug.

Solution: I’ll write a small helper which adds those line numbers to exception stack-traces, without needing PDBs.

 

How it works

Here’s a side-by-side comparison of the output.

PDB-based Exception.StackTrace
(the highlighted parts are absent on phone since they depend on PDBs)
Using my helper-library
(the highlighted parts are present even on phone)
   at VB$StateMachine_3_BarAsync.MoveNext() in Class1.vb:line 24
— End of stack trace from previous location where exception was thrown —
   at TaskAwaiter.ThrowForNonSuccess(Task task)
   at TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at TaskAwaiter.GetResult()
   at VB$StateMachine_2_FooAsync.MoveNext() in Class1.vb:line 19
— End of stack trace from previous location where exception was thrown —
   at TaskAwaiter.ThrowForNonSuccess(Task task)
   at TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at TaskAwaiter.GetResult()
   at VB$StateMachine_1_TestAsync.MoveNext() in Class1.vb:line 14
— End of stack trace from previous location where exception was thrown —
   at TaskAwaiter.ThrowForNonSuccess(Task task)
   at TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at TaskAwaiter`1.GetResult()
   at VB$StateMachine_0_Button1_Click.MoveNext() in Class1.vb:line 5
   at Test.BarAsync
   at Test.FooAsync()#BarAsync in Class1.vb:19
   at Test.TestAsync()#FooAsync(True) in Class1.vb:14
   at Test.Button1_Click() in Class1.vb:5

 

I noticed that all the exceptions I ever cared about either arose in async operations in the framework, or in my own async methods. That let me use a fluent syntax, like this: (I’ve given the examples in C#, to balance out the fact that implementation is in VB…)

private async void Button1_Click(object sender, RoutedEventArgs e)
{
    try
    {
        await TestAsync().Log();    // so exception’s stacktrace will show “Button1Click() in MainPage.xaml.cs:53
    }
    catch (Exception ex)
    {
        MessageBox.Show(ex.Log());  // this retrieves the version of the stacktrace that includes line numbers
    }
}

Whenever I await something, I stick on “.Log()” at the end. This ensures that line numbers are preserved for any exception that comes out of the awaited task. And rather than retrieving the Exception.StackTrace property, I retrieve the stack-trace through my Exception.Log() extension method. This cleans up the async callstack into something more readable, and inserts back all those line numbers. I also added two other optional overloads of await-point logging, to get richer information in the exception’s async callstack; I use that richer information to (optionally) indicate which API I’m calling, and what arguments I’m passing to it. After all, it’s often the arguments to a method that are crucial to understanding why it threw the exception.

await BarAsync(b).Log(“BarAsync”);           // so the exception stacktrace shows “…#BarAsync in MainPage.xaml.cs:61
await FooAsync(true).Log(“FooAsync”, true);  // so the exception stacktrace shows “…#FooAsync(true) in MainPage.xaml.cs:72

 

Comments (3)

  1. Thomas Levesque says:

    Nice trick! However it seems to me that the implementation is more complex than it should… Here's my attempt at making it simpler: gist.github.com/…/6250080

    (I also change the name of the method to AsyncTrace)

  2. ljw1004 says:

    That's nice. What you observed was that it's better to add into the Exception.Data dictionary, rather than mess around with weak reference list as I was using. I didn't know about Exception.Data 🙂 … You also decided not to bother correlating it with the actual exception stack trace, nor cleaning up the exception stack trace, nor providing extra data. Fair enough design decisions!

  3. hmadrigal says:

    Thanks Lucian and Thomas for sharing your ideas.

    The first time I saw something like this it was on "Tango Master"  (a windows phone app). The application crashed, and when I restarted it then app asked for sending a crash report. Once I saw it, I implemented my own approach for providing the same functionality, and now that I see your ideas I have some code changes that It will provide more info.

    Kind regards,

    Herber