Nach Upgrade auf Insider Build 29560 Anmeldung mit PIN und/oder Kennwort nicht mehr möglich

Antwort erstellen


Diese Frage dient dazu, das automatisierte Versenden von Formularen durch Spam-Bots zu verhindern.
Smileys
:) ;) :smile: :lol: :hihi: :D :rofl: :muahah: :( :pff: :kopfstreichel: :ohno: :betruebt: :heulen: :kopfkratz: :duckundweg: :o :? :oops: :psst: :sauer: :-P :daumenrunter: :daumen: :dankeschoen: :thx: :dafür: :gähn:
Mehr Smileys anzeigen

BBCode ist eingeschaltet
[img] ist eingeschaltet
[flash] ist ausgeschaltet
[url] ist eingeschaltet
Smileys sind eingeschaltet

Die letzten Beiträge des Themas

Ich habe die Datenschutzerklärung gelesen und bin damit einverstanden.

   

Ansicht erweitern Die letzten Beiträge des Themas: Nach Upgrade auf Insider Build 29560 Anmeldung mit PIN und/oder Kennwort nicht mehr möglich

Nach Upgrade auf Insider Build 29560 Anmeldung mit PIN und/oder Kennwort nicht mehr möglich

von HCT » 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

Nach oben