Crash Stacks / Line Numbers for Xamarin Apps

[kensykora]

Crashes and errors that are collected today are really nice, but they aren't including line numbers. So when I see a crash with a stacktrace like this, it's really difficult to pinpoint exactly where the exception occurred. At best I can make an educated guess. Especially tricky when it's a very low frequency crash that we haven't been able to reproduce yet

System.NullReferenceException: Object reference not set to an instance of an object

App.MyApp.Services.BluetoothService+<>c.<ReadInitializationData>b__48_0 (App.MyApp.Member.JournalEntryModel x)
System.Linq.Enumerable.Max[TSource,TResult] (System.Collections.Generic.IEnumerable`1[T] source, System.Func`2[T,TResult] selector)
App.MyApp.Services.BluetoothService+<ReadInitializationData>d__48.MoveNext ()
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task)
System.Runtime.CompilerServices.TaskAwaiter`1[TResult].GetResult ()
App.MyApp.Services.BluetoothService+<>c__DisplayClass34_0+<<InitializePuck>b__0>d.MoveNext ()

I can't think of any alternative way to achieve this behavior. We have considered shipping log data with the crashes to supplement but that only goes so far.

[winnie]

Hi @kensykora - thanks for the feedback. We are unable to display Xamarin line numbers at the moment since we don’t actually process any Xamarin logs and we think this might be a limitation on the Xamarin side. We're currently looking into solutions and I'll keep this thread updated when I have more information. Thanks!

[ajhuntsman]

Can someone from Microsoft please explain how we're supposed to ship production Xamarin apps, when it's impossible to obtain useful crash reports?

[lexboss777]

Any update on this?

[baskren]

What is the status of this?

[Inrego]

It's really a pain to fix crashes, when we don't have line numbers..

You even acknowledge that line numers are needed to read and understand crashes..: https://docs.microsoft.com/en-us/appcenter/diagnostics/ios-symbolication

The stack traces only contain memory addresses and don’t show class names, methods, file names, and line numbers that are needed to read and understand the crashes.

[justintoth]

Don't hold your breath, I've been waiting 5+ years to get line numbers in my production Xamarin apps logged to HockeyApp (mono-symbolicate never worked for me). Seeming that App Center is a downgrade from HockeyApp (inconsistent logging of handled vs. unhandled exceptions, stack traces showing way less than they used to in HockeyApp, buggy dashboard, etc...) there is absolutely 0% chance of them ever getting this working.

[AhmedAdelAlDesouqy]

Any update about this issue? I'm using App Center with Xamarin.Android and there are still no line numbers in the crash reports :(

[catlan]

References: https://xamarin.github.io/bugzilla-archives/33/33806/bug.html https://github.com/xamarin/xamarin-android/issues/3657

[catlan]

What is underlying issue here? Is it just that mono-symbolicate is not used by appcenter? Or is there a problem with mono-symbolicate as well?

[Mikilll94]

Any update on this?

[Edgaras91]

News? Plans? Is there a way to achieve this with debug build?

[Mikilll94]

@Edgaras91 For debug build, line numbers are shown. For production builds they are not.

[Edgaras91]

@Edgaras91 For debug build, line numbers are shown. For production builds they are not.

What settings in android options are required to make a build a "debug" build to show the line numbers?

For example, Release Build, what do I need to do to make it build a debug version?

[Mikilll94]

@Edgaras91 If you compile your app in "Debug" configuration, then line numbers will be shown in stacktraces.

However, if you compile your app in "Release" configuration, line numbers WILL NOT be shown. That's why this issue is still open.

[Edgaras91]

@Edgaras91 If you compile the app in "Debug" configuration, then line numbers will be shown in stacktraces.

However, if you compile your app in "Release" configuration, then line numbers WILL NOT be shown. That's why this issue is still open.

I understand that. I want to convert my Release build, and stay on Release configuration, but I want to instruct the compiler to compile a debug version. There must be an android option to compile with debug information. Right?

[elielson-anjos]

any progress on this? No line numbers in app crash report renders it pretty much useless...

[baskren]

This issue has been resolved on the Xamarin.Android side for quite some time:

• April 18, 2019 Xamarin.Android 6 Release notes : File name and line number information in release builds
• May 12, 2020 No line numbers in Xamarin Android release build crashes after 5+ years

So, the ball should be in the AppCenter team's court. @winnie, with this information, should there be an update in status from your March 13, 2019 comment? Any insights would be appreciated.

[ghost]

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment.

[ryanholden8]

Hey @winnie, with the above information, could we get a roadmap indication for this feature? Even if it’s that there is no plans for this feature.

We have production apps that that are still experiencing crashes that we cannot debug because the lack of line numbers make the exact execution path obscure. Knowing if Xamarin will support this in the near future or not will help us with an approach. We are hoping Xamarin gets support but we’ve been hoping at the expense of unfixed crashes.

[baskren]

@winnie - I want to second @ryanholden8. This is a VERY MUCH NEEDED FEATURE and has been missing much, much too long. Until this is fixed, I cannot recommend AppCenter / Xamarin for Enterprise applications.

[SvenCarstensen]

Any update about this issue?

[carmanj]

@winnie, @ela-malani, @DmitriyKirakosyan - I'd love to hear some progress about this as well. There are multiple reported issues here that have been open for 2.5 years. I'm not entirely sure who the current PMs are for AppCenter, I gather Winnie left a while back. Any information on who the tag would be helpful as well.

At least for us, the funny thing is that AppCenter actually does display line numbers for either the iOS simulator or iOS devices that were being debugged directly via VS2019. These are also listed as unsymbolized crashes in AppCenter, despite appearing as symbolized. Any installs that are built and distributed by AppCenter to our QA members or clients do not include the line information that would be greatly helpful in having to pin down issues.

If we could get a copy of the heap that we could download and open up against VS (similar to what is possible with Azure), that would be even better, but I can at least understand why that might not be possible.

Thanks! -JC

[amirvenus]

Frankly, it's very hard to trace what went wrong within the app (if at all possible) without the line numbers.

[ghost]

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment.

[baskren]

Is this ever going to happen?

[bruno-garcia]

See blog post: https://devblogs.microsoft.com/appcenter/announcing-apache-cordova-retirement/ ? Won't take long for one of these to come out about Xamarin

[AlphaNERD-]

Hello Microsoft Team,

do we have some news on this issue? Because it is quite annoying. When i build the app in debug mode, i get all the line numbers without so much as a issue. I even get the paths to my source files located on my Mac. But for release builds i have to use the symbolicatecrash tool from Xcode. This is not very handy and it doesn't seem to get line numbers for every line reliably.

If you can't fix this issue on your end, can you suggest a way to build the app in such a way that i get all the information i can get in debug but without having to build the app in debug? Everything seems to work when i build my app in debug.

[davidbuckleyni]

This issue has been resolved on the Xamarin.Android side for quite some time:

• April 18, 2019 Xamarin.Android 6 Release notes : File name and line number information in release builds
• May 12, 2020 No line numbers in Xamarin Android release build crashes after 5+ years

So, the ball should be in the AppCenter team's court. @winnie, with this information, should there be an update in status from your March 13, 2019 comment? Any insights would be appreciated.

Nope it has not still an issue now

[ghost]

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment.

[amirvenus]

I would appreciate an update on this please

[baskren]

Is there any way this issue can get some love?

[AlphaNERD-]

Or maybe, just maybe, expand the REST API to allow us to modify stack traces so at least we can hack together a solution ourselves after years of you blatantly ignoring this very annoying issue.

By the way, there is another issue with the same feature request/complaint!

https://github.com/microsoft/appcenter/issues/324

How can it be that you own both App Center and Xamarin, yet you cannot integrate both of them together properly? Why is Xamarin being treated like a second-class citizen in your own damn products? What next, are you not allowing me to send Mono symbols from Xamarin.Android to the App Center, maybe even through DevOps CI?

Oh wait a minute! That is also an issue! By golly, you really couldn't be bothered to properly support Xamarin, could you?

https://github.com/microsoft/appcenter/issues/2370

EDIT: Just found out that you give people trying to work with .NET 6 the same silent treatment: https://github.com/microsoft/appcenter/issues/86

[davidbuckleyni]

Or maybe, just maybe, expand the REST API to allow us to modify stack traces so at least we can hack together a solution ourselves after years of you blatantly ignoring this very annoying issue.

By the way, there is another issue with the same feature request/complaint!

324

How can it be that you own both App Center and Xamarin, yet you cannot integrate both of them together properly? Why is Xamarin being treated like a second-class citizen in your own damn products? What next, are you not allowing me to send Mono symbols from Xamarin.Android to the App Center, maybe even through DevOps CI?

Oh wait a minute! That is also an issue! By golly, you really couldn't be bothered to properly support Xamarin, could you?

2370

EDIT: Just found out that you give people trying to work with .NET 6 the same silent treatment: #86

It seems Appcentre seems to being retired I have had no communication from them in realtion to whats hapening when maui comes out.

Might I suggest raygun it gives you line numbers and have of late changed their pricing model.

[baskren]

@davidbuckleyni : Thanks for mentioning RayGun. I hadn't heard of it. The price seems quite reasonable. I would be very happy to pay these kind of prices to get line numbers.

[davidbuckleyni]

@baskren no worries and dont forget u can email urself logs as well.

[ghost]

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment.

[brminnick]

Please remove the stale label. This feature has not yet been implemented.

[ghost]

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment.

[MaximMikhisor]

This issue has been manually marked as not stale because it has had activity for 60 days. It will not be closed because further activity occured within 15 days of previous comment.

[baskren]

You know what would be great? It would be great if this issue could be given some attention OR a rational explanation could be given as to why this is not a priority.

[carmanj]

You know what would be great? It would be great if this issue could be given some attention OR a rational explanation could be given as to why this is not a priority.

Why would they give a rational explanation, when it's becoming ever more evident that Xamarin is dead to them. It's all about MAUI now.

[baskren]

I'd be happy if they'd fix this for MAUI too - because that would mean it would be fixed for .NET6-iOS, .NET6-Android. Heck, maybe even for .NET6-Windows!

[AlphaNERD-]

I wanted to say that the App Center is dying but if you don't use Microsoft's own technologies with the App Center, the devs are quick to respond! Hey devs, why is some whack-a-doodle React Native framework getting more attention than your own technologies? INCLUDING .NET 6 BTW.! It's new and feels already as deprecated as Xamarin within the App Center!

You may say that none of these are deprecated except you don't and let the bot mark it as stale! If this continues, i'm gonna switch to Raygun!

[tdevere]

TL;DR - @amirvenus pointed out the flaw in my approach - here I was using a debug profile but when I switched to release, the problem resurfaced. I do apologize for the false alarm (@baskren)

Just came across this issue in another support channel. This may be something for consideration for those willing to accept the workaround. I have not isolated the source code which is responsible for creating the crash call stack. But I noticed that when using the Crash.TrackError method in our SDK, line numbers are retained. The workaround then, would be to hookup the AppDomain unhandled exception handler.

AppDomain.CurrentDomain.UnhandledException += CurrentDomain_UnhandledException;

Then, implement something like this:

    private void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
    {
        Exception ex = ((Exception)e.ExceptionObject);
        Crashes.TrackError(ex);
    }

The result? Surprisingly to me, both the crash which eventually is sent to App Center and the tracked crash, both now contain line numbers.

[amirvenus]

Just came across this issue in another support channel. This may be something for consideration for those willing to accept the workaround. I have not isolated the source code which is responsible for creating the crash call stack. But I noticed that when using the Crash.TrackError method in our SDK, line numbers are retained. The workaround then, would be to hookup the AppDomain unhandled exception handler.

AppDomain.CurrentDomain.UnhandledException += CurrentDomain_UnhandledException;

Then, implement something like this:

    private void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)

    {

        Exception ex = ((Exception)e.ExceptionObject);

        Crashes.TrackError(ex);

    }

The result? Surprisingly to me, both the crash which eventually is sent to App Center and the tracked crash, both now contain line numbers.

Have you tried with Release builds?

Thanks

[baskren]

Can't wait to try this

[davidbuckleyni]

TL;DR - @amirvenus pointed out the flaw in my approach - here I was using a debug profile but when I switched to release, the problem resurfaced. I do apologize for the false alarm (@baskren)

Just came across this issue in another support channel. This may be something for consideration for those willing to accept the workaround. I have not isolated the source code which is responsible for creating the crash call stack. But I noticed that when using the Crash.TrackError method in our SDK, line numbers are retained. The workaround then, would be to hookup the AppDomain unhandled exception handler.

AppDomain.CurrentDomain.UnhandledException += CurrentDomain_UnhandledException;

Then, implement something like this:

    private void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
    {
        Exception ex = ((Exception)e.ExceptionObject);
        Crashes.TrackError(ex);
    }

The result? Surprisingly to me, both the crash which eventually is sent to App Center and the tracked crash, both now contain line numbers.

What u describe has been around for years people reporting here would be aware of this

[Gekidoku]

TL;DR - @amirvenus pointed out the flaw in my approach - here I was using a debug profile but when I switched to release, the problem resurfaced. I do apologize for the false alarm (@baskren) Just came across this issue in another support channel. This may be something for consideration for those willing to accept the workaround. I have not isolated the source code which is responsible for creating the crash call stack. But I noticed that when using the Crash.TrackError method in our SDK, line numbers are retained. The workaround then, would be to hookup the AppDomain unhandled exception handler. AppDomain.CurrentDomain.UnhandledException += CurrentDomain_UnhandledException; Then, implement something like this:

    private void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
    {
        Exception ex = ((Exception)e.ExceptionObject);
        Crashes.TrackError(ex);
    }

The result? Surprisingly to me, both the crash which eventually is sent to App Center and the tracked crash, both now contain line numbers.

What u describe has been around for years people reporting here would be aware of this

This should be added to the documentation of crash handling of MAUI and Xamarin.

[rhult]

I got tired of waiting for this to never happen so I put together a small tool that helps somewhat. See the repo at https://github.com/rhult/crash-sharpener

It is not a full solution, but it does two things:

1. Add information to stack traces that can be uploaded as handled errors to App Center
2. A tool you can run locally to symbolicate those stack traces

You can use this to automate symbolicating by downloading the errors from App Center using its API, and then symbolicate them on your machine. I have tested it with iOS and Android on .net7 and it works well. I get line numbers from release builds this way.

[baskren]

Not all heros wear capes.