EXC_BAD_ACCESS reported by Sentry on .NET MAUI apps without actual app crashes (Silent Error)

[jvelandiadevinmotion]

Package

Sentry.Maui

.NET Flavor

.NET

.NET Version

9

OS

iOS

OS Version

26.2.1

Development Environment

Visual Studio v18.x

SDK Version

5.14.1

Self-Hosted Sentry Version

No response

Workload Versions

.

UseSentry or SentrySdk.Init call

Our Settings

"CrashSettings": {
"Android": {
"Dsn": "https://",
"Debug": false,
"TracesSampleRate": 0.1,
"AttachStacktrace": true,
"SendDefaultPii": true,
"CaptureFailedRequests": false,
"SampleRate": 1.0,
"MaxBreadcrumbs": 100,
"DisableUnhandledException": true,
"SupressNativeCrashes": true
},
"iOS": {
"Dsn": "https://",
"Debug": false,
"TracesSampleRate": 0.1,
"AttachStacktrace": true,
"SendDefaultPii": true,
"CaptureFailedRequests": false,
"SampleRate": 1.0,
"MaxBreadcrumbs": 100,
"DisableUnhandledException": true,
"SupressNativeCrashes": true
},

var crashOptions = PlatformExtensions.GetCrashSettings();

SentrySdk.Init(options =>
{
options.Dsn = crashOptions.Dsn;
options.Debug = crashOptions.Debug;
options.TracesSampleRate = crashOptions.TracesSampleRate;
options.AttachStacktrace = crashOptions.AttachStacktrace;
options.SendDefaultPii = crashOptions.SendDefaultPii;
options.CaptureFailedRequests = crashOptions.CaptureFailedRequests;
options.MaxBreadcrumbs = crashOptions.MaxBreadcrumbs;
options.SampleRate = crashOptions.SampleRate;
#if ANDROID
if (crashOptions.DisableUnhandledException)
{
options.DisableAppDomainUnhandledExceptionCapture();
}
if (crashOptions.SupressNativeCrashes)
{
options.Android.SuppressSegfaults = true;
options.Native.AnrEnabled = false;
}
#elif IOS
if (crashOptions.DisableUnhandledException)
{
options.DisableRuntimeMarshalManagedExceptionCapture();
}
if (crashOptions.SupressNativeCrashes)
{
options.Native.SuppressExcBadAccess = true;
options.Native.SuppressSignalAborts = true;
}
#endif
});

Steps to Reproduce

Hi Sentry team,

We are seeing a large number of EXC_BAD_ACCESS exceptions reported in the Sentry portal for our .NET MAUI application, but after extensive testing we have not been able to reproduce any real crashes or app terminations.

Details
Platform: .NET MAUI
Affected OS: iOS
Devices: Multiple devices and iOS versions
Time range: Last 30 days
Volume: ~16,000 events
Error type: EXC_BAD_ACCESS

Despite the high volume of events, the application:

• Does not crash
• Does not close

Continues running normally after the exception is reported

We performed multiple manual and automated tests across different devices and iOS versions, and we could not observe any real crash behavior that matches these reports.

Observations.

Based on our analysis, this seems to be:

An internal exception captured by the Sentry iOS SDK
Possibly a false positive or a low-level memory signal that does not lead to a real crash
Potentially related to how the SDK hooks or symbolicates EXC_BAD_ACCESS events in MAUI apps
This is generating a lot of noise in our crash reporting and makes it difficult to identify real, actionable crashes.

Questions

• Is this a known issue when using Sentry with .NET MAUI on iOS?
• Are there recommended settings to filter or suppress these non-fatal EXC_BAD_ACCESS events?
• Is there any guidance on how to distinguish real crashes from internal SDK signals in this scenario?
• We would really appreciate any insights or recommendations, as this is significantly impacting the reliability of our crash metrics.

Thanks in advance for your help!

Expected Result

EXC_BAD_ACCESS should only be reported when the application actually crashes or terminates.
Non-fatal internal SDK signals should not be reported as crashes in Sentry.
Crash reports should accurately reflect real app crashes experienced by end users.

Actual Result

Sentry reports a high volume of EXC_BAD_ACCESS events (~16,000 in the last 30 days)
across multiple devices and iOS versions, even though the application does not
crash or terminate and continues running normally.

These events appear to be false positives or internal SDK exceptions, generating
significant noise in crash reporting and making it difficult to identify real crashes.

[linear]

NET-581

[jamescrosswell]

@jvelandiadevinmotion it might be that your app creates (and also catches/handles) .NET exceptions that wrap the native EXC_BAD_ACCESS ios exceptions.

It is possible to suppress these and in your case it sounds like it might be worth doing so (:

sentry-dotnet/src/Sentry/Platforms/Cocoa/SentryOptions.cs

Lines 216 to 230 in 6a67f5e

	/// <summary>
	/// <para>
	/// Whether to suppress capturing EXC_BAD_ACCESS errors in the Native SDK.
	/// </para>
	/// <para>
	/// When managed code results in a NullReferenceException, this also causes a EXC_BAD_ACCESS. Duplicate
	/// events (one managed and one native) can be prevented by suppressing native EXC_BAD_ACCESS, which may be
	/// convenient.
	/// </para>
	/// <para>
	/// Enabling this may prevent the capture of EXC_BAD_ACCESS originating from native (not managed) code... so it may
	/// prevent the capture of genuine native EXC_BAD_ACCESS errors.
	/// </para>
	/// </summary>
	public bool SuppressExcBadAccess { get; set; } = false;

So something like when configuring Sentry at startup:

#if __IOS__
                options.Native.SuppressExcBadAccess = true;
#endif

[jvelandiadevinmotion]

@jvelandiadevinmotion it might be that your app creates (and also catches/handles) .NET exceptions that wrap the native EXC_BAD_ACCESS ios exceptions.

It is possible to suppress these and in your case it sounds like it might be worth doing so (:

sentry-dotnet/src/Sentry/Platforms/Cocoa/SentryOptions.cs

Lines 216 to 230 in 6a67f5e

///

///
/// Whether to suppress capturing EXC_BAD_ACCESS errors in the Native SDK.
///
///
/// When managed code results in a NullReferenceException, this also causes a EXC_BAD_ACCESS. Duplicate
/// events (one managed and one native) can be prevented by suppressing native EXC_BAD_ACCESS, which may be
/// convenient.
///
///
/// Enabling this may prevent the capture of EXC_BAD_ACCESS originating from native (not managed) code... so it may
/// prevent the capture of genuine native EXC_BAD_ACCESS errors.
///
///

public bool SuppressExcBadAccess { get; set; } = false;
So something like when configuring Sentry at startup:

#if IOS
options.Native.SuppressExcBadAccess = true;
#endif

Thanks for your reply, @jamescrosswell.

We already have the configuration options.Native.SuppressExcBadAccess = true;

However, the EXC_BAD_ACCESS error is logged in the Sentry control panel frequently and randomly.

Our Settings

"CrashSettings": {
"Android": {
"Dsn": "https://",
"Debug": false,
"TracesSampleRate": 0.1,
"AttachStacktrace": true,
"SendDefaultPii": true,
"CaptureFailedRequests": false,
"SampleRate": 1.0,
"MaxBreadcrumbs": 100,
"DisableUnhandledException": true,
"SupressNativeCrashes": true
},
"iOS": {
"Dsn": "https://",
"Debug": false,
"TracesSampleRate": 0.1,
"AttachStacktrace": true,
"SendDefaultPii": true,
"CaptureFailedRequests": false,
"SampleRate": 1.0,
"MaxBreadcrumbs": 100,
"DisableUnhandledException": true,
"SupressNativeCrashes": true
},

var crashOptions = PlatformExtensions.GetCrashSettings();

SentrySdk.Init(options =>
{
options.Dsn = crashOptions.Dsn;
options.Debug = crashOptions.Debug;
options.TracesSampleRate = crashOptions.TracesSampleRate;
options.AttachStacktrace = crashOptions.AttachStacktrace;
options.SendDefaultPii = crashOptions.SendDefaultPii;
options.CaptureFailedRequests = crashOptions.CaptureFailedRequests;
options.MaxBreadcrumbs = crashOptions.MaxBreadcrumbs;
options.SampleRate = crashOptions.SampleRate;
#if ANDROID
if (crashOptions.DisableUnhandledException)
{
options.DisableAppDomainUnhandledExceptionCapture();
}
if (crashOptions.SupressNativeCrashes)
{
options.Android.SuppressSegfaults = true;
options.Native.AnrEnabled = false;
}
#elif IOS
if (crashOptions.DisableUnhandledException)
{
options.DisableRuntimeMarshalManagedExceptionCapture();
}
if (crashOptions.SupressNativeCrashes)
{
options.Native.SuppressExcBadAccess = true;
options.Native.SuppressSignalAborts = true;
}
#endif
});

[jamescrosswell]

@jvelandiadevinmotion what that option does under the hood is to wire up a before send hook on the native/cocoa SDK:

sentry-dotnet/src/Sentry/Platforms/Cocoa/SentrySdk.cs

Line 91 in 6a67f5e

nativeOptions.BeforeSend = evt => ProcessOnBeforeSend(options, evt)!;

So you could do something similar yourself to try to identify which exceptions are not being filtered by the logic we built to suppress EXC_BAD_ACCESS exceptions and work out why these aren't being caught by our code.

You could also suppress whichever native/cocoa exceptions you like with that method.