Windows Server 2025: TPM wird nach jedem monatlichen Sicherheitsupdate dauerhaft unbrauchbar (seit KB5065426) — tpm.sys selbst gibt beim Öffnen des Geräts den undokumentierten Fehler 0x80284018 zurück

Das Problem

Auf unseren Windows Server 2025 RDS-Servern hört das TPM nach der Installation jedes monatlichen kumulativen Sicherheitsupdates auf zu funktionieren. Das tritt seit KB5065426 (September 2025) jeden Monat erneut auf — mittlerweile seit etwa einem Jahr. Der Geräte-Manager zeigt das TPM ("Trusted Platform Module 2.0", ACPI\MSFT0101) weiterhin als fehlerfrei an, und der tpm.sys-Treiber bleibt im Status RUNNING — aber Get-Tpm, tpmtool und die WMI-Klasse Win32_Tpm melden das TPM übereinstimmend als vollständig nicht vorhanden. Das blockiert die Benutzeranmeldung bei Microsoft Office auf den betroffenen Servern, wodurch wir überhaupt erst darauf aufmerksam wurden.

Eine frische Windows Server 2025-Installation auf demselben aktuellen Patchstand funktioniert einwandfrei — das Problem wird also gezielt durch die Installation eines Updates auf ein bereits laufendes System ausgelöst, nicht durch den fertigen Inhalt des Updates selbst.

Wir haben keinen Microsoft-Supportvertrag und versuchen deshalb, hier im Forum Hilfe zu bekommen. Im Folgenden alles, was wir bisher herausgefunden haben.

Umgebung

Windows Server 2025 Standard, virtualisiert (QEMU/Proxmox mit einem emulierten TPM 2.0-Gerät über swtpm, als tpm-tis eingebunden).

Der präziseste Befund: ein undokumentierter TBS-Fehlercode

Der direkte Aufruf der Funktion Tbsi_Context_Create aus tbs.dll (unter Umgehung von Get-Tpm/WMI) liefert auf betroffenen Maschinen den Fehler 0x80284018, auf einer bekanntermaßen funktionierenden Referenzmaschine hingegen TBS_SUCCESS (0x0). 0x80284018 taucht in Microsofts öffentlicher TBS-Rückgabecode-Dokumentation nicht auf (learn.microsoft.com/windows/win32/tbs/tbs-return-codes), die nur Codes bis 0x80284016 (TBS_E_PROVISIONING_INCOMPLETE) auflistet.

Wir sind noch eine Ebene tiefer gegangen und haben tbs.dll komplett umgangen, indem wir das rohe Gerät direkt mit dem Win32-Aufruf CreateFile("\.\TPM", ...) geöffnet haben. Gleiches Ergebnis: Schlägt auf der betroffenen Maschine mit demselben 0x80284018 fehl, liefert auf der funktionierenden Maschine einen gültigen Handle. Das bedeutet, der Fehler liegt gar nicht in TBS' Client-Bibliothek — es ist der Create-Handler (IRP_MJ_CREATE) von tpm.sys selbst, der das Öffnen verweigert, noch bevor überhaupt TBS-Logik ausgeführt wird.

Bewiesen: kein Hardware-/Hypervisor-Problem

Wir haben während des Boot-Vorgangs und einer aktiven, angemeldeten Sitzung einen Live-Trace des virtuellen TPM-Backends aufgezeichnet (strace auf dem swtpm-Prozess). Er zeigt vollständig erfolgreichen TPM2-Protokollverkehr — PCR-Extends, eine GetCapability-Antwort mit korrekter Herstellerkennung sowie RSA-2048-große Antworten für Schlüsseloperationen — und das durchgehend, genau zu dem Zeitpunkt, an dem Get-Tpm das TPM als vollständig abwesend meldete. Das TPM selbst funktioniert nachweislich einwandfrei; irgendetwas in Windows kann oder will nur nicht über den normalen Weg mit ihm kommunizieren.

Bewiesen: nicht die Treiberdatei/der Code

Wir haben das aktive tpm.sys durch die bytegleiche, gültig von Microsoft signierte Datei der funktionierenden Referenzmaschine ersetzt (über denselben "delayed rename on reboot"-Mechanismus, den auch Installationsprogramme zum Ersetzen aktiv verwendeter Systemdateien nutzen), nach dem Neustart bestätigt, dass die ersetzte Datei tatsächlich geladen war und lief (STATE: RUNNING) — und der Fehler blieb komplett unverändert. Das schließt den Treibercode selbst als Ursache aus.

Unabhängiger, bestätigender Befund

Unter HKLM:\SYSTEM\CurrentControlSet\Services\TPM\WMI findet sich ein gespeicherter Wert AIKEnrollmentErrorCode (Attestation Identity Key-Registrierung, eine verwandte, aber eigenständige Windows-Komponente) von 0x80090011 (NTE_NOT_FOUND — "der kryptografische Schlüsselcontainer wurde nicht gefunden") auf der betroffenen Maschine, gegenüber einem harmlosen Netzwerk-Timeout-Code auf der funktionierenden Maschine. Das deutet über einen völlig anderen Codepfad auf dieselbe zugrunde liegende Schlussfolgerung hin: Ein lokal gespeicherter TPM-bezogener Schlüssel/Objektverweis fehlt oder kann nicht aufgelöst werden.

Was wir bereits ausgeschlossen bzw. ohne Erfolg versucht haben

• sfc /scannow und DISM /RestoreHealth (fanden nicht verwandte Beschädigungen, TPM dadurch nicht behoben)
• Eine vollständige Reparaturinstallation vor Ort (setup.exe /auto upgrade) — erfolgreich abgeschlossen, TPM danach weiterhin defekt
• Eine echte Windows-Update-Installation auf einen neueren Build — keine Änderung
• Komplett neu erstellte tpmstate0-Disk (vTPM-Zustand) — keine Änderung
• Komplett neu erstellte EFI-Variablen-Disk — keine Änderung
• Migration der VM auf einen anderen physischen Host — keine Änderung
• Geräte-Neuinstallation über pnputil (entfernen + neu suchen) — keine Änderung
• TBS-Dienst fehlt in sc query/Registry — dies ist nachweislich normal/erwartet, selbst auf der funktionierenden Referenzmaschine, also nicht die Ursache

Was wir brauchen

1. Was bedeutet TBS_RESULT 0x80284018, und welchen internen Zustand prüft der Create-Handler von tpm.sys, der zu diesem Rückgabewert führt?
2. Da die Treiberdatei selbst nachweislich nicht die Ursache ist — welcher persistierte Zustand (Registry-Schlüssel, NVRAM-Objekt oder Ähnliches) sollte untersucht werden, der eine vollständige Reparaturinstallation übersteht?
3. Gibt es einen unterstützten Weg, tpm.sys/TBS zu einer vollständigen Neu-Bereitstellung aus einem sauberen Zustand zu zwingen, ohne eine komplette Neuinstallation des Betriebssystems (die für uns keine Option ist — wir haben mehrere betroffene Produktivserver)?

Wir stellen gerne weitere Diagnosedaten zur Verfügung — wir haben aus dieser Untersuchung umfangreiche Protokolle (Ereignisprotokolle, Registry-Exporte, Protokoll-Traces usw.).