[net11.0-android/CoreCLR] DOTNET_EnableEventPipe via AndroidEnvironment aborts app at startup (SIGABRT) instead of writing a trace

[gentledepp]

Android application type

.NET Android (net11.0-android), CoreCLR runtime

Description

Enabling a startup EventPipe file session via the standard runtime environment variables — set through AndroidEnvironment — makes the app fatally abort at startup (SIGABRT) instead of writing a trace file (or cleanly no-op'ing).

AndroidEnvironment.txt:

DOTNET_EnableEventPipe=1
DOTNET_EventPipeConfig=Microsoft-Windows-DotNETRuntime:0x1F000080018:5
DOTNET_EventPipeOutputPath=/storage/emulated/0/Android/data/<pkg>/files/startup.nettrace
DOTNET_EventPipeCircularMB=256

logcat:

D DOTNET  : AndroidCryptoNative_InitLibraryOnLoad: ... pal_jni.c
E DOTNET  : Fatal error.
E DOTNET  : Got a SIGABRT while executing native code. This usually indicates
E DOTNET  : a fatal error in the runtime or one of the native libraries used by your application.
F libc    : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid ... (l.filler.avalon)
F DEBUG   : #01 ... libmonodroid.so (xamarin::android::Helpers::abort_application(...)+836)

No EventPipe file is created; the process dies before any UI. Removing the DOTNET_EnableEventPipe/DOTNET_EventPipe* vars and rebuilding restores normal startup.

Expected

Either honor the env-var-driven EventPipe file session (write the .nettrace to the given path) or ignore it gracefully — not SIGABRT. (If env-var EventPipe startup is intentionally unsupported on Android CoreCLR, a diagnostic message instead of an abort would help; today the only working path seems to be programmatic session start, e.g. the maui ProfilingHelper injection.)

Steps to reproduce

1. net11.0-android app, CoreCLR runtime.
2. Add the vars above to an AndroidEnvironment file; build -c Release and deploy.
3. Launch → immediate SIGABRT (see logcat).

Environment

• Host: Windows 11
• .NET SDK: 11.0.100-preview.6.26359.118
• App: .NET MAUI–embedding Avalonia app, TFM net11.0-android, CoreCLR runtime
• Device: Google Pixel 9 Pro (physical, USB)

[jonathanpeppers]

/cc @lateralusX

I don't know if you are intended to use these environment variables directly on mobile.

I believe you can achieve the same thing by:

• Build/deploy a Release build of your app with -p:EnableDiagnostics=true
• dotnet-trace collect --dsrouter android --providers 'Microsoft-Windows-DotNETRuntime:0x1F000080018:5'

See tracing.md for details.

Does that work instead?