appcenter-sdk-dotnet Send Crashes at the time of Crash, not on restart?

I believe that you are copying Crash logging logic from Hockeyapp and I dont know who favors those delayed crash reports! In my opinion, It is super useless.. In my experience, If new user gets a crash on a new app, he will not open the app 2nd time and will just uninstall it and you will never know that his exception even exist. Why would you locally store it and send it later? You have already had better logic with Xamarin Insights way. I am getting crash instantly on Xamarin Insights, I dont need to restart the app. And this is the reason still today many of us stick with Xamarin Insights. Devs want to 2 things for crash reporting

Real time crashes, not delayed on next start of the app.
Handled exceptions (already other issue exist) These 2 are working perfectly on xamarin Insights. why cant we get it in mobile center?

Oct 08 '17 21:10 EmilAlipiev

@EmilAlipiev Thanks for sharing your feedback. I will answer your questions:

It is not safe to send crash log right after the crash occurred. The app might be in unstable state or corrupted and therefore, we are only storing the crash log at the time of crash and actually sending it after the app opens. We want to have consistent experience across native and cross platforms in Mobile Center, that's why the behavior is designed in this way. Our past experience with HockeyApp suggest that getting crash reports on the next app start should not be an issue.
We plan to support handled exceptions in Mobile Center. It's on our roadmap but there is no ETA yet.

Oct 09 '17 21:10 elamalani

hi, why and how was it working in xamarin insights? do you mean that xamarin insights report crashes on real time is wrong ?

Mar 11 '18 16:03 EmilAlipiev

Hi there,

Insights SDK used to send native crash data the next time the application started up. Handled exceptions however were sent at runtime. The very nature of a crash means the crash reporter service on the device collects the crash log as the stack collapses. Only when the app restarts does it have the ability to send the crash log to the backend confidently. Sometimes Insights would record both a handled exception and a native crash on the same error event. You may have witnessed this in the past.

Mar 12 '18 22:03 ronoc

(Handled errors are sent in real time in AppCenter for Xamarin).

Mar 12 '18 22:03 guperrot

Startup crashes are still a problem - if your app crashes at startup it will likely do so again the next time and these crash reports will never be sent because of it. With Insights, we solved this by synchronously force sending all crash reports at startup after a crash (before proceeding with any real app code that might have caused it). As far as I've been able to discern there is no such API in App Center, nor have I been able to find a workaround.

Apr 09 '18 12:04 ElteHupkes

Today we don't have a simple API to wait synchronously, I will forward this feedback to product team. However, we have callbacks for crash sending and checking if there was a crash before so it can be achieved with some semaphores, but it's not straightforward.

Apr 09 '18 18:04 guperrot

@guperrot If you could guide me towards a workaround solution (however hacky) that would be much appreciated - I've previously spent a full day on the matter without success. If I recall correctly the problem is that those crash sending callbacks occur on the UI thread, even if crash sending itself does not. App initialisation obviously also happens on the main thread. Blocking initialisation (and thus blocking the main thread) therefore results in deadlock. I even tried blocking on a Task.Delay() hoping the callbacks would just fire later, but again nothing happened until the main thread was released. I got lost reading the platform specific code a bit but it appears that sending the crash reports at least at some stage depends on the UI-thread being available, which is in contradiction to it having to wait for them to be sent. I concluded it was currently impossible, but I would like to be wrong.

Apr 10 '18 15:04 ElteHupkes

Hi @ElteHupkes,

you are right that this scenario is currently not possible as this requires changes to our underlying native SDKs. (I just talked to @guperrot who sits right next to me)

We're tracking this as a feature request. Unfortunately, we can't provide an ETA to you.

Apr 10 '18 18:04 ElektrojungeAtWork

@TroubleMakerBen How I hate being right some times ;). I understand, I'm sure you guys are very busy. What's the best way for me to stay up to date with this feature's progress?

Apr 11 '18 08:04 ElteHupkes

Thx for understanding!

There are several ways to stay up to date:

we typically close issues here in GH once we've shipped a feature
we have a blog that includes "ship list" posts, although they are not SDK specific
we also have a Twitter account where we announce new features.

Apr 11 '18 18:04 ElektrojungeAtWork

Is it possible to attach extra information to the crash report at the time of crash? I'm trying to debug a memory issue, and I want to report the memory usage along with the OOM exception. Currently, I can use GetErrorAttachments to attach text to the crash report, but not until the app is restarted, meaning I have to somehow store the memory usage in a log file until the crash report can be sent.

May 22 '18 11:05 troelsim

@troelsim we currently don't support this scenario and thus is a feature request. What you can do as a work around is using AppDomain.UnhandledException event to save the data to your own file then attach it after restart if the exception you get in the attachment callback matches the GetLastSessionCrashReportAsync one.

May 23 '18 19:05 guperrot

@guperrot thanks, I'll try that out!

May 23 '18 19:05 troelsim

This situation is still a real problem:

Startup crashes are still a problem - if your app crashes at startup it will likely do so again the next time and these crash reports will never be sent because of it.

Mar 05 '19 09:03 markuspalme

@markuspalme Yes, that is a possibility- the best thing to do for now is start the Crash service as early as possible.

Mar 05 '19 18:03 achocron

@achocron Thanks. In my scenario, I start the Crash service as soon as possible in the FinishedLaunching method (iOS) but the crash originating in my main view model on startup is not sent. This renders the crash reporting almost useless to me. I would really appreciate a (blocking) Flush method to force sending out the reports on startup.

Mar 05 '19 20:03 markuspalme

I'd also like to see the blocking flush method. I have startup crashes. I've hooked the sending and sent events in Xamarin so that I can delay exit in UIApplicationMain until the reports have been sent, however the events are never fired. Even if I delay exit.

At present, restructuring the application so none of the logic happens during DidFinishLoading is not possible so a way to force errors reports to be sent prior to the app terminating is essential.

May 23 '20 09:05 rjhind

appcenter-sdk-dotnet appcenter-sdk-dotnet copied to clipboard

Send Crashes at the time of Crash, not on restart?

appcenter-sdk-dotnet
appcenter-sdk-dotnet copied to clipboard