Deskmodder.de

Hallo,

seitdem ich Ende September meinen PC (Fujitsu D3221-A12 mit Intel Core i5 4670) per ISO ein Upgrade auf 24H2 verpasst habe, startet er bei aktivem SecureBoot nicht mehr ohne weitere Handgriffe. Ohne SecureBoot läuft alles ganz normal. Aber bei aktivem SecureBoot wird konsequent die Windows-Partition übersprungen.
Sobald ich die bootmgfw.efi in der EFI-Partition durch die alte (archivierte) Version von 23H2 ersetze, funktioniert das Starten auch wieder mit SecureBoot - zumindest bis zum nächsten Update. Danach beginnt das Spiel wieder von Neuem...
In der DB sind das 2011er und das 2023er Zertifikat eingetragen und das Booten mit dem 24H2-Bootloader funktioniert mit beiden Signaturvarianten nicht.

Gibt es Ideen wie ich SecureBoot wieder dauerhaft zum Laufen bekomme?

Schöne Grüße
SPKirsch

Liest sich so, als wenn du das 2023er Zertifikat manuell aktiviert hast?

Ja, das habe ich einige Tage nach dem Upgrade erledigt. Ich dachte, das würde etwas an dem Problem ändern - hat es aber natülich nicht...

Damit hast du jetzt das Problem ausgelöst. Da wirst du so nicht mehr rauskommen, bis Microsoft es vollständig aktiviert, bzw. die ISOs dafür herausgibt

???
Das Problem bestand auch schon in den Tagen zwischen dem Upgrade von 23H2 auf 24H2 und der Aktivierung den 2023er-Zertifikats.
Und das 2011er-Zertifikat ist ja noch nicht in der DBX - sonst würde ja auch der transplantierte alte 23H2-Bootloader (definitiv noch mit dem 2011er-Zertifikat signiert) nicht mehr laufen.

Was hast Du denn von KB5025885 alles aktiviert?

Bei mir wurde nur das 2023 Zertifikat automatisch vom LCU in die DB eingetragen. Das 2011 Zertifikat aber nicht in die DBX und SVN ist auch nicht aktiviert. Die 24H2 läuft damit normal. Diese verwendet noch das 2011 Zertifikat, kann aber manuell auf 2023 umgestellt werden.

Nur Punkt 1: 2023-Zertifikat in die DB

Kann es sein, dass mein Mainboard bei aktiviertem SecureBoot ein generelles Problem mit dem 24H2- Bootloader hat?

Ich hab das gleiche Problem mit leicht anderen Rahmenbedingungen.
Bei mir ist es ein Fujitsu Esprimo Q920 (Board GS D3233-A13). Ich lande beim Starten mit aktiviertem Secure Boot immer im Fujitsu Diagnostic Program, als wäre kein bootfähiges Gerät vorhanden.

Ich hatte vor ein paar Tagen auf 24H2 geupgradet. Weil ich am gleichen Tag auch testweise eine Linux-Distribution auf einem anderen Laufwerk installiert hatte und das wieder rückgängig machen wollte, habe ich törichterweise unter den Secure Boot Optionen im UEFI die Secure Boot Factory Default Keys ausgerollt. Ich bin mir daher nicht sicher, welche dieser beiden Geschichten ursächlich für das Problem ist.

Seitdem starten weder das installierte Windows noch ein per Media Creation Tool vorbereitetes Installationsmedium mit 24H2, sofern Secure Boot aktiviert ist.

Aus dem Blogeintrag über KB5025885 werde ich nicht schlau. Ich habe meines Wissens kein zusätzliches Update manuell ausgerollt, nur nach dem Upgrade auf 24H2 Windows Update durchlaufen lassen. Wie genau könnte ich den Zertifikatstatus prüfen?

Das könnte dir (und anderen) etwas helfen:
FAQ und Script zur Secure Boot-Absicherung
https://www.borncity.com/blog/2025/02/2 ... ack-lotus/

Ob Windows das neue Zertifikat integriert hat, sollte man (laut Supportseite) an folgendem Registry-Schlüssel herausfinden können:

HKEY_LOCAL_MACHINE\SYSTEM\\CurrentControlSet\Control\SecureBoot\Servicing

Ist dort der 32-Bit-DWORD-Wert WindowsUEFICA2023Capable auf 0x40 gesetzt, sollte Windows vorbereitet sein. Mit dem DWORD-Wert 0x0 ist das System nicht für das neue UEFI-Zertifikat bereit.

Die Frage ist nun, was das mit einen signierten KEK-Schlüssel zu tun hätte.

Bei st das CA2023 installiert un in der Registry steht dazu
Ansonsten in der PowerShell eingeben (mit Adminrechten):
-> True

Aber das CA 2023 wird eigentlich automaisch in das UEFI geschrieben, sofern ein Update vorliegt. Interessanter wäre, was hier die Ausgabe ist:
-> True -> False

Kommt mir gerade ein: Weiß jetzt aber nicht, wie zuverlässig die Ausgaben sind, wenn SecureBoot deaktiviert ist.

Hallo,

bei mir sieht es wie folgt aus: Der Rest: True, True und False.

Das Fujitsu D3233-A13 scheint fast genauso alt zu sein wie mein D3221-A12. Bei mir zeigt sich ja exakt dasselbe Fehlerbild - scheint kein Zufall zu sein...