TPM-WMI Fehler 1801

[jvc]

Guten morgen,
ich habe Windows 11 neu installiert mit einer ISO von deskmodder. Windows 11 25H2 26200.7015.
Notebook HP 250 G8
Soweit alles o.k., allerdings taucht in der Ereignisanzeige ca, alle 12 Minuten folgender Fehler auf:
TPM-WMI Fehler 1801
Secure Boot CA/keys need to be updated. This device signature information is included here.
DeviceAttributes: FirmwareManufacturer:Insyde;FirmwareVersion:F.69;OEMModelBaseBoard:85F5;OEMManufacturerName:HP;OSArchitecture:amd64;
Kann mir bitte jemand erklären was ich dagegen unternehmen kann?

Vorab herzlichen Dank,
jvc

[Tante Google]

[DK2000]

Den Fehler bekomme ich da auch nicht so wirklich in dern Griff. In der einen Windows 11 hat das geklappt, in der andern nicht. In Windows 10 fehlt eine Datei und kann deswegen den Bootmanager nicht aktualisieren, seltsamerweise, in der Dev gibt es eine Zugriffsverletzung (0xc0000005). Keine Ahnung, was Microsoft da vergeigt hat oder was der Grund dafür ist. Eventuell sperrt sich auch das UEFI vor dem Update. Kommt auch vor.

Bei mir in Windows 10 /11 trägt das LCU z.B. das ein:

Code: Alles auswählen

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot]
"AvailableUpdates"=dword:00000402

Aber damit kann der Updater wohl nichts anfangen und kommt mit dem 1801. Keine Ahnung, was er da aktualisieren will. Auf jeden Fall startet er nicht das Update.

Im Moment ignoriere ich das wieder. Ich finde da im Moment keine allgemein gültige Lösung für. Nur in der einen Windows 25H2 VM lief das Update mit "AvailableUpdates"=dword:00005944 komplett durch. Warum, weiß ich selber nicht. Vor einer Weile gab es da noch nicht solche Probleme.

[moinmoin]

Hab mal bei mir nachgeschaut. Da geistert der Fehler seit dem 15.10. in der Ereignisanzeige.
Also nach dem Sicherheitspatch Oktober.

Aber solange nichts im Zuverlässigkeitsverlauf steht, ignoriere ich solche Dinge

[DK2000]

Ja, das kann sein. Da fingen wohl diese seltsamen Probleme an. Aber keine Ahnung, wie man das allgemein lösen soll. Betrifft ja Windows 10 22H2 (vermutlich auch 21H2) und 11 24H2/24H2.

Aber im Moment stört das nicht weiter und hoffentlich hat die Sperre für die DBX keinen Bug. Sonst könnte das Problematisch werden, wenn man ein Gerät hat, bei welchem man SecureBoot nicht abschalten kann. Mal auf das nächste Sicherheitsupdate abwarten.

Und Zuverlässigkeitsverlauf ist da relativ. Gibt hat dort keinen Filter für die TPM-WMI Fehler. Daher erscheinen die dort nicht. Ist die Frage, ob Microsoft die Fehler dort überhaupt mal aufnimmt.

[Holgi]

sind BIOS/UEFI Firmware und Treiber alle auf dem neuesten Stand?

https://support.hp.com/de-de/product/de ... c/38151396

[jvc]

Bei mir steht unter
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot]
"AvailableUpdates"=dword:000000

Sollte ich da testweise einen der beiden Werte eintragen?

[jvc]

Ich habe auf elevenforum folgendes gefunden und getestet.

In Powershell-Admin folgendes eingeben:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "AvailableUpdates" -Value 0x40
und
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

Prüfen mit (Powershell-Admin)
[System.Text.Encoding]::ASCII. GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
Antwort muß 'True' sein.
2x Neustart
Bei mir ist die Antwort jetzt 'True', war vorher 'False'. Aber die Warnung in der Ereignisanzeige bleibt bestehen.
Scheint wohl nur durch ein Update zu beheben sein.

Bis dann,
jvc

[moinmoin]

Sieht so aus, ja.

[DK2000]

Das aktualisiere nur das eine Zertifikat:

0x0040 = Windows UEFI CA 2023
0x0800 = Microsoft UEFI CA 2023
0x1000 = Microsoft Option ROM CA 2023
0x0100 = Wenden Sie den von der Windows UEFI-Zertifizierungsstelle 2023 signierten Boot-Manager auf die Boot-Partition an.
0x0004 = Microsoft Corporation KEK 2K CA 2023 (Geräteabhängig)

0x4000 = Dieses Bit ändert das Verhalten der 0x0800 und 0x1000 Bits so, dass nur die Microsoft UEFI CA 2023 und die Microsoft Option ROM CA 2023 angewendet werden, wenn die Datenbank bereits über die Microsoft Corporation UEFI CA 2011 verfügt.

0x5499 fast das alles zusammen.

Problem dürfte hier nur der KEK sein, da dieser mit dem PK vom Gerätehersteller signiert sein muss und zum verwendeten Gerät/Board passen muss. Der PK wird von Gerätehersteller verwaltet. Wenn dieser kein KEK liefert, dann sitz man auf dem Trockenen. Mit VirtualBox hatte ich da keine Probleme, da ein passend signiertes Zertifikat bereits in dessen UEFI integriert ist.

Wie gesagt, bei mir hat das alles nur in der einen Windows 11 25H2 geklappt. Hier ist der 1801 weg.

Screenshot 2025-10-25 195224.png

Aber warum, weiß ich selber nicht. Mit Windows 10 22H2 und Windows 11 24H2 klappt das nicht.

[Tinka]

Ich komme hier einfach nicht weiter.
Ich habe das Updaten mit 0x5944 jetzt auf drei Rechnern erfolgreich hinbekommen. Aber auf dem vierten klappt es einfach nicht. BIOS und Windows sind up to date.
Die Einträge bei den relevanten Registry Keys sind „not started“ und „2“. Das passt ja irgendwie gar nicht zusammen. Setze ich dann den Registry Key für Available Updates auf 0x5944 und starte die entsprechende Aufgabe endet die Task mit dem Fehler 0xC0000005 Auch wenn ich dann nochmal neu starte, hilft das nichts. Setze ich zurück auf die Ursprungseinstellung 0x0 kann die Task aber erfolgreich ausgeführt werden und der TMP-WMI 1801 Fehler wird angezeigt. Aber das updated natürlich nicht die Zertifikate. Es bleibt also alles bei not started und 2.
Checke ich über die PowerShell [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023' wird mir true ausgegeben.
Irgendeine Idee, wie ich das auch auf dem vierten Rechner hinbekomme? Oder kann ich da nur noch auf Microsoft warten?

[DK2000]

Das habe ich da im Moment aufgegeben. Ich kann da das Problem vom Updater nicht weiter identifizieren. Aus irgendwelchen Gründen kommt bei mir, je nach Installation, meistens 0x80070002 (Datei nicht gefunden) oder in der Dev 0xC0000005 (Zugriffsverletzung. Nach dem letzten Update in der Dev kommt jetzt allerdings auch 0x80070002. Aber welche Datei da nicht gefunden wird, kann ich nicht ermitteln. Selbst die ursprüngliche Anleitung funktioniert nicht mehr:

https://support.microsoft.com/de-de/top ... ff139f832d

Scheitert schon am Schritt 1.1 (Installieren Sie die aktualisierten Zertifikatdefinitionen in der Datenbank). Das scheitert mit 0x80070002. Ich kann also das Zertifikat "Windows UEFI CA 2023" derzeit nicht installieren. Hat aber schon einmal alles wunderbar geklappt. Warum das jetzt auf einmal nicht mehr geht, kann ich nicht sagen. Und warum es in der einen 25H2 Installation geklappt hat, weiß ich auch nicht. Alles sehr seltsam.

Und seit dem letzten Update für die 25H2 (26200.7019) gibt es auch eine weitere Meldung in der Ereignisanzeige:

Code: Alles auswählen

Quelle: TPM-WMI
Ereignis: 1040
Integritätsprüfungen vor dem Nachweis bestätigen, dass eine kritische Komponente
fehlgeschlagen ist und dass das Gerät nicht den Nachweis bestehen soll.

Was das TPM-WMI mir jetzt damit noch mitteilen möchte, weiß ich auch noch nicht. Im Moment nicht weiter mit beschäftigt. Ich warte jetzt erst einmal das nächste Sicherheitsupdate am 11.11. ab und dann mal weiter schauen.

[Tinka]

Also ist das nichts Bedenkliches und man soll erst einmal abwarten?

[ticket]

Ich bin folgendermaßen vorgegangen (Stand:25H2 6901):

Zunächst prüft man als Administrator im Terminal mit:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
den Istzustand. True oder False.

Bei False öffnet man den Taskmanager und überprüft, ob der Task
"C:\Windows\System32\Tasks\Microsoft\Windows\PI\Secure-Boot-Update"
auch aktiviert ist.

Dann in der Registrierdatenbank unter [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot] der ggf. vorhandene Schlüssel:
"AvailableUpdates"=dword:00000000
in z.B.:
"AvailableUpdatesOriginal"=dword:00000000
umbenennen.

Jetzt wieder im Terminal als Administrator:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "AvailableUpdates" -Value 0x40

Programme schließen und neu starten.

Nach dem Neustart wieder als Administrator im Terminal:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'

Jetzt sollte True ausgegeben werden.

Abschließend in der Registrierdatenbank die zuvor umbenannte Zeile:
"AvailableUpdatesOriginal"=dword:00000000
löschen.

Die beiden bunten Terminalbefehlszeilen sind von der Microsoft-Webside.
Diese kann man sich dann aus:
"C:\Users\[Username]\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt"
herausfischen und für weiteren Gebrauch extern abspeichern.

[Tinka]

Wenn ich das in der PowerShell abfrage [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023' steht bei mir schon True.
Das ist ja nicht das Problem.
Bei mir passen die Einträge unter Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing noch nicht.
Das steht bei UEFICA2023Status NotStarted und da sollte eigentlich Updated stehen.
Und bei WindowsUEFICA2023Capable 2 (das passt).
Da ist die Frage wie ich die erste Variableauf Updated bekomme oder ob das Microsoft mit der Zeit einfach selbst umstellt?

[DK2000]

@ticket:

Wie ich schon schrieb, das endet in der Testinstallation derzeit nur mit UEFICA2023Error=0x8007002 und in der Ereignisanzeige passen dazu steht dann:

TPM-WMI 1796: Beim Update für den sicheren Start konnte eine Variable für den sicheren Start nicht aktualisiert werden. Fehler: Das System kann die angegebene Datei nicht finden.

Hat aber schon einmal funktioniert. Aber aktuell halt nicht mehr. Ich vermute fast, das hängt in dem Fall mit der leeren dbupdate.bin zusammen.

Ich kann also das Zertifikat nicht (mehr) installieren.

@Tinka

Geht ja nicht nur um das 'Windows UEFI CA 2023' sondern auch um den Rest:

AvailableUpdates=0x0800 -> 'Microsoft UEFI CA 2023'
AvailableUpdates=0x1000 -> 'Microsoft Option ROM UEFI CA 2023'

AvailableUpdates=0x0004 -> 'Microsoft Corporation KEK 2K CA 2023'

Da bei Dir WindowsUEFICA2023Capable=2 steht, bedeutet, dass das "Windows UEFI CA 2023" installiert wurde und dass der Bootmanager aktualisiert wurde. Aber was mit dem Rest ist, geht daraus nicht hervor. Und wenn der Updater bei Dir mit 0xC0000005 (Zugriffsverletzung) kommt, dann passt da so oder so etwas nicht.