Teams 0x80070190: Sign-In and Launch Fix That Works

You click Teams, it spins, then spits out 0x80070190 and dumps you back at the sign-in screen. Annoying, right? Let's get you back in.

The fix that works 9 times out of 10

The culprit here is almost always a corrupted Windows credential tied to your Microsoft 365 account, sometimes paired with a stale WebView2 runtime. Teams 2.x (the new client) leans hard on WebView2, so when that runtime is broken or half-updated, auth fails with 0x80070190.

Do this in order. Don't skip steps.

Step 1: Kill every Teams process

Teams leaves background processes running even after you close the window. If you don't kill them, nothing you do next sticks.

taskkill /F /IM ms-teams.exe /T
taskkill /F /IM Teams.exe /T
taskkill /F /IM msedgewebview2.exe /T

If you're on the classic Teams client, just taskkill /F /IM Teams.exe /T is enough.

Step 2: Nuke the credential

1. Hit Win+R, type control keymgr.dll, press Enter.
2. Click Windows Credentials.
3. Look for anything named MicrosoftOffice16_Data:ADAL, MicrosoftOffice16_Data:SSPI, Teams, or msteams.
4. Delete them all. Every one.

This is the actual fix. I've watched a single stale MicrosoftOffice16_Data:ADAL entry cause 0x80070190 for weeks on end.

Step 3: Clear the Teams cache

Close Teams first. Then:

rmdir /S /Q "%appdata%\Microsoft\Teams"
rmdir /S /Q "%localappdata%\Microsoft\Teams"
rmdir /S /Q "%localappdata%\Packages\MSTeams_8wekyb3d8bbwe\LocalCache"

That third path is the new Teams 2.x cache. Don't skip it. The classic client cache won't touch it.

Step 4: Repair or reinstall WebView2

Open Settings > Apps > Installed apps. Search for Microsoft Edge WebView2 Runtime. If it's there, click Modify > Repair. If it's missing or repair doesn't help, download the Evergreen Bootstrapper from Microsoft and reinstall.

Reboot. Launch Teams. Sign in. It should go through.

Why this works

0x80070190 is a WININET_E_ class error — specifically it maps to a bad or missing credential handle during the OAuth token exchange. Teams asks Windows Credential Manager for the cached token to your tenant, Credential Manager hands back something malformed (or nothing at all), and the auth stack bails with 0x80070190.

The WebView2 piece matters because Teams 2.x renders its sign-in flow inside a WebView2 control. If that runtime is mid-update or the user profile inside it is corrupt, the sign-in page can't complete the redirect, and you get the same code bounced back.

Clearing the credential forces a fresh OAuth dance. Repairing WebView2 gives the auth page a clean surface to run on. Both have to be healthy or you'll keep looping.

Less common variations

Error only happens on one machine but not others

Check for a lingering HKCU\Software\Microsoft\Office\16.0\Common\Identity key with a stale SignedOutADAL or ADALUserId value. Delete the key and re-launch Teams.

Error on a domain-joined machine with Conditional Access

If your org enforces Conditional Access, 0x80070190 can show up when the device isn't registered with Entra ID. Run dsregcmd /status and confirm AzureAdJoined : YES or DomainJoined : YES with a valid PRT. If the PRT is missing, dsregcmd /refreshprt or a re-join fixes it.

Error after a Windows feature update

Feature updates sometimes break the WebView2 user data folder at %localappdata%\Microsoft\EdgeWebView. Delete that folder (the whole thing), reboot, and let Teams rebuild it.

Error on Windows Server 2019/2022 with Teams installed via VDI

Non-persistent VDI uses per-user WebView2 data. If your golden image has a baked-in WebView2 profile from the build account, every user inherits it and 0x80070190 shows up for everyone. Strip %localappdata%\Microsoft\EdgeWebView from the image before sealing.

Error after password change

Old tokens survive password rotations. Wipe the credentials again (Step 2). This is the number one repeat offender I see — user changes password on Friday, Monday morning nothing works.

Prevention

• Keep WebView2 on auto-update. Don't pin it in your image.
• If you rotate passwords on a schedule, clear Teams credentials as part of the rotation script. A three-line PowerShell loop against cmdkey handles it.
• Exclude %localappdata%\Microsoft\EdgeWebView from roaming profiles and from FSLogix containers unless you know exactly what you're doing — the profile is per-machine, not per-user, and roaming it breaks auth.
• Don't sign into Teams on a machine with your admin account for testing. It poisons the credential store for the actual user later. Use a test tenant.

If you've done all of the above and it still fails, check your proxy. A TLS-inspecting proxy that blocks login.microsoftonline.com or returns a weird cert will present as 0x80070190 too. Bypass the proxy for Teams endpoints as a test — if sign-in goes through, you found your real problem.