Ja, klappt immer noch nicht, wie erhofft. Die dbupdate.bin ist immer noch inhaltslos.

Bin gerade am überlegen, ob man die nicht von einer älteren ISO nehmen kann. Oder war die schon immer leer? Kann aber eigentlich nicht sein.

Auch nach dem gestrigen Patchday-Update wird mir weiterhin der Fehler TPM-WMI 1801 im Event Viewer ausgegeben. Die relevanten Registry-Keys stehen weiterhin auf not started und 2.

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 :D

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...

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.

[quote=DK2000 post_id=451279 time=1762368412 user_id=39966]

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

[/quote]

Na schau an, funzt, danke erstmal dafür.
[attachment=0]1.png[/attachment]

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?

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.

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

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

Das ist jetzt lustig.

Der Wert hier in Registry
[code]HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot\AvailableUpdates 0x100[/code]
stand noch nach wie vor in der Registry. Jetzt habe ich nochmal den Befehl
[code]Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"[/code]
gestartet und ohne Reboot steht jetzt das im Ereignisprotokoll als auch in der Registry.

Meldung 1 (1801 Fehler, sehr merkwürdig)
[attachment=2]1.png[/attachment]
Meldung 2 (ohne jeglichen Neustart)
[attachment=1]2.png[/attachment]
und in der Registry das
[attachment=0]3.png[/attachment]

Sehr strange...

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/topic/how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d

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.

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

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

Kommt das:
[attachment=1]Screenshot 2025-11-05 190859.png[/attachment]
[attachment=2]Screenshot 2025-11-05 190859.png[/attachment]

BRB

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

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

Ja, Die fehlt noch der Boot Manager:

[code]reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x100 /f[/code]
[code]Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"[/code]

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.

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

Also,

ich habe diesen Thread lange verfolgt und selber rumgemacht aber immer kam ein False. Jetzt bin ich einen großen Schritt weiter.
[code][System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI kek).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'[/code] 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:

[quote]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.[/quote]

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.[attachment=0]Screenshot 2025-11-05 185326.png[/attachment][attachment=1]Screenshot 2025-11-05 185253.png[/attachment][attachment=2]Screenshot 2025-11-05 185221.png[/attachment]

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.

@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.