search

getsentry / sentry-dotnet

Sentry SDK for .NET
https://docs.sentry.io/platforms/dotnet
MIT License
578 stars 205 forks source link

Support for .NET minidumps on CoreCLR JIT #2076

Open bruno-garcia opened 1 year ago

bruno-garcia commented 1 year ago

Problem Statement

An experiment was made to use sentry-native and capture minidumps (through crashpad).

In the process we found out that the minidump created by crashed doesn't include information about the .NET runtime required on the backend to show things like managed heap, etc.

For that reason, the minidump support at this time is suboptimal, for example, not showing managed code lines in stack traces.

Tracking AOT support here: https://github.com/getsentry/sentry-dotnet/issues/2770

Solution Brainstorm

A discussion was opened on that repo with alternative methods to collect the minidumps, using .NET APIs or out of process collection.

In addition, Sentry (backend/frontend) would require changes to read on the new sections in the minidump and display them to the users. Similar to how other .NET debugging tools do.

vaind commented 9 months ago

Maybe it would be OK to limit this to NativeAOT published app crashes? There, we have native stacktraces for all the code and symbolication works fine, we just need to implement #2770

bruno-garcia commented 9 months ago

Agree, no plans to do this for JIT for now. Minidumps on AOT suffice

bruno-garcia commented 9 months ago

Reopening since this just came up again. We actually have a ticket open for WER that would depend on this (ingesting .NET minidumps):

wfjsw commented 9 months ago

To confirm that's CoreCLR you're looking for, right?

Yes.

Could you please write about your use case on that ticket instead?

There are 2 main use cases:

In both cases it would silently kill the app with no user-facing indications, let along displaying any crashlog for reporting purposes. As Sentry .NET is also on the managed side, it would not be able to report the incident.

For my cases I don't exactly care about the unification of the managed vs. unmanaged stack, but being able to report such incidents, and knowing which module causes it, is important. It's also a great plus if it would be possible to display a crash report window when such crash happens.

whiskhub commented 1 month ago

+1 for this feature request. Use case: WinUI apps that frequently call native code, or any Windows app that PInvokes native code (e.g. from a C++ dll).

IMO just letting people activate this feature using a flag during initialization or similar, without AOT requirement, would be sufficient for now.

support at this time is suboptimal, for example, not showing managed code lines in stack traces

It may not be perfect, but better than no information at all on Sentry. Usually it would be enough to just see which C++ function causes problems, without the entire callstack.

Especially now that you've deprecated https://github.com/getsentry/sentry-dotnet-minidump.