Detecting crashes, user reports through email, a dialogue box on crash, and/or generating a text file

Basically, all I want is something for my game that reports crashes like the crash reporter that already exists for UnityEngine itself! Bringing up a dialogue box, then a nice little form for the user to email the crash report, and also generating a text file like UnityEngine does in that crashes folder. But, if no one knows how to do that, the next best thing is to ask questions about the smaller steps. So: Does anyone know how to make some code that can run when my Unity game crashes and run anyway? I can’t seem to find any information about this online and I’m looking to do any (or all) of these three things:

  • Have some code that can run when my game crashes that will generate a text file about the crash ***(I have found a way to partially do this, but I have some questions that reading documentation or googling have been unable to answer to really call this “finished”)
  • Emails this text to my email
  • A dialogue box that lets the player know about the crash and gives them the option to email it
    Help would be much appreciated because this is for a school competition!

***(CODE FOR EVERYTHING DESCRIBED FROM HERE ON OUT ATTATCHED BELOW): About the text file, using an event that subscribes to Application.logMessageRecieved (article on how to do that here: Unity - Scripting API: Application.logMessageReceived )
When I force a crash with a button that simply runs UnityEngine.Diagnostics.Utils.ForceCrash(UnityEngine.Diagnostics.ForcedCrashCategory.FatalError),
the logMessageRecieved event is called, and I can output the error information, which is in the “logString” in the Unity article linked to above, to a textfile. The next thing I noticed is that I can make it so that, at least for my project, which has a lot of Debug.Log’s and missingreferenceexceptions, it only ouputs a crash to this file if I use an if statement that checks that the LogType (again check the unity article above) is LogType.Error. So, then I realized: If all errors result in a crash, or if all crashes are sent in the log as errors, that means that my code will be able to detect any sort of crash with this if statement. However, again, this is only true IF AND ONLY IF all errors result in crashes. So, for the last question/request of this post: is that statement true? Is anything that is a LogType.Error result in a crash?

I’ve attatched the script of what was just described. The only other thing you’d have to do is set up a button that runs UnityEngine.Diagnostics.Utils.ForceCrash(UnityEngine.Diagnostics.ForcedCrashCategory.FatalError) on click to get a project identical to mine
CatchCrashScrript.cs (920 Bytes)

You are looking for Diagnostics. Or plenty of other similar services like Crashlytics (mobile only I think).

At most those services will send you a digest by email, ie daily (at most) or weekly/monthly reports. Because there could potentially be tens of thousands of such logs appearing at any given moment ie when there’s a new OS update rolling out that causes your highly popular app to crash. For this reason no diagnostics service will send you an email for each individual crash.

Instead their dashboards will try to categorize crashes together so that you’ll instantly see “Oh, we got half a million crashes of the same kind on the latest xOS 123 that rolled out this week”.

When an application truly crashes, only something outside the application can provide crash reports. This “outside” could be a very outer layer, basically an “executable runner” of sorts as many desktop apps have been using for decades. But on mobile specifically the OS gathers these reports and it becomes a matter of providing these reports to you via cloud services.

For analysis where you have direct access to the device you can always manually access the log files.

No.

Simple example: Debug.LogError("this is an error log, not a crash");

Also note that there is no commonly accepted definition of “crash”. From the user’s perspective this is often when the app is unresponsive or suddenly closes. From a technical perspective this could be caused by many many things.

Throwing an exception for instance can lead to a crash, but exceptions can also be caught and handled appropriately. For instance cloud services actually require you to implement exception handling so the app responds correctly to the device or service going offline.

An infinite loop is a kind of crash that has the application function correctly, as programmed, but it will not do anything else besides running a loop infinitely. Only the OS can catch those (“application not responding” in Task Manager), or defensive programming styles by adding a counter with an upper limit breaking out of any potentially infinite loop.

Then you have crashes that are segmentation faults (aka access violation aka null dereferencing) as well as applications that cause the OS layer to malfunction, ie an operation that leads the driver to fail due to a bug or incompatibility, ultimately showing the user a bluescreen of death (BSOD) but this often gets attributed to the application itself when it could even be the user’s hardware malfunctioning.

Then on mobile, running a task for an extended period of time or allocating too much memory may cause the OS to force shutdown the app.

So there’s not one way of a “crash” occuring and any attempts at making your own system is futile, or it will at most be wholly insufficient by being able to catch only one specific kind of “crash”.

Crashlytics reports the details of crashes (at latest) on the next successful app start.

You can configure notifications based on alert triggers and use these to trigger Firebase Cloud functions that can do numerous useful things such as send an email, message a slack or discord or other functionalities exposed as APIs.

I see what you’re saying. In order to fully get the points for this section of the project, I think I’d have to do what you said here, " When an application truly crashes, only something outside the application can provide crash reports. This “outside” could be a very outer layer, basically an “executable runner” of sorts as many desktop apps have been using for decades. ". Unfortunately crashlytics doesn’t work because I’m making a desktop application, and diagnostics will get my partial points but the specific words for these points to be counted toward my favor in the project are “Generation of crash reports (via text file or dialog box) on application failure (maximum 30 points) and Option to email crash report on application failure (maximum 20 points)”. Do you know how to make one of these "executable runner”s? Or some resources to get me started on that?

Thanks Joe, unfortunately, my app is a desktop app, so crashlytics doesn’t meet what I’m looking for.

No, and nobody wastes any time doing that because creating a custom crash reporter is just like writing a custom installer - we already have plenty of solutions available to us, both free and commercial, and both kinds are really involved projects of their own that you could easily spend months to develop just a minimal barebones solution.

Hello, have you found a solution? I had the same problem.