Forum General

Locating Exception from Release Stack Trace

JohnKablanJohnKablan USMember

I have a Xamarin Android application that is deployed to testers which is crashing intermittently. I log the stack trace when the application has an unhandled exception however I'm having difficulty locating the source of the crash from the trace. I found a note in the Xamarin 6.1 release notes about getting file names / line number in release build stack traces and implemented the changes in my project. Note I did have to change debugging information option to "Full" rather than "PDB Only" to get the build process to generate the msym directory.

I tested the functionality by adding a button to my app that raises an unhandled exception. As expected I was able to use the mono-symbolicate utility to determine the origin of the exception from the reported stack trace.

I noticed that the contents of the msym folder is named randomly so after rebuilding the app I deployed the new build and saved off the msym directory. The following is a stack trace I received from a crash report.

Object reference not set to an instance of an object

at MyApp.Droid.Dashboard.DashboardActivity+<OnResume>d__18.MoveNext () [0x0003b] in <e3858b3570dd4244985ab7c8da45615a>:0 \n--- End of stack trace from previous location where exception was thrown ---\n 
 at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <151302d8db184dfd9dfbf4e0ac550df9>:0 \n 
 at System.Runtime.CompilerServices.AsyncMethodBuilderCore+<>c.<ThrowAsync>b__6_0 (System.Object state) [0x00000] in <151302d8db184dfd9dfbf4e0ac550df9>:0 \n 
 at Android.App.SyncContext+<>c__DisplayClass2_0.<Post>b__0 () [0x00000] in <c8c020c6a36f47959fcbe54313f43792>:0 \n 
 at Java.Lang.Thread+RunnableImplementor.Run () [0x00008] in <c8c020c6a36f47959fcbe54313f43792>:0 \n 
 at Java.Lang.IRunnableInvoker.n_Run (System.IntPtr jnienv, System.IntPtr native__this) [0x00008] in <c8c020c6a36f47959fcbe54313f43792>:0 \n 
 at (wrapper dynamic-method) System.Object.452a73e4-d2f9-4ade-a6c1-b8346138dd0d(intptr,intptr)","reportType":"UHELogEntry","timestamp_ticks":636894071182040326}

However when I run the mono-symbolicate utility on the above trace the utility complains with the following warning.

Warning: MVID directory does not exist: .\e3858b3570dd4244985ab7c8da45615a

Its easy to see that the exception is coming from the OnResume method of the DashboardActivity (see below). But there are several possible sources of the exception but none of them seem probable so I'd like to have a better idea of where the exception is coming from before I go on several wild goose chases.

protected override async void OnResume()
    var provider = KernelBuilder.KERNEL.Get<ServiceProvider>();
    await provider.initializationTask;

    _service = provider.getService();
    Log.Debug(TAG, string.Format("OnResume, post service assignment", "Service: " + (_service?.ToString() ?? "null")));

    var wrapper = new ExerciseServiceWrapper(_service, null);
    _connectionView.Setup(wrapper, _service.userSetupHardware);


My questions are the following:

  1. Why is the mono-symbolicate tool not able to translate the stack traces to a file / line number?
  2. Is it possible to use the information encoded in the method name at the top of the stack trace (MyApp.Droid.Dashboard.DashboardActivity+d__18.MoveNext) to narrow down where the exception is coming from? It seems like the d__18 suffix may indicate if the exception happened before or after the call to await provider.initializationTask but I haven't found anything to help me understand this suffix.

An Additional Observation:

I noticed that if I set debugging information to "Full" and disable "Optimize Code" I get a file path / line numbers reported in the stack trace of my testing exceptions but not of the exception occurring in the OnResume function. This makes me think this is happening somewhere "special" maybe provider.initializationTask is null?




  • igorkr_10igorkr_10 Member ✭✭✭✭
    Have this issue too.
    All exceptions are without line numbers:

    TcuClientStandard.BaseViewModel.OnPropertyChanged (System.String propertyName) [0x00013] in <3ccd5325a17b45cb8ae260b30f1d7b20>:0
    at TcuClientStandard.ViewModels.EditorViewModel.OnDataLoading () [0x00095] in <3ccd5325a17b45cb8ae260b30f1d7b20>:0
    at TcuClientStandard.ViewModels.Editors.Documents.DocumentEditorViewModel.OnDataLoading () [0x00074] in <3ccd5325a17b45cb8ae260b30f1d7b20>:0
    at TcuClientStandard.ViewModels.Editors.Documents.GoodsDocuments.GoodsDocumentEditorViewModel.OnDataLoading () [0x00062] in <3ccd5325a17b45cb8ae260b30f1d7b20>:0
    at TcuClientStandard.ViewModels.EditorViewModel.LoadDataAsync (System.Boolean forceLoad) [0x000af] in <3ccd5325a17b45cb8ae260b30f1d7b20>:0
  • JohnHardmanJohnHardman GBUniversity admin


    If you want help identifying the cause of your exception, I suggest starting a new forum thread, posting your TcuClientStandard.BaseViewModel code, and specifying the type of exception (I'm assuming NullReferenceException).

  • JohnKablanJohnKablan USMember
    edited July 2020



    I haven't done any Xamarin development in the past year, but I did write myself a note regarding this issue. Here it is verbatim.

    To get line numbers in release builds do the following

    • Needed to change
      § 1) Proj Props -> Build -> Optimize Code : off
      § 2) Proj Props -> Build -> Advanced -> Debugging Information : full. Then we got line numbers but seems like we also lost part of the stack trace but probably not a part we really care about.

    -Can also do this, but you need to save off the mSym directory before rebuilding or you'll never figure the stack trace out

    [github (-dot-) com/xamarin/release-notes-archive/blob/master/release-notes/android/xamarin.android_6/xamarin.android_6.1/]

    The system might strip the url that is below the second point in that case. Go to the Xamarin github repo. Navigate to release-notes-archive/release-notes/android/xamarin.android_6/xamarin.android_6.1/ and read the section discussing generating .msym files and mono-symbolicate.

    Good luck.

  • Thanks John. I didn't have an error even slightly similar but, Debug Full solved me an entire morning worth of headache for something unrelated!

Sign In or Register to comment.