Every time I try to log in to Microsoft Store, Xbox or any other Microsoft app in Windows which requires Microsoft account connection (or even directly under Settings->Accounts->Email & accounts or directly attempting migrating a local profile to a Microsoft profile it fails with 0x80048054 or with 0x80860010 (essentially too many requests, so this is not significant).
When I set up a second profile and try the same log in to the same Microsoft account there it works just fine.
How to debug this problem?
An important note - I did migrate my NVME drive by cloning from 512GB to 2TB which then required clearing the TPM storage by disabling and reenabling it and the account might be corrupted since then, don't know as it was years ago.
I spent 2 days debugging this issue by searching and by using AI. I did not want to migrate to a new profile as the broken profile was an old profile with a lot of apps and customizations and migration would be similar as to reinstalling Windows fresh or just moving to Linux. Hope this helps someone and saves them the time and pain of debugging or moving to a new profile.
First I tried the typical steps like removing/re-adding the account, clearing IdentityCache / TokenBroker / Credential Manager, re-registering Microsoft.AccountsControl and Microsoft.AAD.BrokerPlugin, sfc/DISM, and reboots. Nothing helped.
Here is what turned out to be the problem on my machine:
Root cause
Two artifacts belonging to that profile carried impossible far-future timestamps. On my machine this followed cloning Windows from a 512 GB NVMe to a 2 TB NVMe (and a later BIOS fTPM clear), but the exact trigger is unproven — if you've never cloned a disk you may still hit this.
1. A per-user CNG key file dated in the year 2175
%APPDATA%\Microsoft\Crypto\Keys\ contained the Microsoft Connected Devices Platform device certificate key with LastWriteTime of 2175. Cryptographic operations against it failed with ERROR_INVALID_FUNCTION / NTE_NOT_FOUND.
2. A device-identity record dated in the year 2161 — the real killer
HKEY_USERS\.DEFAULT\Software\Microsoft\IdentityCRL\DeviceIdentities\production\<YOUR-USER-SID>\<deviceid>\DeviceId
held:
<Data DAInvalidationTime="6039175974"><User username="…"><HardwareInfo BoundTime="6039175979" …/></User></Data>
6039175974 as Unix time is 2161-05-16. A healthy profile has no DAInvalidationTime attribute at all.
Why that breaks everything
DAInvalidationTime tells wlidsvc to discard any device-auth (DA) token obtained before that moment. Because the value exceeds INT_MAX, the service reports it as exactly 2147483647 (2038-01-19) — it appears to saturate a 32-bit signed integer. Every DA token, no matter how fresh, is therefore "obtained prior to" the watermark and is thrown away microseconds after being issued:
deviceidentity.cpp:931 Invalidating DA token for <deviceid> obtained prior DA InvalidationTime: 2147483647, 1784936365
DeviceIdHelpers::GetDeviceAuthToken → 0x80048054
Note this store lives in the SYSTEM hive (HKU\.DEFAULT, because wlidsvc runs as LocalSystem) but is keyed by your user SID. That's why it survives everything: it's not in HKCU, not in HKLM, and it's an XML attribute, so registry value searches never find it.
How to check whether you have it
# 1. Any device identity with a DAInvalidationTime? Compare the number against https://www.epochconverter.com — anything beyond ~2040 is corrupt.
Get-ChildItem "Registry::HKEY_USERS\.DEFAULT\Software\Microsoft\IdentityCRL\DeviceIdentities\production" -Recurse |
ForEach-Object {
$d = (Get-ItemProperty $_.PSPath -ErrorAction SilentlyContinue).DeviceId
if ($d -match 'DAInvalidationTime="(\d+)"') {
"{0}`n {1} -> {2}" -f $_.Name, $matches[1],
[DateTimeOffset]::FromUnixTimeSeconds([long]$matches[1]).ToString('yyyy-MM-dd')
}
}
# 2. Any per-user crypto key with an absurd date?
Get-ChildItem -Force "$env:APPDATA\Microsoft\Crypto\Keys" | Select-Object Name, LastWriteTime
To confirm it's really your problem, capture the auth trace (elevated) and reproduce once:
logman create trace LiveId -p "Microsoft-Windows-LiveId" 0xffffffffffffffff 0xff -o C:\t\liveid.etl -ets
# …attempt the sign-in, let it fail…
logman stop LiveId -ets
tracerpt C:\t\liveid.etl -o C:\t\liveid.csv -of CSV -y
Select-String C:\t\liveid.csv -SimpleMatch 'Invalidating DA token'
A healthy profile produces zero hits. Mine produced 20 per attempt.
Fix
Back up first:
reg export "HKU\.DEFAULT\Software\Microsoft\IdentityCRL\DeviceIdentities" C:\backup-devids.reg
Then edit that DeviceId value to remove the DAInvalidationTime attribute entirely and set BoundTime to a sane current Unix timestamp — i.e. make it match a healthy profile:
<Data><User username="…"><HardwareInfo BoundTime="1784936832" TpmKeyStateClient="0" TpmKeyStateServer="0" LicenseInstallError="0"/></User></Data>
Get a correct timestamp with [DateTimeOffset]::UtcNow.ToUnixTimeSeconds() (not Get-Date -UFormat %s, which is off by your UTC offset).
Then restart the service and retry:
Restart-Service wlidsvc
Also move the future-dated file out of %APPDATA%\Microsoft\Crypto\Keys\ — Windows regenerates it (mine came back healthy at 1080 bytes, matching a working profile).
Re-trace afterwards: Invalidating DA token should now be 0.
Gotcha — do not set up a Windows Hello PIN while troubleshooting this
Creating a PIN creates NGC containers, which pushes ShouldCreateNgcKey off the benign "No usable NGC containers found" path onto one that then demands an NGC key for your account. Because Store/Settings request tokens with noUI, it can't prompt and dies silently with ONL_E_ACTION_REQUIRED / PPCRL_E_NGC_REGISTRATION_REQUIRED — a second, self-inflicted failure that masks the first. Removing the PIN reverted it.
Things that were NOT the cause (save yourself the time)
ACLs on profile keys/files; the TPM (healthy, and tpmtool said ready — clearing it is what created some of this mess); VBS/Credential Guard key isolation; the missing Microsoft.AccountsControl per-user folder (absent on healthy profiles too — these are SystemApps that keep state in the registry); the virtualapp/didlogical credential (deleting it regenerates the same device ID); removing the device from account.microsoft.com; IdentityCRL\KeyCache; and an empty IdentityCache folder (a symptom of never completing sign-in, not a cause).
Also, two traps if you go trace-diving: tracerpt CSV has a variable column count per event type, so Import-Csv silently misaligns fields — read it as raw lines. And Win32 message strings are localised per profile, so a string match can return zero for one profile purely because it's in another language.
