WHAT HAPPENED
Windows protects app secrets (browser cookies and passwords, Credential Manager, app sessions such as WhatsApp) with DPAPI. DPAPI uses a "master key" stored in %APPDATA%\Microsoft\Protect<your SID>, and that key is unlocked by your sign-in credential.
- After the 26H2 update, the first sign-in could not unlock the existing master key. Every app that depends on DPAPI started failing.
- At the sign-in screen I clicked "I forgot my PIN" / the web sign-in option by accident. This signs you in through the browser or phone (the system account "WsiAccount" is enabled for this flow), so Windows does not receive your password. Windows then created a NEW master key protected by a different credential. Apps could not read their old data, so they silently created new keys and started from scratch (lost logins).
- The next day I signed in with my normal PIN. The PIN unlocked the ORIGINAL master key again, but not the one created during the web sign-in. So the data the apps re-created the day before became unreadable too, and WhatsApp asked for the QR code again.
My password had not changed in months. The PIN and the password unlock the same (original) key. Only the web sign-in path creates a separate key.
HOW TO CONFIRM YOU HAVE THE SAME PROBLEM
- In the Crypto-DPAPI Operational log, look for Event 1 "DPAPI created Master key" at a time you did not expect, followed by many 8198/8203/3 events naming a different key GUID.
- In %APPDATA%\Microsoft\Protect<SID>\ (hidden/system files) you will see more than one recent key file with a creation date matching the problem.
- Local Users and Groups shows "WsiAccount" with a last logon time matching the moment the problem started.
THE FIX
Step 1. Sign in ONLY with your normal PIN or password. Do NOT use "I forgot my PIN", web sign-in or "Other sign-in options". Do NOT remove and re-create the PIN and do NOT reset your password yet: the PIN stores the credential that opens your original key, and re-creating it may lock that key permanently.
Step 2. Check if the old key works again: in the DPAPI log, the failures for the ORIGINAL key GUID should stop after this sign-in.
Step 3. Recover the original app data from a shadow copy (System Restore point) created BEFORE the update. Restore points are created automatically before feature updates. In an elevated Command Prompt:
vssadmin list shadows
Pick the shadow copy with a creation date just before the update (example: HarddiskVolumeShadowCopy4), then:
mklink /d C:\ShadowSnap \?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4\
(Both backslashes before "?" are required.) Now copy what you need from C:\ShadowSnap\Users<you>\ to a safe folder first, for example:
- AppData\Local\Microsoft\Credentials and AppData\Roaming\Microsoft\Credentials (Credential Manager)
- AppData\Local\Microsoft\Edge\User Data\Local State, and in Default: Login Data, Login Data For Account, Network\Cookies
- The same files for Chrome or other Chromium browsers (if "Local State" in the newest shadow copy has no "os_crypt" section, take "Local State" from an older shadow copy: the key does not change)
- Electron apps (Discord, Obsidian, etc.): AppData\Roaming<app>\Local State (and Local Storage for Discord)
Remove the link when done: rmdir C:\ShadowSnap
Step 4. Close the apps (Edge, Discord, etc.; check Task Manager for background processes), BACK UP the current files, then copy the old files over the current ones. For browser databases, delete the matching "-journal" / "-wal" files next to them. For Credential Manager, only copy files that do not already exist.
Step 5. Open the apps. Credential Manager (cmdkey /list) should show your old entries again, and browsers and apps should be signed in as before the update. WhatsApp: just link it again with the QR code from your phone. Chrome passwords stored in your Google account sync back by themselves.
Step 6. Restart and sign in with the PIN to confirm: no new "DPAPI created Master key" event and no new 8198 failures.
PREVENTION
- Avoid the "I forgot my PIN" / web sign-in option unless you really need it.
- Optional: Settings > Accounts > Sign-in options > turn off "Use my sign-in info to automatically finish setting up after an update", so the first sign-in after an update is done by you.
What I could not confirm: why the first sign-in right after the 26H2 update could not open the original key. It could be the automatic sign-in that finishes the update or the same web sign-in path. I filed a Feedback Hub report for Microsoft.