TPM-WMI Fehler 1801

[Tinka]

@DK2000
Aber was ist die Konsequenz daraus?
Setze ich den Key auf 0x5944 dann endet die Task mit 0xC0000005.
0x40 und 0x100 einzeln gingen - so bin ich ja dann wenigstens da hin gekommen, wo ich jetzt bin.
Soll ich das dann erst einmal so lassen?
Ist damit zu rechnen, dass Microsoft dann bei irgendeinem Patchday-Update alles schön macht? Oder ist bei mir was kaputt?
Nachdem das auf den drei anderen Rechnern problemlos geklappt hat, dachte ich, dass ich es auf dem vierten auch direkt chic mache, um nicht mehr warten zu müssen. Aber wie beschrieben, klappt das eben scheinbar nicht.

[Tante Google]

[DK2000]

Ist halt die Frage, wo genau intern der 0xC0000005 kommt. Das lässt sich wohl nicht ermitteln. 0x5944 fast ja nur die weiter oben genannten Aufgaben zusammen. Die kann man auch alle einzeln ausführen.

Bei 0x40 und 0x100 ist nach Ausführen des Tasks AvailableUpdates auf 0 zurückgesprungen?

Und was passiert bei AvailableUpdates=0x0004? Ließ sich KEK auch installieren oder gibt es da noch nichts? Kann man analog zu den anderen Zertifikaten prüfen. Man muss nur die Variable von db in kek ändern und den Text:

Code: Alles auswählen

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'

Da sollte dann auch "True" stehen. Aber das Zertifikat muss vom OEM passend vom Geräteherstelle kommen. Microsoft fasst diese Zertifikate für die einzelnen Hersteller in der "KEKUpdateCombined.bin" zusammen. Das passende Zertifikat wird automatisch gewählt und installiert.

Kaputt ist bei Dir wohl nichts, eher andere Probleme. Aber schwer zu sagen, was es sein könnte. Und solange Du im UEFI Secure Boot deaktivieren kannst, bist Du dann auf der sicheren Seite.

Aber die Frage stelle ich mir da auch, warum es bei der einen Installation komplett geklappt hat und bei der Test-Installation jetzt schon bei 0x40 scheitert, obwohl es schonmal funktioniert hat. In Windows 10 scheitert es mit 0x100 (Boot Manager aktualisieren).

Und ein Update ist wohl im kommen. Der User Xeno auf X hat geschrieben, dass er über das WU "Secure Boot Allowed Signature Database (DB) Update" erhalten. Eventuell löst das diverse Probleme. Bei mir ist da allerdings noch nicht gekommen. Muss man im Moment einfach nur abwarten.

[Tinka]

@DK2000
Bei 0x40 und 0x100 ist nach Ausführen des Tasks AvailableUpdates auf 0 zurückgesprungen? - Ja.
Und was passiert bei AvailableUpdates=0x0004? - Das habe ich nicht probiert.
Wenn ich das über PowerShell abfrage steht da noch False auf dem Rechner wo 0x5944 nicht funktioniert. Wahrscheinlich hakt es dann da.
So wie Du es beschreibst muss sich das dann ja irgendwie von selbst lösen oder der Hersteller muss mit einem erneuten BIOS Update nacharbeiten.
Ich will da jetzt auch nicht ständig irgendetwas ausprobieren. Am Ende mache ich wirklich noch etwas kaputt.

[DK2000]

Ich warte einfach ab. Die Fehler kann ich selber wohl nicht beheben.

ja, kann sein, dass für das eine Gerät ein UEFI-Update erforderlich ist.

[Purgatory]

Also,

ich habe diesen Thread lange verfolgt und selber rumgemacht aber immer kam ein False. Jetzt bin ich einen großen Schritt weiter.

Code: Alles auswählen

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'

gibt ein True aus und der Schlüssel "WindowsUEFICA2023Capable" gibt ein "in Progress" aus.

Ich bin, vor ca. einer Stunde, auf ein neues UEFI geswitcht, von F38 auf F39 (das lange in der Beta war). In diesem BIOS ist eine AGESA die Vulnerables bei AMD Prozessoren fixt. Mainboard siehe Signatur. Und prompt verhält sich dieses Szenario komplett anders. MS schreibt ja selber:

Firmwareprobleme: Nicht alle Gerätefirmware aktualisiert DB oder DBX für den sicheren Start erfolgreich. In den Fällen, die uns bekannt sind, haben wir das Problem dem Gerätehersteller gemeldet. Ausführliche Informationen zu protokollierten Ereignissen finden Sie unter KB5016061: Ereignisse beim Aktualisieren von DB- und DBX-Variablen für den sicheren Start. Wenden Sie sich für Firmwareupdates an den Gerätehersteller. Wenn das Gerät nicht unterstützt wird, empfiehlt Microsoft ein Upgrade des Geräts.

Jetzt muss ich mal schauen wie das so weitergeht, ich habe nämlich einen neuen Fehler in dem Ereignisprotokoll (1798).
Wie es scheint müssen echt TPM Updates aka BIOS Updates von den Herstellern kommen. Meine Firmwareversion im UEFI ist auch gestiegen.

Screenshot 2025-11-05 185326.png

Screenshot 2025-11-05 185253.png

Screenshot 2025-11-05 185221.png

[DK2000]

Ja, Die fehlt noch der Boot Manager:

Code: Alles auswählen

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x100 /f

Code: Alles auswählen

Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

Wenn das geklappt hat, sollte zum. WindowsUEFICA2023Capable=2 schalten.

Klappt aber nur, wenn das "Windows UEFI CA 2023" installiert wurde. Aber das scheint derzeit nicht möglich zu sein, weil die dbupdate.bin keinen Inhalt hat.

Solange das nicht geschehen ist, kann DBX/DBX SVN nicht aktualisiert werden, weil das System dann nicht mehr bootbar wäre. Aber das habe ich manuell noch ausgelassen. Ist mir zu viel Aufwand mit den ISOs derzeit noch.

[Purgatory]

Kommt das:

Screenshot 2025-11-05 190859.png

Screenshot 2025-11-05 190859.png

BRB

[DK2000]

Da fehlt ein Neustart. (0x8070015e = No action was taken because a system reboot is required.)

[Purgatory]

Nach Neustart verhält sich die Registry gleich...

[DK2000]

Wie gesagt, irgendwas muss Microsoft da vergeigt haben. Denn die Anleitung hat ja bei mir schon einmal funktioniert, einschließlich DBX/DBX SVN. Jetzt scheitert das schon an Schritt 1.1 ("Windows UEFI CA 2023").

https://support.microsoft.com/en-us/top ... ff139f832d

Warum, ist mir nicht so ganz klar, aber vermute mal, es liegt an der dbupdate.bin. Nur finde ich da bei Microsoft keine brauchbare Datei. Ich habe da nur eine neue dbxupdate.bin gefunden.

[Purgatory]

Das ist jetzt lustig.

Der Wert hier in Registry

Code: Alles auswählen

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot\AvailableUpdates 0x100

stand noch nach wie vor in der Registry. Jetzt habe ich nochmal den Befehl

Code: Alles auswählen

Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

gestartet und ohne Reboot steht jetzt das im Ereignisprotokoll als auch in der Registry.

Meldung 1 (1801 Fehler, sehr merkwürdig)

1.png

Meldung 2 (ohne jeglichen Neustart)

2.png

und in der Registry das

3.png

Sehr strange...

[DK2000]

Gut, dann ist jetzt bei Dir "Windows UEFI CA 2023" installiert /war es wohl auch schon) und jetzt auch der neu signierte Bootmanager. Bis hier hin passt das jetzt.

Der Fehler 1801 verschwindet wohl erst, wenn man auch die anderen beiden Zertifikate noch installieren lässt:

0x0800 = Microsoft UEFI CA 2023
0x1000 = Microsoft Option ROM CA 2023

Müsste eigentlich gehen, wenn AvailableUpdates=0x1800 bzw. 0x5800 eingetragen wird. Oder halt beide der Reihe nach einzeln.

KEK ist ja schon und mehr gibt es da gerade nicht.

Ist auch immer interessant, was in AvailableUpdates noch drinsteht, wenn das Update ausgeführt wurde.

[Purgatory]

Der Fehler 1801 verschwindet wohl erst, wenn man auch die anderen beiden Zertifikate noch installieren lässt:

0x0800 = Microsoft UEFI CA 2023
0x1000 = Microsoft Option ROM CA 2023

Na schau an, funzt, danke erstmal dafür.

1.png

Allerdings muss ich sagen das funktioniert erst nach BIOS Update (und damit TPM) UND als ich Secure Boot von "System" auf "User" umstellte. Ich bin die Schritte nämlich auch vorher durch hab Secure Boot aber komplett so gelassen wie im BIOS eingestellt. Scheinbar darf Windows, zumindest auf meinem Mainboard hier, im "System" Mode nichts umschreiben.
Das ist viel zuviel Aufwand für Normaluser, da muss MS, und auch die Hersteller, dringend was machen.
Schluss oder endlich, ohne BIOS Update was die Firmware für das TPM mit einschließt, wird das nichts werden.
Ich sehe schwarz für ältere Systeme. Mein BIOS vorher war nur 1,5 Jahre alt und nichts ging.

Vor allem bin ich gespannt was passiert wenn man mal "Secure Boot" aus macht und dann wieder an macht. Wird das alles übernommen? Muss ich jetzt, nur für MS, diverse Profile im BIOS anlegen?

[DK2000]

Ah, hat also funktioniert. Der 1801 Fehler sollte jetzt weg sein.

Ja, das kann natürlich sein, wenn das UEFI Secure Boot im System-Modus läuft, dass dann keine neuen Zertifikate eingespielt werden können. Aber schon ein gewisser Aufwand für Benutzer.

Und Secure Boot kannst Du ein und ausschalten. Die Variablen werden nicht geändert. Das würde nur gehen, wenn das UEFI-Setup extra dafür eine Einstellung hat, wo man die Variablen manuell bearbeiten kann. Da könnte man dann auch wieder ein Zertifikat rauslösche oder eine Sperre zurücknehmen. Ansonsten bleibt alles so, wie es jetzt ist.

[Purgatory]

Ich habe sogar noch einen Modus mehr, den "Manual". Und der hat mir den Arsch gerettet was das Thema hier betrifft.
Ich habe, auch nach BIOS Update, die Schritte hier mehrmals wiederholt und ständig kam eine Fehlermeldung.
Dann bin ich auf "Manual" gegangen wo ich die Option habe Zertifikate zu löschen oder auch einzufügen. Und ich sah das unter DB- und DBX, also den Bootoptionen, eine 0 stand.
Also habe ich von "System" auf "User" geswitched und die Schritte nochmal wiederholt, und siehe da, die Zertifikate werden eingebunden. Das mag ein spezifisches "Gigabyte" Problem sein, aber mir hat es geholfen.

Schlussendlich weiß ich jetzt das ich diese Zertifikate auch vor dem BIOS Update hätte einbinden können, aber zum einen weiß ich nicht woher ich die bekomme und zum anderen... na ja, zu doof oder so

Helfen, für viele, wird wohl nur ein BIOS Update in dem das TPM Modul, bzw. die Sicherheitslücken der jeweiligen CPU, explizit aufgelistet werden. Wenn die jeweiligen Hersteller das eben zur Verfügung stellen...