Copilot WAM Sign-in Error on Windows 11: Diagnose and Repair Safely

Official documentation checked October 14, 2026.

A Copilot sign-in failure on Windows 11 is not automatically a Web Account Manager (WAM) failure. First identify the app, account type and full error. In particular, do not disconnect a managed work account or remove all Microsoft accounts just because a sign-in window says “Something went wrong.”

1. Confirm which sign-in experience is failing

Record whether you are using the standalone Copilot app, Copilot inside a Microsoft 365 desktop app, or a website. Also note whether the account is personal or belongs to work or school. Microsoft 365 desktop authentication guidance should not be applied indiscriminately to every app carrying the Copilot name.

For Microsoft 365 apps, WAM components help establish and renew sign-in sessions. Microsoft documents specific cases involving missing account packages, security-software interference and damaged per-user package state. These are possibilities to investigate, not a diagnosis from a spinner or generic message. Microsoft’s 1001 sign-in article describes particular historical scenarios; it does not establish that every present-day Copilot failure has the same cause.

• If an Entra error identifies MFA, consent, device compliance or access policy, ask IT to investigate that sign-in event. A package repair does not grant access or satisfy those requirements.
• If the same account works in a browser, record that result. It helps isolate the affected client, but is not proof that WAM is broken.
• If several desktop apps fail together, tell support which ones. If only the Copilot app fails, start with that app before attempting Windows authentication repairs.

2. Try an app-level recovery without removing Windows accounts

Save your work, close the affected app, restart Windows and install approved app and Windows updates. Select the intended account in the app’s sign-in flow and complete legitimate authentication prompts. Having both personal and work accounts on a computer is not, by itself, evidence of corruption.

For a standalone app that offers it, open Settings > Apps > Installed apps, find the app, select its menu, then Advanced options > Repair. Some apps do not have these options. See Microsoft’s Windows app-repair guidance.

Do not treat Reset as identical to Repair: Microsoft distinguishes these operations, and Reset may remove local app data. Preserve anything important and check your organization’s support process before resetting. For Microsoft 365 desktop sign-in failures, the Microsoft authentication guide links the Microsoft 365 Sign-in troubleshooter.

wsreset.exe is a Microsoft Store troubleshooting command. It is not documented there as a reset of WAM’s account database; repeating it is not a substitute for diagnosing sign-in.

3. Check WAM evidence in the affected Windows profile

If IT suspects the documented Microsoft 365 WAM problem, use Windows PowerShell in the affected user’s normal session for these read-only checks:

Get-AppxPackage Microsoft.AAD.BrokerPlugin
Get-AppxPackage Microsoft.Windows.CloudExperienceHost

The Microsoft Entra broker is relevant to organizational accounts; CloudExperienceHost is associated with the personal-account package in Microsoft’s authentication guidance. An empty result is a reason to investigate package registration. A returned package does not prove that its authentication flow works. Running the check as a different administrator account can inspect the wrong user’s state.

Ask IT to correlate the failure time with Event Viewer > Windows Logs > Application. Microsoft’s documented desktop sign-in scenario identifies AppModel-State events naming Microsoft.AAD.BrokerPlugin and package-settings failures. This is archived, scenario-specific guidance, not a requirement to reinstall brokers on every Windows 11 machine. Generic codes such as 0x80004005 alone do not establish that scenario.

4. Use a targeted repair only when the evidence matches

Microsoft’s missing-package authentication remedy provides separate re-registration instructions for work and personal accounts. Have IT choose the relevant procedure and verify the affected-user context and required privileges. Save work first: the documented commands include an option that can close applications. Do not paste both repair commands into every user profile or download replacement package files from an unofficial site.

If the failure returns, have the security or desktop-management team investigate the matching events and recent changes. Microsoft’s 1001 guidance also identifies unsupported roaming of identity data as one possible cause. Do not disable or uninstall security software yourself, create broad antivirus exclusions, delete token folders or certificates, change WAM startup settings, or detach the device from work management as trial-and-error fixes.

After an approved repair, retry the original action under the same account and check whether other affected apps recover. A successful sign-in does not prove the recurring cause is gone. Provide support with the exact app and Windows versions, account type, timestamp, error/correlation ID and diagnostic results. Send logs through your organization’s approved support channel; never post passwords, tokens or unredacted identity logs publicly.