MSAL.NET NativeInterop Core.Dispose invalidates an unrelated GCHandle

Question

MSAL.NET NativeInterop Core.Dispose invalidates an unrelated GCHandle

Vince Hardwick 25

Has anyone found a safe workaround for this MSAL.NET NativeInterop defect while it awaits triage?

Issue #6220 reports that after removing a Core.LogEvent handler, disposing Core invalidates an unrelated GCHandle allocated by the caller. The public issue includes a standalone reproduction and reports the behavior with Microsoft.Identity.Client.NativeInterop 0.20.6, also used by Microsoft.Identity.Client.Broker 4.91.0.

I have asked for triage on the original GitHub issue: https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/6220 (no maintainer response yet as of 19 October 2026).

Is there a known safe workaround, or should users avoid this event subscribe/unsubscribe sequence until the issue is assessed? The report says leaving the handler subscribed avoids its minimal reproduction, but that has not been assessed as a general workaround for Broker applications?

Vince Hardwick 25 Reputation points

2026-10-19T13:22:21.8733333+00:00
The recommendation to use WithLogging does not address Broker’s internal subscription to NativeInterop.Core.LogEvent.

Microsoft’s public MSAL.NET 4.91.0 source shows that:

AcquireTokenInteractiveAsync constructs a LogEventWrapper during an ordinary Broker operation.

The wrapper’s constructor subscribes to Core.LogEvent, and its Dispose method unsubscribes. Those operations are not conditional on the application’s logging configuration.

The logging level is checked when forwarding an event. That check does not prevent the subscription or unsubscription.

Broker subsequently disposes its shared Core through its process-exit handler.

The WithLogging implementation configures logging; it does not remove that internal sequence. An application can therefore use only public MSAL APIs and still reach the subscription, unsubscription and disposal operations implicated by the report.

This does not establish that every Broker application will experience corruption. It does mean that using WithLogging has not been demonstrated to avoid the defect.

The defect has already been reported, with a standalone reproduction, in MSAL.NET issue #6220.

Could a Microsoft engineer responsible for MSAL.NET please provide a human response confirming whether Broker’s internal sequence is affected and whether there is a supported mitigation or a planned fix?

1 answer

Your answer

Vince Hardwick 25 Reputation points

2026-10-19T13:22:21.8733333+00:00

The recommendation to use WithLogging does not address Broker’s internal subscription to NativeInterop.Core.LogEvent.

Microsoft’s public MSAL.NET 4.91.0 source shows that:

AcquireTokenInteractiveAsync constructs a LogEventWrapper during an ordinary Broker operation.

The wrapper’s constructor subscribes to Core.LogEvent, and its Dispose method unsubscribes. Those operations are not conditional on the application’s logging configuration.

The logging level is checked when forwarding an event. That check does not prevent the subscription or unsubscription.

Broker subsequently disposes its shared Core through its process-exit handler.

The WithLogging implementation configures logging; it does not remove that internal sequence. An application can therefore use only public MSAL APIs and still reach the subscription, unsubscription and disposal operations implicated by the report.

This does not establish that every Broker application will experience corruption. It does mean that using WithLogging has not been demonstrated to avoid the defect.

The defect has already been reported, with a standalone reproduction, in MSAL.NET issue #6220.

Could a Microsoft engineer responsible for MSAL.NET please provide a human response confirming whether Broker’s internal sequence is affected and whether there is a supported mitigation or a planned fix?

Answer 1

There is currently no confirmed safe workaround for #6220; avoid manually subscribing and unsubscribing Core.LogEvent, and use MSAL.NET’s public logging API instead of treating “leave the handler subscribed” as a production mitigation.

What is established

The report remains open and covers Microsoft.Identity.Client.NativeInterop 0.20.6 on .NET Framework 4.8, where the standalone reproduction uses Core directly without authentication, broker operation, or an identity provider.^1^

Consequently:

The reproduction demonstrates corruption following the subscribe → unsubscribe → dispose sequence.
It does not establish that leaving the handler subscribed is safe across repeated Core lifetimes, concurrent callbacks, or Broker shutdown.
It also does not establish that every Broker application will encounter the defect. The minimal reproduction bypasses the Broker path.
No matching fix or pull request has been identified, and MSAL.NET 4.91.0 cannot be considered to contain a fix merely because it carries NativeInterop 0.20.6.

The older callback-lifetime bug #3578 is not a workaround for this case. It involved a native callback reaching a garbage-collected managed delegate and was reported fixed in MSAL.NET 4.47.0; #6220 presents a different lifetime sequence and must be assessed independently.^2^

Recommended mitigation

Applications using `Core` directly

Remove application-level use of Core.LogEvent where possible.
Do not add an unsubscribe-before-dispose operation merely to clean up the handler.
Do not deliberately keep the handler subscribed and then dispose Core as a claimed fix; that variation only avoids the current minimal reproduction.
If direct Core logging is indispensable, keep the affected code out of production or isolate it in a disposable helper process until maintainers define a safe lifetime contract or release a fix. Process isolation prevents native-memory corruption from compromising the main application.
Retain the standalone reproducer as a regression test and rerun it against any candidate NativeInterop update before deployment.

Avoid attempting to “repair” the caller’s GCHandle afterward. Once interop code has freed or corrupted a handle incorrectly, allocating another handle or suppressing Free() does not restore a reliable process state.

Applications using `Microsoft.Identity.Client.Broker`

Do not reproduce the direct-Core workaround inside application code. Continue using the Broker through its public MSAL.NET APIs, and avoid reflection or direct access to its NativeInterop Core.

For diagnostics, configure logging when constructing the MSAL application with WithLogging(IIdentityLogger, Boolean). This is the documented logging surface; PII logging is disabled unless explicitly enabled.^3^

var logger = new MyIdentityLogger();

var app = PublicClientApplicationBuilder
    .Create(clientId)
    .WithBroker(new BrokerOptions(BrokerOptions.OperatingSystems.Windows))
    .WithLogging(logger, enablePiiLogging: false)
    .Build();

If a Broker application is actually crashing or detects handle invalidation, add that concrete Broker reproduction to #6220, including:

Exact MSAL.NET, Broker, and NativeInterop versions.
.NET runtime, architecture, and Windows build.
Whether disposal races with token acquisition or shutdown.
A minimal dump or stack showing the invalid GCHandle.
MSAL logs with sensitive information removed.

MSAL recommends enabling logging for diagnosis, using Informational normally and enabling Verbose only temporarily; network traces can contain PII and credentials and must be sanitized before posting.^3^

Practical decision

Until #6220 receives maintainer triage or a fixed package:

Direct NativeInterop use: avoid the LogEvent subscribe/unsubscribe/dispose sequence.
Broker use without observed failure: do not alter Broker internals based solely on the direct-Core reproduction.
Broker use with a matching failure: isolate or disable the affected Broker path if operationally possible and provide a Broker-specific reproduction.
Leaving the handler subscribed: regard it only as a reproduction observation, not a generally safe workaround.

References

MSAL.NET NativeInterop Core.Dispose invalidates an unrelated GCHandle

1 answer

What is established

Recommended mitigation

Applications using Core directly

Applications using Microsoft.Identity.Client.Broker

Practical decision

Your answer

Applications using `Core` directly

Applications using `Microsoft.Identity.Client.Broker`