From 1455972afdfa070197547e7a7804b2f53fa78cf9 Mon Sep 17 00:00:00 2001 From: James Crosswell Date: Thu, 2 Jul 2026 12:31:53 +1200 Subject: [PATCH 1/3] Add "Duplicate events from native crashes" troubleshooting section Documents how to resolve duplicate managed + native crash events on Android and iOS. Covers the preferred (experimental) SignalHandlerStrategy approach and the SuppressSegfaults fallback on Android, and notes the automatic iOS handling as of 6.4.0. Closes #3943 (getsentry/sentry-dotnet). Co-Authored-By: Claude Opus 4.8 --- .../dotnet/common/troubleshooting.mdx | 30 +++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/docs/platforms/dotnet/common/troubleshooting.mdx b/docs/platforms/dotnet/common/troubleshooting.mdx index 8e758e4e77f95a..920c2f6a5f2eaf 100644 --- a/docs/platforms/dotnet/common/troubleshooting.mdx +++ b/docs/platforms/dotnet/common/troubleshooting.mdx @@ -39,6 +39,36 @@ This issue affects: - Applications built in release mode with trimming enabled - Specifically impacts the `net9.0-ios*` target frameworks +## Duplicate events from native crashes + +On Android and iOS, a single managed exception that surfaces as a native signal — for example a `NullReferenceException` that the runtime raises as a `SIGSEGV` — can be reported to Sentry **twice**: once as the managed .NET exception, and once as a native crash. This happens because both the .NET runtime and Sentry's native layer handle the same fault. + +### iOS + +This is handled automatically as of **version 6.4.0** — no configuration is required. The SDK intercepts the managed exception first and tells the native layer to ignore the resulting signal, so you get a single event. If you're seeing duplicates on iOS, upgrade to 6.4.0 or later. + +### Android + +The preferred fix is to change the order in which the native and managed signal handlers run, so the .NET runtime handles the managed exception first. This is currently **experimental** and opt-in: + +```csharp +options.Native.ExperimentalOptions.SignalHandlerStrategy = + Sentry.Android.SignalHandlerStrategy.ChainAtStart; +``` + +**Important Note:** +- Requires Android 8.0 (API level 26) or later. On older versions, the SDK falls back to the default strategy automatically. +- Only needed on the **Mono** runtime. On CoreCLR, the SDK already avoids the duplicate and keeps the default strategy. +- Not compatible with .NET runtimes 10.0.0–10.0.3 (.NET SDKs 10.0.100–10.0.103). On those versions, the SDK falls back to the default strategy automatically. This was fixed in .NET runtime 10.0.4 (.NET SDK 10.0.200). + +As an alternative — or if you can't opt into the experimental strategy — you can suppress native segfault capture entirely: + +```csharp +options.Android.SuppressSegfaults = true; +``` + +**Important Note**: This stops the native SDK from capturing `SIGSEGV` errors altogether, so it can also hide *genuine* native segfaults originating in native (non-managed) code. Prefer `SignalHandlerStrategy.ChainAtStart` where possible. + ## Sentry CLI not configured From fe9656eb7cc39f527dd59393cc660e1c8f9d2cd0 Mon Sep 17 00:00:00 2001 From: James Crosswell Date: Thu, 2 Jul 2026 12:45:04 +1200 Subject: [PATCH 2/3] Guard duplicate-crash section for dotnet.android too The new section was nested inside the existing PlatformSection scoped to dotnet.maui/dotnet.apple only, so readers on the plain ".NET for Android" guide (not MAUI) wouldn't see the Android-specific fix. Give it its own PlatformSection that also includes dotnet.android. Co-Authored-By: Claude Opus 4.8 --- docs/platforms/dotnet/common/troubleshooting.mdx | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/platforms/dotnet/common/troubleshooting.mdx b/docs/platforms/dotnet/common/troubleshooting.mdx index 920c2f6a5f2eaf..92b7ea019c0f6b 100644 --- a/docs/platforms/dotnet/common/troubleshooting.mdx +++ b/docs/platforms/dotnet/common/troubleshooting.mdx @@ -39,6 +39,10 @@ This issue affects: - Applications built in release mode with trimming enabled - Specifically impacts the `net9.0-ios*` target frameworks + + + + ## Duplicate events from native crashes On Android and iOS, a single managed exception that surfaces as a native signal — for example a `NullReferenceException` that the runtime raises as a `SIGSEGV` — can be reported to Sentry **twice**: once as the managed .NET exception, and once as a native crash. This happens because both the .NET runtime and Sentry's native layer handle the same fault. From 6006fbf06db02be72fbb967debd7eabeec5d9713 Mon Sep 17 00:00:00 2001 From: James Crosswell Date: Fri, 3 Jul 2026 11:27:28 +1200 Subject: [PATCH 3/3] Split content into iOS and Android specific sections Resolves https://github.com/getsentry/sentry-docs/pull/18623/changes#r3510081163 Co-authored-by: James Crosswell --- docs/platforms/dotnet/common/troubleshooting.mdx | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/platforms/dotnet/common/troubleshooting.mdx b/docs/platforms/dotnet/common/troubleshooting.mdx index 92b7ea019c0f6b..070967657c25f6 100644 --- a/docs/platforms/dotnet/common/troubleshooting.mdx +++ b/docs/platforms/dotnet/common/troubleshooting.mdx @@ -47,10 +47,14 @@ This issue affects: On Android and iOS, a single managed exception that surfaces as a native signal — for example a `NullReferenceException` that the runtime raises as a `SIGSEGV` — can be reported to Sentry **twice**: once as the managed .NET exception, and once as a native crash. This happens because both the .NET runtime and Sentry's native layer handle the same fault. + + ### iOS This is handled automatically as of **version 6.4.0** — no configuration is required. The SDK intercepts the managed exception first and tells the native layer to ignore the resulting signal, so you get a single event. If you're seeing duplicates on iOS, upgrade to 6.4.0 or later. + + ### Android The preferred fix is to change the order in which the native and managed signal handlers run, so the .NET runtime handles the managed exception first. This is currently **experimental** and opt-in: