Azure Application Insights Debugging using the Call Stack

5

I am trying to figure out a way to debug exceptions that I have received in Azure's Application insights. I am new to this type of debugging since I've only really dealt with bugs in Visual Studio, where an active debugger is running. However, with Application Insights, there are null reference exceptions which only provide a call stack, and no useful exception message.

Exception Message: Arg_NullReferenceException

Callstack:at SharedLibrary!<BaseAddress>+0x68d4c5 --- End of stack trace from previous location where exception was thrown --- at SharedLibrary!<BaseAddress>+0x329115 at SharedLibrary!<BaseAddress>+0x329207 at SharedLibrary!<BaseAddress>+0x34d603

Other Exceptions have messages such as Excep_FromHResult 0x800455A0, While others actually show the methods they trace back to.

Is there a way to find where these exceptions came from deciphering the callstack or Base Address or HResult?

This will be very useful in eliminating bugs in my app.

c#
azure
uwp
azure-application-insights
.net-native
asked on Stack Overflow Dec 11, 2015 by William Bradley • edited Dec 11, 2015 by MattWhilden

1 Answer

5

UPDATE: This is now supported by the HockeyApp telemetry stack. See: http://support.hockeyapp.net/kb/client-integration-windows-and-windows-phone/crash-reporting-for-uwp

When your application is compiled with .NET Native, the resulting binary doesn't contain all of the rich metadata that is normally available to .NET applications. (You get the same behavior if you call Environment.StackTrace when compiled with .NET Native.) We do write all of that data into the pdb file that is generated but it's not available at runtime.

The solution here is to post facto rebuild your stacks using the information from the pdb files. I know the AppInsights team had this on their backlog but it doesn't seem to have happened. We have some diagnostic tools that we're attempting to get published so you can do this re-combobulation yourself but there's a bit of a morass getting them published.

If you send a mail to dotnetnative@microsoft.com describing this issue it may help to grease some wheels.

answered on Stack Overflow Dec 11, 2015 by MattWhilden • edited Apr 14, 2016 by MattWhilden

User contributions licensed under CC BY-SA 3.0