getsentry
Support for .NET minidumps on CoreCLR JIT
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
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.
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
Reopening since this just came up again. We actually have a ticket open for WER that would depend on this (ingesting .NET minidumps):
- https://github.com/getsentry/sentry-dotnet/issues/1148
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:
- Handling WPF crashes Recent Intel integrated graphics would cause all WPF applications to crash on unmanaged side upon launch, and I only find it out by luck and Intel employee. I don't think WPF will have any chance to go NativeAOT in the following years.
- Handling P/Invoke crashes On some installations, NVIDIA's CUDA driver would decide to crash when I call it.
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.
+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.
Use case: WinUI apps that frequently call native code, or any Windows app that PInvokes native code (e.g. from a C++ dll).
Aren't WinUI3 apps AOT compiled? This issue is looking at support for native crashes for JIT apps (.NET basically, without Native AOT)
We added support for Native AOT, so perhaps it's not too challenging to extend that to .NET Native (I assume that's still what its' called for WinUI3)
Especially now that you've deprecated https://github.com/getsentry/sentry-dotnet-minidump.
You can continue to use that. Did it work for you on UWP/WinUI3 apps? If so, that helps us see how we could give support. The biggest problem there was the lack of any JIT context. Stack traces didn't have any frame that was JIT compiled, just C++ stuff. It was discussed in the open issues there, including:
- https://github.com/getsentry/sentry-dotnet-minidump/issues/1
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.
If that's the case you can continue using https://github.com/getsentry/sentry-dotnet-minidump But agree it would be nice if things worked out of the box. As it does for .NET Native AOT
I did create a ticket about a "WinUI package":
- https://github.com/getsentry/sentry-dotnet/issues/3712
Please chime in if you have thoughts
@bruno-garcia There is a big distinction between WinUI 2 (UWP) and WinUI 3. You seem to refer to WinUI 2, which is indeed using .NET Native.
But WinUI 3 is a UI framework for regular Win32 apps, mostly used with .NET apps. By default, they are not NativeAOT. WinUI 3 is internally implemented using C++, so some (fatal) errors are not catchable within C#, for example fail fast exceptions.
But the main point for me is really if you are using some C++ library within your C# (WinUI 3 or any other) app using PInvoke. Optimally, you would be able to complement the .NET Sentry NuGet package for catching C# exceptions, with Sentry Native for catching C++ exceptions from the C++ library.
The "problem" with sentry-dotnet-minidump right now is that you can't combine it with the C# Sentry NuGet package, due to both packages having a sentry.dll.
Additionally, .NET seems to internally catch critical C++ exceptions (access violation, stack overflow) so these aren't even detected by crashpad_handler.exe. They can be catched with crashpad_wer.dll, but not with the default implementation that is hardcoded to only catch 2 error codes.
I hope this clears up my use case. Let me know if you have more questions!
PS: I would not recommend you to invest much time into WinUI 2 and .NET Native, as there will be soon .NET 9 support for UWP/WinUI2.
I hope this clears up my use case. Let me know if you have more questions!
That does help clarify things, thanks.
PS: I would not recommend you to invest much time into WinUI 2 and .NET Native, as there will be soon .NET 9 support for UWP/WinUI2.
That's great because we have Native AOT support and we continue to invest on it.
PS: I would not recommend you to invest much time into WinUI 2 and .NET Native, as there will be soon .NET 9 support for UWP/WinUI2.
That is good news! A lot of the work we did to add AOT support in the sentry-dotnet SDK relies on net8.0 or higher.
We are also interested in this feature (see https://github.com/getsentry/symbolicator/issues/1731).
