Skip to content

Fix MacMainThreadScheduler crash when ManagedThreadId != 1 (#646) - #649

Merged
embetten merged 10 commits into
masterfrom
users/embetten/main-thread-bug
Mar 6, 2026
Merged

embetten merged 10 commits into
masterfrom
users/embetten/main-thread-bug

Conversation

@embetten

@embetten embetten commented Feb 25, 2026 •

Copy link
Copy Markdown
Contributor

Fixes #646 โ€” MacMainThreadScheduler.StartMessageLoop() throws "Message loop must be started on the main thread" when Environment.CurrentManagedThreadId is not 1, which can happen when launched via dotnet tool run or dotnet run where internal runtime threads consume thread ID 1 before Main() executes.

MSAL's MacMainThreadScheduler assumes ManagedThreadId == 1 means "main thread." This is a .NET runtime implementation detail, not a guarantee. The dotnet tool shim and certain hosting configurations cause Main() to run on a thread where this check fails.

This change proposes falling back to no longer use the MacMainThreadScheduler when the thread != 1. Windows and Linux brokers will be unaffected, but mac broker will become unavailable and fall back to browser or DCF.

@embetten

Copy link
Copy Markdown
Contributor Author

validated on linux-x64, win x64, arm64. Need to finialze mac testing

@embetten
embetten marked this pull request as ready for review March 4, 2026 23:58
@embetten

embetten commented Mar 4, 2026

Copy link
Copy Markdown
Contributor Author

finished mac testing

@AlexVTor

Copy link
Copy Markdown
Contributor

Looking to improve my understanding of the space:

I understand the bug lies in the thread scheduler expecting the main thread.
Is this fix to add a check for the current thread and to fallback to interactive auth (for macos) if needed?
If that is the case, does that mean that users in this scenario will always have to interact to provide auth, and the broker auth scenario isn't usable?

Comment thread CredentialProvider.Microsoft/Program.cs Resolved
Comment thread MicrosoftCredentialProvider.sln Resolved
@embetten

embetten commented Mar 5, 2026

Copy link
Copy Markdown
Contributor Author

Looking to improve my understanding of the space:

I understand the bug lies in the thread scheduler expecting the main thread. Is this fix to add a check for the current thread and to fallback to interactive auth (for macos) if needed? If that is the case, does that mean that users in this scenario will always have to interact to provide auth, and the broker auth scenario isn't usable?

The fix here is more for non-mac platforms by removing the managed thread id =1 that is only a requirement for the mac broker. But i did add some messages and checks for mac to fail early if possible.

But for all platforms, if brokered auth is not available or fails for some reason (e.g. not on main thread for mac, network issues for WAM, missing dependencies for Linux), we will try the next authentication method, which would be browser auth in this scenario. And Brokered auth is considered interactive, so it would be interactive auth regardless.

@AlexVTor Alex Torres (AlexVTor) left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@embetten
embetten merged commit 133f737 into master Mar 6, 2026
56 checks passed
@embetten
embetten deleted the users/embetten/main-thread-bug branch March 6, 2026 21:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Throws "Message loop must be started on the main thread" at "MacMainThreadScheduler.StartMessageLoop()"

2 participants