microsoft-authentication-library-for-dotnet: [Bug] Log-in window is sometimes left running by itself/orphaned

I’m experimenting with WinappSDK / WinUI3. Coming from UWP, one odd thing I’ve noticed is sometimes when my app closes/crashes, the MSAL sign-in window is left running on its own/orphaned. Why does that happen and is there a way to prevent it?

Which version of MSAL.NET are you using? 4.49.1-preview

Platform WinappSDK 1.3 expermintal1, WinUI3

** Repro ** It repros fine with a console app.

    static async Task Main(string[] args)
            var pca = PublicClientApplicationBuilder

            var result = pca.AcquireTokenInteractive(new[] { "" })
            // WAM account picker pops up here.
            await Task.Delay(1000);

            // app crashes, but instead of closing, both console and Account picker remain on the screen. Console is modal.
            throw new Exception("oh no");

Actual: when app crashes, the account picker stays on screen and so does the console window, which remains modal. Account Picker seems to be blocking the window from closing after the crash. App appears “frozen”

Expected: on app crash, Account picker and app should close.

About this issue

  • Original URL
  • State: open
  • Created a year ago
  • Comments: 19 (5 by maintainers)

Most upvoted comments

@localden - the account picker is a windows component separate from WAM. It’s official name is Accounts Settings Pane. It is owned by Windows. It is required when combining AAD and MSA accounts.

If MSAL knows we deal only with “work and school” accounts, then it bypasses this picker and goes directly to WAM’s AAD plugin, which behaves better in scenarios where you have a login hint etc.

I can repro the orphaned account picker scenario, though. Even better - I can’t continue in it in any capacity, I can only close it 😃


This will need our friends from WAM to take a look. App doesn’t have any control over those windows.

Yes, I can repro. I’ll update the steps.

@bgavrilMS The bottom screenshot.