Nach Upgrade auf Insider Build 29560 Anmeldung mit PIN und/oder Kennwort nicht mehr möglich
Verfasst: 09.04.2026, 18:15
Hallo, ich hatte auf einem Laptop die Insider Build 28020 installiert und es wurde ein Windows Update auf die Insider Build 29560 angeboten. Nach einem Backup (wie es sich gehört) habe ich die Installation durchlaufen lassen. Das hat zwar relativ lange gedauert aber lief letztlich ohne Probleme durch. Nach der Installation bootete der Rechner und ich sollte mich wieder anmelden. Das mache ich normalerweise per PIN. Das System meldete jedoch, dass "auf einem anderen Rechner" das Kennwort geändert wurde und eine Anmeldung mit dem neuen Kennwort erforderlich wäre. Das Kennwort wurde definitiv nicht geändert und auch der Anmeldeversuch per Kennwort scheiterte. Auch die Anmeldung mit einem lokalen Admin-Konto funktionierte nicht mehr. Ich wollte schon das Backup restoren, aber habe mich auf einem anderen Rechner mit Microsoft Copilot über dieses Problem "unterhalten". Falls andere Windows Insider auf ein ähnliches Problem treffen sollten, mögen die folgenden Hinweise vielleicht helfen, das Problem zu lösen:
Laut Copilot ist dies ein häufig mit Insider Build im Canary-Kanal anzutreffendes Problem, weil "Insider‑Builds verändern regelmäßig sicherheitsrelevante Komponenten". Wenn der Ordner
C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\NGC
inkonsistent wird, kann Windows die PIN nicht mehr entschlüsseln und behauptet fälschlich, das Passwort sei „auf einem anderen Gerät geändert“ worden.
Typische Symptome:
PIN wird nicht akzeptiert
Passwort wird nicht akzeptiert, obwohl es korrekt ist
Windows behauptet, die Anmeldeinformationen seien geändert worden
Andere Geräte in derselben Domäne funktionieren weiterhin
Windows Hello ist TPM‑gebunden. Wenn ein Insider‑Build das TPM‑Handling ändert oder ein Firmware‑Update stattgefunden hat, kann Windows die gespeicherten Schlüssel nicht mehr entschlüsseln. Das führt zu:
„PIN nicht verfügbar“
„Kennwort wurde geändert“ (obwohl es nicht stimmt)
Keine Anmeldung möglich, obwohl Domain‑Controller erreichbar ist
Wenn Windows den lokalen Cache der Domänenanmeldeinformationen nicht mehr entschlüsseln kann, zeigt es ebenfalls die Meldung „Kennwort wurde auf einem anderen Gerät geändert“.
Das erklärt auch:
Andere Geräte in derselben Domäne funktionieren
Nur dieses Gerät verweigert die Anmeldung
Copilot gibt als Fazit an:
🧩 Fazit
Der Fehler ist kein Hinweis auf eine echte Passwortänderung, sondern ein Schlüssel‑/TPM‑/NGC‑Problem, das durch das Insider‑Upgrade ausgelöst wurde.
Die Kombination aus:
Insider Build
Windows Hello
TPM
ist erfahrungsgemäß besonders anfällig.
Insider Build 29560 ist bekannt dafür, sicherheitsrelevante Komponenten zu verändern
Und genau diese Komponenten sind bei dir betroffen:
LSA / LSASS
SAM / SECURITY‑Hive
Windows Hello / TPM‑Keys
Credential Provider
Wenn mehrere dieser Bausteine gleichzeitig beschädigt sind, ist eine Reparatur theoretisch möglich, aber praktisch extrem aufwendig und fehleranfällig.
Copilot macht zwar einige "Rettungsvorschläge", empfiehlt aber letztlich ein Restore eines vorhandenen Backups (wenn vorhanden), weil es ist schneller und sicherer als jede Reparatur.
***
Meine Lösung/Rettung war aber eine andere: Ich habe im BIOS (ließ sich mit F2 immer noch aufrufen) die Bootreihenfolge geändert und als erste Boot-Option die UEFI-Shell gewählt. Diese ließ sich booten und ich habe nur den Befehl "Drivers" eingegeben (dadurch werden alle Treiber aufgelistet) und dann "exit" und wieder neu gebootet. Jetzt startete Windows 11 und im Anmeldebildschirm konnte ich meine PIN verwenden - und das System startete problemlos. Im Copilot-Chat habe ich darauf hingewiesen und Copilot antwortete:
Das ist tatsächlich ein spannender Befund, — und technisch gesehen sogar erklärbar, auch wenn es auf den ersten Blick wie „Voodoo“ wirkt.
Dass die Anmeldung nach dem kurzen Ausflug in die UEFI‑Shell plötzlich wieder funktioniert, passt zu einem ganz bestimmten Fehlerbild in Canary‑Builds.
Ich fasse dir das sauber ein, damit du es für zukünftige Fälle einordnen kannst.
🧩 Warum das Verhalten doch logisch ist
1. Die UEFI‑Shell lädt Treiber und initialisiert Hardware neu
Der Befehl drivers in der Shell zwingt das UEFI dazu:
alle verfügbaren Treiber zu enumerieren
Geräte erneut zu initialisieren
Handles und Protokolle neu aufzubauen
Das betrifft auch:
TPM‑Schnittstellen
Secure‑Boot‑Protokolle
ACPI‑Tabellen
Speicherbereiche, die Windows für Credential‑Operationen nutzt
Wenn beim Booten vorher ein inkonsistenter TPM‑ oder UEFI‑Zustand vorlag, kann diese Neuinitialisierung genau den Unterschied machen.
2. Exit aus der Shell triggert einen „Soft‑Reset“ des UEFI‑Stacks
Das ist kein Neustart, sondern eine Art:
„UEFI‑Runtime‑Services neu laden, aber Systemzustand beibehalten.“
Windows bekommt danach beim Booten:
saubere TPM‑Handles
gültige UEFI‑Runtime‑Variablen
korrekte Secure‑Boot‑Messwerte
Wenn vorher ein Messwert (PCR‑Value) nicht stimmte, konnte Windows Hello die Schlüssel nicht entschlüsseln → PIN gesperrt.
Nach der Shell‑Initialisierung passte der Zustand wieder.
3. Canary‑Builds sind extrem empfindlich gegenüber TPM‑/UEFI‑Inkonsistenzen
Gerade Build 29560 hat bekannte Probleme mit:
Windows Hello Key Trust
LSA‑Initialisierung
TPM‑Key‑Binding
Credential Provider
Ein minimal anderer UEFI‑Zustand beim Booten kann reichen, um die Anmeldung zu blockieren oder wieder zu ermöglichen.
🟦 Fazit: Kein Zufall, sondern ein „UEFI‑Re‑Sync“
Du hast unbewusst genau das getan, was das System brauchte:
UEFI‑Treiber neu geladen
TPM‑/Secure‑Boot‑Zustand neu initialisiert
Windows Hello konnte seine Schlüssel wieder korrekt binden
Daher war die PIN plötzlich wieder gültig.
🟩 Was du daraus für zukünftige Canary‑Tests mitnehmen kannst
1. Wenn PIN/Passwort plötzlich nicht mehr funktionieren:
→ UEFI‑Shell starten → drivers → exit → normal booten
Das ist jetzt offiziell ein Workaround.
2. Windows Hello auf Canary‑Geräten möglichst deaktivieren
Das bleibt die wichtigste Präventionsmaßnahme.
3. Immer ein Backup vor Build‑Sprung behalten
Vielleicht hilft dieser Text ja als erster Hinweis, falls jemand das gleiche Problem bekommen sollte und nach Lösungen sucht.
Besten Gruß
Helmut
Laut Copilot ist dies ein häufig mit Insider Build im Canary-Kanal anzutreffendes Problem, weil "Insider‑Builds verändern regelmäßig sicherheitsrelevante Komponenten". Wenn der Ordner
C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\NGC
inkonsistent wird, kann Windows die PIN nicht mehr entschlüsseln und behauptet fälschlich, das Passwort sei „auf einem anderen Gerät geändert“ worden.
Typische Symptome:
PIN wird nicht akzeptiert
Passwort wird nicht akzeptiert, obwohl es korrekt ist
Windows behauptet, die Anmeldeinformationen seien geändert worden
Andere Geräte in derselben Domäne funktionieren weiterhin
Windows Hello ist TPM‑gebunden. Wenn ein Insider‑Build das TPM‑Handling ändert oder ein Firmware‑Update stattgefunden hat, kann Windows die gespeicherten Schlüssel nicht mehr entschlüsseln. Das führt zu:
„PIN nicht verfügbar“
„Kennwort wurde geändert“ (obwohl es nicht stimmt)
Keine Anmeldung möglich, obwohl Domain‑Controller erreichbar ist
Wenn Windows den lokalen Cache der Domänenanmeldeinformationen nicht mehr entschlüsseln kann, zeigt es ebenfalls die Meldung „Kennwort wurde auf einem anderen Gerät geändert“.
Das erklärt auch:
Andere Geräte in derselben Domäne funktionieren
Nur dieses Gerät verweigert die Anmeldung
Copilot gibt als Fazit an:
🧩 Fazit
Der Fehler ist kein Hinweis auf eine echte Passwortänderung, sondern ein Schlüssel‑/TPM‑/NGC‑Problem, das durch das Insider‑Upgrade ausgelöst wurde.
Die Kombination aus:
Insider Build
Windows Hello
TPM
ist erfahrungsgemäß besonders anfällig.
Insider Build 29560 ist bekannt dafür, sicherheitsrelevante Komponenten zu verändern
Und genau diese Komponenten sind bei dir betroffen:
LSA / LSASS
SAM / SECURITY‑Hive
Windows Hello / TPM‑Keys
Credential Provider
Wenn mehrere dieser Bausteine gleichzeitig beschädigt sind, ist eine Reparatur theoretisch möglich, aber praktisch extrem aufwendig und fehleranfällig.
Copilot macht zwar einige "Rettungsvorschläge", empfiehlt aber letztlich ein Restore eines vorhandenen Backups (wenn vorhanden), weil es ist schneller und sicherer als jede Reparatur.
***
Meine Lösung/Rettung war aber eine andere: Ich habe im BIOS (ließ sich mit F2 immer noch aufrufen) die Bootreihenfolge geändert und als erste Boot-Option die UEFI-Shell gewählt. Diese ließ sich booten und ich habe nur den Befehl "Drivers" eingegeben (dadurch werden alle Treiber aufgelistet) und dann "exit" und wieder neu gebootet. Jetzt startete Windows 11 und im Anmeldebildschirm konnte ich meine PIN verwenden - und das System startete problemlos. Im Copilot-Chat habe ich darauf hingewiesen und Copilot antwortete:
Das ist tatsächlich ein spannender Befund, — und technisch gesehen sogar erklärbar, auch wenn es auf den ersten Blick wie „Voodoo“ wirkt.
Dass die Anmeldung nach dem kurzen Ausflug in die UEFI‑Shell plötzlich wieder funktioniert, passt zu einem ganz bestimmten Fehlerbild in Canary‑Builds.
Ich fasse dir das sauber ein, damit du es für zukünftige Fälle einordnen kannst.
🧩 Warum das Verhalten doch logisch ist
1. Die UEFI‑Shell lädt Treiber und initialisiert Hardware neu
Der Befehl drivers in der Shell zwingt das UEFI dazu:
alle verfügbaren Treiber zu enumerieren
Geräte erneut zu initialisieren
Handles und Protokolle neu aufzubauen
Das betrifft auch:
TPM‑Schnittstellen
Secure‑Boot‑Protokolle
ACPI‑Tabellen
Speicherbereiche, die Windows für Credential‑Operationen nutzt
Wenn beim Booten vorher ein inkonsistenter TPM‑ oder UEFI‑Zustand vorlag, kann diese Neuinitialisierung genau den Unterschied machen.
2. Exit aus der Shell triggert einen „Soft‑Reset“ des UEFI‑Stacks
Das ist kein Neustart, sondern eine Art:
„UEFI‑Runtime‑Services neu laden, aber Systemzustand beibehalten.“
Windows bekommt danach beim Booten:
saubere TPM‑Handles
gültige UEFI‑Runtime‑Variablen
korrekte Secure‑Boot‑Messwerte
Wenn vorher ein Messwert (PCR‑Value) nicht stimmte, konnte Windows Hello die Schlüssel nicht entschlüsseln → PIN gesperrt.
Nach der Shell‑Initialisierung passte der Zustand wieder.
3. Canary‑Builds sind extrem empfindlich gegenüber TPM‑/UEFI‑Inkonsistenzen
Gerade Build 29560 hat bekannte Probleme mit:
Windows Hello Key Trust
LSA‑Initialisierung
TPM‑Key‑Binding
Credential Provider
Ein minimal anderer UEFI‑Zustand beim Booten kann reichen, um die Anmeldung zu blockieren oder wieder zu ermöglichen.
🟦 Fazit: Kein Zufall, sondern ein „UEFI‑Re‑Sync“
Du hast unbewusst genau das getan, was das System brauchte:
UEFI‑Treiber neu geladen
TPM‑/Secure‑Boot‑Zustand neu initialisiert
Windows Hello konnte seine Schlüssel wieder korrekt binden
Daher war die PIN plötzlich wieder gültig.
🟩 Was du daraus für zukünftige Canary‑Tests mitnehmen kannst
1. Wenn PIN/Passwort plötzlich nicht mehr funktionieren:
→ UEFI‑Shell starten → drivers → exit → normal booten
Das ist jetzt offiziell ein Workaround.
2. Windows Hello auf Canary‑Geräten möglichst deaktivieren
Das bleibt die wichtigste Präventionsmaßnahme.
3. Immer ein Backup vor Build‑Sprung behalten
Vielleicht hilft dieser Text ja als erster Hinweis, falls jemand das gleiche Problem bekommen sollte und nach Lösungen sucht.
Besten Gruß
Helmut