provider.SignInAsync() error from CommunityToolkit.Authentication.Uwp

Question

The following code of a classic UWP app used for OneDrive access worked for a few years without any issues:

string[] scopes = new string[] { "Files.ReadWrite.AppFolder" };
ProviderManager.Instance.GlobalProvider = new WindowsProvider(scopes);
IProvider provider = ProviderManager.Instance.GlobalProvider;
await provider.SignInAsync();

await provider.SignInAsync() started to throw the exception recently:

Source = "CommunityToolkit.Authentication.Uwp"

Message = "Object reference not set to an instance of an object."

at CommunityToolkit.Authentication.WindowsProvider.<GetTokenAsync>d__38.MoveNext() in CommunityToolkit.Authentication\WindowsProvider.cs:line 186 at CommunityToolkit.Authentication.WindowsProvider.<SignInAsync>d__35.MoveNext() in CommunityToolkit.Authentication\WindowsProvider.cs:line 110

I don't know exactly when it started to have this, and what changes caused this. Could anyone offer a tip on how to find the culprit?

Answer 1

Hi @Hong ,

The problem does not seem to be your sign-in logic anymore. The crash is happening inside WindowsProvider.GetWebTokenRequest(), when the Toolkit tries to loop through _webAccountProviderConfig.MSATokenRequestProperties.

That means the Toolkit is using a config object that was not fully initialized. So this looks more like a Toolkit bug or package/version mismatch than an issue in your app code. Reinstalling the app would not fix that.

The next thing I would try is creating WindowsProvider with an explicit WebAccountProviderConfig, and making sure the MSA and AAD token property collections are initialized before sign-in.

For example:

var webAccountProviderConfig = new WebAccountProviderConfig
{
    WebAccountProviderType = WebAccountProviderType.Msa,
    MSATokenRequestProperties = new Dictionary<string, string>(),
    AADTokenRequestProperties = new Dictionary<string, string>()
};

var provider = new WindowsProvider(
    scopes,
    webAccountProviderConfig: webAccountProviderConfig,
    autoSignIn: false);

That sample is only for reference, so you may need to adjust it for your project and package version.

One important detail is that the public 7.1.x docs do not clearly show these token property members, but your decompiled code does. That suggests you may be using a different build or variant of the package.

If you can edit the Toolkit source, the cleanest fix is to add null checks in GetWebTokenRequest() before looping through MSATokenRequestProperties or AADTokenRequestProperties.

At this point, I would treat this as a library issue rather than an app issue. The sign-in dialog is showing correctly, and the crash happens only after that when the Toolkit builds the token request.

If the app is still being maintained, I would also consider moving away from CommunityToolkit.Authentication.Uwp over time. MSAL with Microsoft Graph is the more reliable long-term option.

Answer 2

Hi @Hong ,

Thanks for reaching out.

From the stack trace, this looks less like your app code suddenly breaking and more like the authentication flow underneath it no longer returning what WindowsProvider expects. The failure is happening inside WindowsProvider.GetTokenAsync(), so the likely issue is that the Windows account broker is returning an unexpected or incomplete token result, and the Toolkit ends up hitting a null reference while processing it.

The first thing I would try is turning off the automatic silent sign-in in the constructor and handling the flow explicitly. WindowsProvider defaults autoSignIn to true, so it may already be kicking off a silent sign-in before your later SignInAsync() call runs. Driving that flow yourself is the cleanest short-term test and may avoid the overlap entirely:

string[] scopes = { "Files.ReadWrite.AppFolder" };

var provider = new WindowsProvider(scopes, autoSignIn: false);
ProviderManager.Instance.GlobalProvider = provider;

if (!await provider.TrySilentSignInAsync())
{
  await provider.SignInAsync();
}

That sample is mainly meant as a reference for the sign-in flow, so you may need to adjust it a bit to fit your app structure and how your project initializes authentication.

If that still fails, I would clear any cached account state next. This provider stores account information in local app settings, and if those cached values no longer line up with what Windows account services expect, sign-in can start failing even though the code has not changed. Clearing the app's local data, reinstalling the app, or removing and re-adding the Microsoft account under Windows account settings are all good checks. It is also worth trying the same build on a different Windows profile or another machine. If it only fails on one profile, that points much more strongly to stale local account or token state than to a regression in your app.

One other thing to verify is that the provider is being created and used on a UI-capable thread. The interactive path uses AccountsSettingsPane, so if this is now being called from a different context than before, passing the correct DispatcherQueue into WindowsProvider is important.

If you want to narrow down the culprit more precisely, try logging the full exception details and, if possible, step into the Toolkit source around GetTokenAsync(). If the token request is coming back as successful but the response payload is null or empty, that would confirm this is really an edge case between the Toolkit and the Windows broker rather than a normal sign-in error in your app.

For the longer term, I would also keep in mind that CommunityToolkit.Authentication.Uwp is an older authentication stack and is not especially resilient to changes in the identity platform. If this app is still being maintained, moving the sign-in flow to MSAL with Microsoft Graph would be the more reliable path going forward, and it will also give you much better diagnostics when token acquisition fails.

Hope this helps! If my answer was helpful, I would greatly appreciate it if you could follow the instructions here so others with the same problem can benefit as well.

Answer 3

The exception is thrown inside WindowsProvider.SignInAsync, specifically in GetTokenAsync, which indicates the internal provider state is null when the sign‑in is invoked. From the available APIs, the following points are relevant:

1. WindowsProvider is an IProvider implementation that uses the Windows account system and the AccountsSettingsPane for authentication.
2. The constructor has an autoSignIn parameter (default true) and a dispatcherQueue parameter:

      public WindowsProvider(
          string[] scopes = default,
          WebAccountProviderConfig? webAccountProviderConfig = default,
          AccountsSettingsPaneConfig? accountsSettingsPaneConfig = default,
          bool autoSignIn = true,
          Windows.System.DispatcherQueue dispatcherQueue = default);
   

   It attempts a silent sign‑in on construction when autoSignIn is true.
3. WindowsProvider.TrySilentSignInAsync is the supported way to check whether a user is already signed in without UI:

      public override Task<bool> TrySilentSignInAsync();
   

4. IProvider.TrySilentSignInAsync is exposed at the interface level as well:

      public Task<bool> TrySilentSignInAsync();
   

Given that the same code worked for years and now fails with a NullReferenceException inside GetTokenAsync, the most likely cause is that the internal Windows account provider or token acquisition context is no longer initialized as expected in the current environment (for example, due to changes in available accounts, OS behavior, or how the AccountsSettingsPane is invoked).

To isolate and work around the issue using the available APIs:

1. Explicitly construct WindowsProvider and avoid relying solely on SignInAsync:

      string[] scopes = { "Files.ReadWrite.AppFolder" };
      var windowsProvider = new WindowsProvider(scopes);
      ProviderManager.Instance.GlobalProvider = windowsProvider;
      IProvider provider = ProviderManager.Instance.GlobalProvider;
   

2. First attempt a silent sign‑in and only then call SignInAsync if needed:

      bool silentOk = await provider.TrySilentSignInAsync();
      if (!silentOk)
      {
          await provider.SignInAsync();
      }
   

   This uses the documented TrySilentSignInAsync path and may avoid hitting the null state that causes the exception.
3. If the app is not running on the UI thread when creating WindowsProvider, pass an appropriate DispatcherQueue so that UI operations for the AccountsSettingsPane can be dispatched correctly. The constructor explicitly allows specifying a DispatcherQueue for UI updates.
4. If the app previously relied on automatic silent sign‑in (autoSignIn = true), try disabling it and controlling the flow explicitly:

      var windowsProvider = new WindowsProvider(scopes, autoSignIn: false);
      ProviderManager.Instance.GlobalProvider = windowsProvider;
      IProvider provider = ProviderManager.Instance.GlobalProvider;
      
      bool silentOk = await provider.TrySilentSignInAsync();
      if (!silentOk)
      {
          await provider.SignInAsync();
      }
   

5. Use ProviderManager consistently as the single source of the global provider:

      ProviderManager.Instance.GlobalProvider = windowsProvider;
      // Later, controls and helpers will use ProviderManager.Instance.GlobalProvider
   

If the exception persists even when using TrySilentSignInAsync and explicit construction, the next step is to inspect the environment (Windows account availability, whether the AccountsSettingsPane can be shown, and whether the app is on a supported Windows build) and compare it with a machine where the same code still works, since the public API surface itself (constructor, SignInAsync, TrySilentSignInAsync) has not changed in the referenced version.

---

References:

• WindowsProvider Class
• WindowsProvider Constructor
• WindowsProvider.SignInAsync Method
• WindowsProvider.TrySilentSignInAsync Method
• ProviderManager Class
• IProvider.TrySilentSignInAsync Method