Crash diagnostics for CoreCLR on mobile

[vitek-karas]

In .NET 11 we're bringing CoreCLR to .NET mobile applications. Initial support is already available in Preview 3, it will expand in later previews, and the plan is for CoreCLR to become the default runtime.

One area that needs attention is crash diagnostics, especially on end-user devices.

Background

On mobile, OS-provided crash reports are limited because platform unwinders do not understand .NET managed frames. Mono had the same limitation in some cases, which can lead to shortened call stacks, poor symbolication, and less useful post-mortem information overall.

As we bring CoreCLR to mobile, we want to improve this experience there and make crash information more useful than what platform tooling can provide on its own.

Goal

We're in the process of adding runtime support that can capture useful crash diagnostics at the point of failure and write them onto the device before the application process is terminated.

The initial focus is crash reports and managed call stacks rather than dumps. We expect to write additional crash information into device logs, and likely also into a JSON crash report file using the same JSON format as existing crash report functionality enabled by DOTNET_EnableCrashReport.

Over time, we are also interested in whether dumps make sense for mobile scenarios, but that is a later step.

If you have feedback, ideas, or experience in this area, feel free to comment.

[jamescrosswell]

I think the order in which signal handlers fire is related to this. @jpnurmi opened this PR to try to fix duplicate exception issues we've been having on Mono:

• [mono] Restore signal handlers during crash chaining #125835

I assume similar choices exist re signal handling order when using the Core CLR rather than Mono as the runtime... so would be great to get that right from the start with Core CLR.

[rolfbjarne]

This might be a better solution than signal chaining: #101560

[jamescrosswell]

A readable/useful managed call stack is obviously the most useful bit of context.

In terms of the crash report, this is some typical meta data that we generally try to capture for all exceptions... particularly if the exception causes the process to terminate (and we might only be able to capture the details out of process or on the next process run), it would be good if these were included in some kind of crash report: