Windows Server 2025: TPM-Gerätezugriff schlägt nach Sicherheitsupdate mit undokumentiertem Fehler 0x80284018 fehl

Dienst

Windows Server 2025 Standard, TPM 2.0 (Trusted Platform Module), TBS (TPM Base Services). Virtualisierte Umgebung (QEMU/Proxmox mit emulierten TPM 2.0-Gerät über swtpm).

Szenario

Nach der Installation eines monatlichen kumulativen Sicherheitsupdates auf einem bereits laufenden, produktiven Windows Server 2025 hört das TPM auf zu funktionieren. Der Geräte-Manager zeigt das TPM ("Trusted Platform Module 2.0", ACPI\MSFT0101) weiterhin als fehlerfrei an, der Treiber tpm.sys 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 u. a. die Anmeldung bei Microsoft Office auf den betroffenen Servern.

Das Problem tritt seit KB5065426 (September 2025) reproduzierbar mit jedem folgenden monatlichen Sicherheitsupdate erneut auf, sobald dieses auf ein bereits bestehendes System installiert wird. Eine frische Windows Server 2025-Installation auf demselben aktuellen Patchstand ist nicht betroffen – das Problem hängt also am Vorgang der Aktualisierung eines bestehenden Systems, nicht am fertigen Update-Inhalt selbst.

Ergebnis

Direkter Aufruf von Tbsi_Context_Create (tbs.dll) sowie ein reiner Win32-Aufruf CreateFile("\.\TPM", ...), der tbs.dll vollständig umgeht, liefern beide denselben Fehler:

0x80284018

Dieser Code ist in Microsofts öffentlicher TBS-Rückgabecode-Dokumentation (learn.microsoft.com/windows/win32/tbs/tbs-return-codes) nicht enthalten; diese endet bei 0x80284016 (TBS_E_PROVISIONING_INCOMPLETE). Da der Fehler bereits bei einem reinen CreateFile-Aufruf auf das Gerät auftritt, liegt die Ursache im Create-Handler (IRP_MJ_CREATE) von tpm.sys selbst, nicht in TBS' Client-Bibliothek.

tpmtool getdeviceinformation liefert entsprechend: 0x800710df (ERROR_DEVICE_NOT_AVAILABLE).

Umgebung

• Windows Server 2025 Standard, Volume-Lizenz
• Virtualisiert unter Proxmox VE (QEMU), TPM 2.0 über swtpm emuliert (tpm-tis-Schnittstelle)
• Betroffen: mehrere produktive Remote Desktop Session Host (RDS)-Server
• Erstmals aufgetreten mit KB5065426 (September 2025), seither mit jedem monatlichen kumulativen Update reproduzierbar

Problembehandlung

Bereits ohne Erfolg versucht:

• sfc /scannow und DISM /RestoreHealth (unabhängige, nicht TPM-bezogene Beschädigungen gefunden, TPM dadurch nicht behoben)
• Vollständige Reparaturinstallation vor Ort (setup.exe /auto upgrade) – erfolgreich abgeschlossen, TPM danach weiterhin defekt
• Vollständig neu erstellte TPM-State-Disk (vTPM-NVRAM) sowie neu erstellte EFI-Variablen – keine Änderung
• Migration der virtuellen Maschine auf einen anderen physischen Host – keine Änderung
• Geräte-Neuinstallation über pnputil (entfernen + neu suchen) – keine Änderung
• Austausch der aktiven tpm.sys-Treiberdatei gegen eine bytegleiche, gültig signierte Datei einer funktionierenden Referenzmaschine (über MoveFileEx mit MOVEFILE_DELAY_UNTIL_REBOOT, nach Neustart als geladen und RUNNING bestätigt) – keine Änderung. Damit ist die Treiberdatei selbst als Ursache ausgeschlossen.

Zusätzlich per Live-Protokollmitschnitt (strace) auf dem Hypervisor bestätigt: Das virtuelle TPM-Backend beantwortet TPM2-Befehle (PCR-Extends, GetCapability, Schlüsseloperationen) zum exakt selben Zeitpunkt korrekt, an dem Get-Tpm das TPM als abwesend meldet. Die zugrunde liegende Hardware-/Hypervisor-Ebene funktioniert also nachweislich.

Unterstützende Materialien

Vollständige Diagnosedaten (Ereignisprotokolle, Registry-Exporte, Protokoll-Traces, das genaue Reproduktionsskript) liegen vor und werden auf Anfrage gerne bereitgestellt.

Reproduzierbare Schritte

Add-Type @"
using System;
using System.Runtime.InteropServices;
public class DevOpen {
    [DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Auto)]
    public static extern IntPtr CreateFile(string lpFileName, uint dwDesiredAccess, uint dwShareMode,
        IntPtr lpSecurityAttributes, uint dwCreationDisposition, uint dwFlagsAndAttributes, IntPtr hTemplateFile);
}
"@
[uint32]$access = [Convert]::ToUInt32("80000000", 16)
$h = [DevOpen]::CreateFile("\\.\TPM", $access, 3, [IntPtr]::Zero, 3, 0, [IntPtr]::Zero)
if ($h -eq [IntPtr]::Zero -or $h.ToInt64() -eq -1) {
    "FEHLER: 0x{0:X8}" -f [System.Runtime.InteropServices.Marshal]::GetLastWin32Error()
} else {
    "Erfolgreich, Handle: $h"
}

Auf einem betroffenen Server liefert dieses Skript den Fehler 0x80284018; auf einem nicht betroffenen Server einen gültigen Handle.

Konkrete Frage

1. Was bedeutet der TBS-Rückgabecode 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 überlebt eine vollständige Reparaturinstallation und sollte als nächstes untersucht werden?
3. Gibt es einen unterstützten Weg, tpm.sys/TBS zu einer vollständigen Neu-Bereitstellung aus sauberem Zustand zu zwingen, ohne komplette Neuinstallation des Betriebssystems? Eine Neuinstallation ist für uns keine Option, da mehrere produktive Server betroffen sind und wir aus Compliance-Gründen weiterhin monatliche Sicherheitsupdates einspielen müssen.