search

getsentry / sentry-dotnet

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

WinUI: Native (test) crashes aren't reported #3244

Open tipa opened 7 months ago

tipa commented 7 months ago

Package

Sentry

.NET Flavor

.NET

.NET Version

8.0.2

OS

Windows

SDK Version

4.2.1

Self-Hosted Sentry Version

No response

Steps to Reproduce

  1. Create WinUI3 / WinAppSDK app
  2. Sentry.SentrySdk.CauseCrash(Sentry.CrashType.Native)

Expected Result

Crash is being reported to sentry.io

Actual Result

No crash is being reported (but app crashes with System.AccessViolationException: 'Attempted to read or write protected memory. This is often an indication that other memory is corrupt). Happens both in debug as well as in Release mode

bitsandfoxes commented 7 months ago

Hey @tipa, thanks for raising this. Could you provide us with some debug logs from the SDK so we can see what's going on?

tipa commented 7 months ago

Sure, I see these logs before the crash, during initialization:

  Debug: Initializing Hub for Dsn: '...'.
  Debug: This looks like a standard JIT/AOT application build.
  Debug: Starting BackgroundWorker.
  Debug: Registering integration: 'AutoSessionTrackingIntegration'.
  Debug: BackgroundWorker Started.
  Debug: Registering integration: 'AppDomainUnhandledExceptionIntegration'.
  Debug: Registering integration: 'AppDomainProcessExitIntegration'.
  Debug: Registering integration: 'SentryDiagnosticListenerIntegration'.
   Info: DiagnosticSource Integration is disabled because tracing is disabled.
  Debug: Registering integration: 'SystemDiagnosticsMetricsIntegration'.
   Info: System.Diagnostics.Metrics Integration is disabled because no listeners are configured.

And then when I trigger the crash:

  Debug: Triggering a deliberate exception because SentrySdk.CauseCrash(CrashType.Native) was called
An unhandled exception of type 'System.AccessViolationException' occurred in Sentry.dll
Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

You can reproduce it easily using this example: TestException.zip

bitsandfoxes commented 7 months ago

Thanks for the repro and logs! Much appreciated!

jamescrosswell commented 7 months ago

I can definitely reproduce this... managed exceptions get caught by the global exception handler that Sentry wires up. This particularly native exception crashes the app, bypassing the global exception handler (and any other exception handling I try to setup).

I've tried surrounding the code in a simple try..catch, but the catch never executes. I've tried setting up a custom SynchronizationContext but the exception never gets posted. I'm not sure if it's possible to catch these kinds of exceptions in WinUI.

bitsandfoxes commented 7 months ago

Sorry for the delay and the misleading CauseCrash utils. Unfortunately, the SDK does not support native crashes outside of AOT. We're going to guard the "demo" by a check and log instead of doing nothing.

@bruno-garcia tried adding and providing native support for regular JIT compiled applications over here https://github.com/getsentry/sentry-dotnet-minidump/issues/1 but that ran into a whole lot of issues.

bruno-garcia commented 1 month ago

@bruno-garcia tried adding and providing native support for regular JIT compiled applications over here https://github.com/getsentry/sentry-dotnet-minidump/issues/1 but that ran into a whole lot of issues.

To be clear it worked, but not the way you'd take the most value out of it. For example, there was no C# function names. I only saw C++ code, seemed like JIT generated code and less user-written code and no C#->C stack traces. SO it would require more work to get good support

bruno-garcia commented 1 month ago

I'm reopening this because we need to support capturing crashes in any sort of app. So this is a valid feature request imo