Initializing SentrySdk Crashes when running with AndroidEnableAssemblyCompression = false in Release mode #3920

Cheesebaron · 2025-01-27T16:40:52Z

Package

Sentry.Extensions.Logging

.NET Flavor

.NET

.NET Version

9.0.100

OS

Android

SDK Version

5.0.0 + 5.0.1

Self-Hosted Sentry Version

No response

Steps to Reproduce

We have an application which only exposes a Service. This is normally bound to by some of our other applications to exchange information.

We upgraded to .NET 9 and Sentry to 5.0.1 recently, and we see a weird crash when the Service starts, we initially thought it was some of our dependencies that were causing the issue, but seems like even when moving the initialization code to MainApplication it throws the following exception at startup:

FATAL EXCEPTION: main
Process: dk.trackman.range.kiosk.virtualgolfmediator, PID: 1976
android.runtime.JavaProxyThrowable: [System.Security.Cryptography.CryptographicException]: Cryptography_ConcurrentUseNotSupported
	at System.Security.Cryptography.ConcurrencyBlock.Enter + 0x1a(Unknown Source)
	at System.Security.Cryptography.HashProviderDispenser+EvpHashProvider.FinalizeHashAndReset + 0x0(Unknown Source)
	at System.Security.Cryptography.HashProvider.FinalizeHashAndReset + 0x13(Unknown Source)
	at System.Security.Cryptography.SHA1+Implementation.HashFinal + 0x0(Unknown Source)
	at System.Security.Cryptography.HashAlgorithm.CaptureHashCodeAndReinitialize + 0x0(Unknown Source)
	at System.Security.Cryptography.HashAlgorithm.ComputeHash + 0x22(Unknown Source)
	at Sentry.Internal.Extensions.HashExtensions.GetHashString + 0x12(Unknown Source)
	at Sentry.Internal.InstallationIdHelper.TryGetPersistentInstallationId + 0x46(Unknown Source)
	at Sentry.Internal.InstallationIdHelper.TryGetInstallationId + 0x3b(Unknown Source)
	at Sentry.SentryOptions.<.ctor>b__346_0 + 0x6(Unknown Source)
	at System.Lazy`1[[System.String, System.Private.CoreLib, Version=9.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].ViaFactory + 0x44(Unknown Source)
	at System.Lazy`1[[System.String, System.Private.CoreLib, Version=9.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].ExecutionAndPublication + 0x22(Unknown Source)
	at System.Lazy`1[[System.String, System.Private.CoreLib, Version=9.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].CreateValue + 0x74(Unknown Source)
	at System.Lazy`1[[System.String, System.Private.CoreLib, Version=9.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].get_Value + 0xa(Unknown Source)
	at Sentry.SentryOptions.get_InstallationId + 0x0(Unknown Source)
	at Sentry.GlobalSessionManager.StartSession + 0x3c(Unknown Source)
	at Sentry.Internal.Hub.StartSession + 0x3c(Unknown Source)
	at Sentry.Integrations.AutoSessionTrackingIntegration.Register + 0x8(Unknown Source)
	at Sentry.Internal.Hub..ctor + 0xf8(Unknown Source)
	at Sentry.SentrySdk.InitHub + 0x7d(Unknown Source)
	at Sentry.SentrySdk.Init + 0x0(Unknown Source)
	at TrackMan.VirtualGolfMediator.Droid.MainApplication.OnCreate + 0x23(Unknown Source)
	at Android.App.Application.n_OnCreate + 0x8(Unknown Source)
	at Android.Runtime.JNINativeWrapper.Wrap_JniMarshal_PP_V + 0x5(Unknown Source)
	at crc6449c06082aa7b0d2b.MainApplication.n_onCreate(Native Method)
	at crc6449c06082aa7b0d2b.MainApplication.onCreate(MainApplication.java:24)
	at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1192)
	at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6712)
	at android.app.ActivityThread.access$1300(ActivityThread.java:237)
	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1913)
	at android.os.Handler.dispatchMessage(Handler.java:106)
	at android.os.Looper.loop(Looper.java:223)
	at android.app.ActivityThread.main(ActivityThread.java:7656)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)

This is when we call the following code in MainApplication.OnCreate:

var options = new SentryLoggingOptions
{
    Dsn = "our-dsn-here",
    MinimumEventLevel = LogLevel.Critical
};
options.DisableUnobservedTaskExceptionCapture();
SentrySdk.Init(options);

Interestingly we had the IsGlobalModeEnabled = false set in options then it seemd to crash differently at startup with:

FATAL EXCEPTION: main
Process: dk.trackman.range.kiosk.virtualgolfmediator, PID: 2184
android.runtime.JavaProxyThrowable: [System.Threading.LockRecursionException]: LockRecursionException_RecursiveReadNotAllowed
	at System.Threading.ReaderWriterLockSlim.TryEnterReadLockCore + 0x56(Unknown Source)
	at System.Threading.ReaderWriterLockSlim.TryEnterReadLock + 0x0(Unknown Source)
	at System.Threading.ReaderWriterLockSlim.TryEnterReadLock + 0x7(Unknown Source)
	at System.Threading.ReaderWriterLockSlim.EnterReadLock + 0x0(Unknown Source)
	at Sentry.Scope.get_Transaction + 0x0(Unknown Source)
	at Sentry.Scope.set_TransactionName + 0x7(Unknown Source)
	at Sentry.Scope.Apply + 0x1a8(Unknown Source)
	at Sentry.Scope.Apply + 0x9(Unknown Source)
	at Sentry.Scope.Clone + 0x1e(Unknown Source)
	at Sentry.Internal.SentryScopeManager.PushScope + 0x76(Unknown Source)
	at Sentry.Internal.SentryScopeManager.PushScope + 0x0(Unknown Source)
	at Sentry.Internal.Hub.PushScope + 0x6(Unknown Source)
	at Sentry.Internal.Hub..ctor + 0xc6(Unknown Source)
	at Sentry.SentrySdk.InitHub + 0x7d(Unknown Source)
	at Sentry.SentrySdk.Init + 0x0(Unknown Source)
	at TrackMan.VirtualGolfMediator.Droid.MainApplication.OnCreate + 0x3c(Unknown Source)
	at Android.App.Application.n_OnCreate + 0x8(Unknown Source)
	at Android.Runtime.JNINativeWrapper.Wrap_JniMarshal_PP_V + 0x5(Unknown Source)
	at crc6449c06082aa7b0d2b.MainApplication.n_onCreate(Native Method)
	at crc6449c06082aa7b0d2b.MainApplication.onCreate(MainApplication.java:24)
	at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1192)
	at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6712)
	at android.app.ActivityThread.access$1300(ActivityThread.java:237)
	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1913)
	at android.os.Handler.dispatchMessage(Handler.java:106)
	at android.os.Looper.loop(Looper.java:223)
	at android.app.ActivityThread.main(ActivityThread.java:7656)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)

I've managed to narrow this down to the project property AndroidEnableAssemblyCompression which we had set to false. If I recall correctly, we set this to work around an issue in an earlier version of the .NET Android workloads that would crash the App at startup trying to unpack the assemblies.

My question is, why does this cause Sentry to crash at startup when this property is set to false. Seemingly it mainly happens in Sentry code, because when we remove SentrySdk.Init the rest of the App seems to work OK.

Here is a repo with the issue: https://github.com/Cheesebaron/SentryInitCrash build it in Release mode and deploy to an emulator/device and start the main activity. It will crash on startup with a similar error as above.

Expected Result

SentrySdk.Init should with with AndroidEnableAssemblyCompression = false?

Actual Result

See exceptions above.

The text was updated successfully, but these errors were encountered:

jamescrosswell · 2025-01-27T21:28:50Z

Hey @Cheesebaron,

Thanks for raising an issue. I'd avoid setting IsGlobalModeEnabled = false in UI applications. That would cause all kinds of issues (it causes scopes, transactions and breadcrumbs etc. to have an affinity for async contexts - that makes sense for HTTP requests in an ASP.NET apps but not for Android or MAUI apps).

The original problem you're seeing appears to be coming from here:

sentry-dotnet/src/Sentry/Internal/InstallationIdHelper.cs

Line 60 in 7da3cf3

    
           var directoryPath = Path.Combine(rootPath, "Sentry", options.Dsn!.GetHashString());

sentry-dotnet/src/Sentry/Internal/Extensions/HashExtensions.cs

Line 9 in e827b76

var hash = sha.ComputeHash(bytes);

Seemingly that ComputeHash method fails on your target platform. It's weird that it complains about concurrent use, since the whole thing is wrapped in a lock:

sentry-dotnet/src/Sentry/Internal/InstallationIdHelper.cs

Line 21 in 7da3cf3

lock (_installationIdLock)

The good news is that I can reproduce with the sample app you provided! And I've found a couple of clues on stack overflow so it should be possible to find a way to work around this.

Cheesebaron · 2025-01-27T22:06:46Z

I am not even sure why it is only an issue when AndroidEnableAssemblyCompression in csproj is to false. Almost inclined to say it is an issue in the .NET workload.

The Global Mode seems to be a misunderstanding from my colleague when setting up Sentry in that App, will let them know 🤔

jamescrosswell · 2025-01-28T00:54:01Z

Interestingly, I don't get the problem with the following changes:

- var options = new SentryLoggingOptions
+ var options = new SentryOptions
   {
-       Dsn = "https://[email protected]/5428537",
+       Dsn = "https://[email protected]/5428537"
-       MinimumEventLevel = LogLevel.Critical
   };
   SentrySdk.Init(options);

This is odd since the SentryLoggingOptions aren't used in any call to AddSentry to initialise the MEL integration in the minimal repro app... so I wouldn't expect this to have any impact on the SDK initialisation (the extra properties in SentryLoggingOptions should just be ignored when calling SentrySdk.Init).

@Cheesebaron is there a reason why you're using SentryLoggingOptions rather than SentryOptions in the call to Init?

Cheesebaron · 2025-01-28T07:03:59Z

@Cheesebaron is there a reason why you're using SentryLoggingOptions rather than SentryOptions in the call to Init?

Sure, in this sample it probably doesn't make sense. The code was extracted from an App where we also call AddSentry on a ServiceCollection to get logs as breadcrumbs, and my colleague who set it up was probably under the impression they needed to use SentryLoggingOptions, will go through how it is set up today to make sure we are doing the correct thing :)

pkubs-ui · 2025-01-28T08:23:04Z

This is odd since the SentryLoggingOptions aren't used in any call to AddSentry to initialise the MEL integration in the minimal repro app... so I wouldn't expect this to have any impact on the SDK initialisation (the extra properties in SentryLoggingOptions should just be ignored when calling SentrySdk.Init).

I have the same issue as Cheesebaron. Had originally SentrySdk.Init(o => { //... }); and have tried with passing SentryOptions to SentrySdk.Init. Is a not a MAUI project but a .net for Android project running net9 with Sentry sdk 5.0.1.

With AndroidEnableAssemblyCompression=True it works.

Options:

  Dsn = "<dns>",
  AutoSessionTracking = true,
  Environment = "<env>",
  SampleRate = 1.0f,
  CaptureFailedRequests = false,
  Release = "<buildNo>",
#if ANDROID
  Native.EnableNdk = true;
#endif

It's not the same Exception msg, similar though

[ERROR] FATAL UNHANDLED EXCEPTION: 
System.Security.Cryptography.CryptographicException: Concurrent operations from multiple threads on this type are not supported.
    at System.Security.Cryptography.ConcurrencyBlock.Enter(ConcurrencyBlock& block)
    at System.Security.Cryptography.HashProviderDispenser.EvpHashProvider.FinalizeHashAndReset(Span`1 destination)
    at System.Security.Cryptography.HashProvider.FinalizeHashAndReset()
    at System.Security.Cryptography.SHA1.Implementation.HashFinal()
    at System.Security.Cryptography.HashAlgorithm.CaptureHashCodeAndReinitialize()
    at System.Security.Cryptography.HashAlgorithm.ComputeHash(Byte[] buffer)
    at Sentry.Internal.Extensions.HashExtensions.GetHashString(String str, Boolean upperCase)
    at Sentry.Internal.InstallationIdHelper.TryGetPersistentInstallationId()
    at Sentry.Internal.InstallationIdHelper.TryGetInstallationId()
    at Sentry.SentryOptions.<.ctor>b__346_0()
    at System.Lazy`1[[System.String, System.Private.CoreLib, Version=9.0.0.0, Culture=neutral]].ViaFactory(LazyThreadSafetyMode mode)
    at System.Lazy`1[[System.String, System.Private.CoreLib, Version=9.0.0.0, Culture=neutral]].ExecutionAndPublication(LazyHelper executionAndPublication, Boolean useDefaultConstructor)
    at System.Lazy`1[[System.String, System.Private.CoreLib, Version=9.0.0.0, Culture=neutral]].CreateValue()
    at System.Lazy`1[[System.String, System.Private.CoreLib, Version=9.0.0.0, Culture=neutral]].get_Value()
    at Sentry.SentryOptions.get_InstallationId()
    at Sentry.GlobalSessionManager.StartSession()
    at Sentry.Internal.Hub.StartSession()
    at Sentry.Integrations.AutoSessionTrackingIntegration.Register(IHub hub, SentryOptions options)
    at Sentry.Internal.Hub..ctor(SentryOptions options, ISentryClient client, ISessionManager sessionManager, ISystemClock clock, IInternalScopeManager scopeManager, RandomValuesFactory randomValuesFactory)
    at Sentry.SentrySdk.InitHub(SentryOptions options)
    at Sentry.SentrySdk.Init(SentryOptions options)
    at Sentry.SentrySdk.Init(Action`1 configureOptions)
    ...

aritchie · 2025-02-04T20:26:31Z

This issue is very much in the dotnet internals. I've tried various workarounds without success so far. An issue has been filed with the dotnet android team here: dotnet/android#9752

bruno-garcia · 2025-03-12T19:26:22Z

I understand this is a .NET bug. But if someone adds our SDK and it crashes, it understandable they won't be happy with Sentry.

Looking at the stack trace:

Looks like it crashes when we try to start a session:

sentry-dotnet/src/Sentry/GlobalSessionManager.cs

Line 222 in f0a778b

var distinctId = _options.InstallationId;

We should capture this, log with diagnostic logger and carry on. The app wouldn't have session tracking with Sentry but we should at least capture crashes and more importantly. not crash the app.

In addition we might have to disable offline caching since we use that to build the path. Although on Android each app has its own folder so shouldn't really need installationId on the path there.
But that should be taken care of because we try/catch it here:

sentry-dotnet/src/Sentry/GlobalSessionManager.cs

Lines 60 to 95 in f0a778b

    
           try 
        
           { 
        
               _options.LogDebug("Creating persistence directory for session file at '{0}'.", _persistenceDirectoryPath); 
        
               if (!_options.FileSystem.CreateDirectory(_persistenceDirectoryPath)) 
        
               { 
        
                   _options.LogError("Failed to create persistent directory for session file."); 
        
                   return; 
        
               } 
        
               var filePath = Path.Combine(_persistenceDirectoryPath, PersistedSessionFileName); 
        
               var persistedSessionUpdate = new PersistedSessionUpdate(update, pauseTimestamp); 
        
               if (!_options.FileSystem.CreateFileForWriting(filePath, out var file)) 
        
               { 
        
                   _options.LogError("Failed to persist session file."); 
        
                   return; 
        
               } 
        
               try 
        
               { 
        
                   using var writer = new Utf8JsonWriter(file); 
        
                   persistedSessionUpdate.WriteTo(writer, _options.DiagnosticLogger); 
        
                   writer.Flush(); 
        
               } 
        
               finally 
        
               { 
        
                   file.Dispose(); 
        
               } 
        
               _options.LogDebug("Persisted session to a file '{0}'.", filePath); 
        
           } 
        
           catch (Exception ex) 
        
           { 
        
               _options.LogError(ex, "Failed to persist session on the file system."); 
        
           }

In short: we need to degrade the experience, even if we disable Sentry altogether. But we can't crash the app. Even if we silently disable Sentry that's better.

aritchie · 2025-03-13T14:07:31Z

@bruno-garcia We currently don't have a way of detecting that this issue is coming. We've discussed being able to source gen over some of the build contextual information such as this android flag. The issue is far deeper in decrypting the installationID. IF I try/catch the issue at the level it is at (or even up a couple of calls in the stack), the issue begins to balloon out from there. I tried to find a suitable workaround or notification without too much success. In terms of timeboxing a resolution to this issue, and instead of overcomplicating the Sentry SDK (and likely causing other downstream issues), we decided the best course of action was to document this for now. We haven't done the doc on it yet since we've been busy with other things. We can pin this issue in the meantime?

jamescrosswell · 2025-03-16T20:22:06Z

For posterity, here is one reason why people might want to set this value to false.

@Cheesebaron is this why you're doing it or did you have some other reason?

Cheesebaron · 2025-03-16T20:29:27Z

For posterity, here is one reason why people might want to set this value to false.

@Cheesebaron is this why you're doing it or did you have some other reason?

No we had it as there was a bug in an earlier version of net-android which crashed at startup failing to extract assemblies on some devices. This was fixed later. I think this was around .NET 7

jamescrosswell · 2025-03-16T21:38:25Z

No we had it as there was a bug in an earlier version of net-android which crashed at startup failing to extract assemblies on some devices. This was fixed later. I think this was around .NET 7

OK that makes it easier to workaround then - for the most part people should be able to avoid having to set this to false (unless they need to inspect the IL to look into a gnarly problem).

Still, if there's any way we could degrade functionality and log (rather than crash), in these situations, that would be preferable.

@aritchie let's discuss next time we catch up.

github-project-automation bot added this to GDX Jan 27, 2025

getsantry bot added the Waiting for: Product Owner label Jan 27, 2025

getsantry bot added this to GitHub Issues with 👀 3 Jan 27, 2025

getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 3 Jan 27, 2025

getsantry bot removed the Waiting for: Product Owner label Jan 27, 2025

getsantry bot removed the status in GitHub Issues with 👀 3 Jan 27, 2025

bruno-garcia added Bug Something isn't working Framework: MAUI labels Jan 27, 2025

getsantry bot added the Waiting for: Product Owner label Jan 27, 2025

getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 3 Jan 27, 2025

getsantry bot removed the Waiting for: Product Owner label Jan 28, 2025

getsantry bot removed the status in GitHub Issues with 👀 3 Jan 28, 2025

getsantry bot added the Waiting for: Product Owner label Jan 28, 2025

getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 3 Jan 28, 2025

bitsandfoxes removed the Waiting for: Product Owner label Jan 29, 2025

getsantry bot removed the status in GitHub Issues with 👀 3 Jan 29, 2025

jamescrosswell assigned aritchie Feb 3, 2025

aritchie added the Blocked label Feb 4, 2025

aritchie moved this to Blocked in GDX Feb 14, 2025

bruno-garcia pinned this issue Mar 16, 2025

getsantry bot added the Waiting for: Product Owner label Mar 16, 2025

getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 3 Mar 16, 2025

getsantry bot removed the Waiting for: Product Owner label Mar 16, 2025

getsantry bot removed the status in GitHub Issues with 👀 3 Mar 16, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Initializing SentrySdk Crashes when running with AndroidEnableAssemblyCompression = false in Release mode #3920

Initializing SentrySdk Crashes when running with AndroidEnableAssemblyCompression = false in Release mode #3920

Cheesebaron commented Jan 27, 2025

jamescrosswell commented Jan 27, 2025

Cheesebaron commented Jan 27, 2025

jamescrosswell commented Jan 28, 2025 •

edited

Loading

Cheesebaron commented Jan 28, 2025

pkubs-ui commented Jan 28, 2025

aritchie commented Feb 4, 2025

bruno-garcia commented Mar 12, 2025 •

edited

Loading

aritchie commented Mar 13, 2025

jamescrosswell commented Mar 16, 2025

Cheesebaron commented Mar 16, 2025

jamescrosswell commented Mar 16, 2025

Initializing SentrySdk Crashes when running with AndroidEnableAssemblyCompression = false in Release mode #3920

Initializing SentrySdk Crashes when running with AndroidEnableAssemblyCompression = false in Release mode #3920

Comments

Cheesebaron commented Jan 27, 2025

Package

.NET Flavor

.NET Version

OS

SDK Version

Self-Hosted Sentry Version

Steps to Reproduce

Expected Result

Actual Result

jamescrosswell commented Jan 27, 2025

Cheesebaron commented Jan 27, 2025

jamescrosswell commented Jan 28, 2025 • edited Loading

Cheesebaron commented Jan 28, 2025

pkubs-ui commented Jan 28, 2025

aritchie commented Feb 4, 2025

bruno-garcia commented Mar 12, 2025 • edited Loading

aritchie commented Mar 13, 2025

jamescrosswell commented Mar 16, 2025

Cheesebaron commented Mar 16, 2025

jamescrosswell commented Mar 16, 2025

jamescrosswell commented Jan 28, 2025 •

edited

Loading

bruno-garcia commented Mar 12, 2025 •

edited

Loading