Fehlerbild

Mit deaktiviertem Secure Boot funktionierte Windows. Nach dem Aktivieren erschien dagegen beim Start die Recovery-Umgebung mit dem Fehlercode 0xc0430001. Das allein beweist weder einen Defekt von Secure Boot noch das Fehlen eines bestimmten Zertifikats in der Firmware.

Hardware und Windows-Version

• Acer Aspire XC-780
• Intel Core i5-7400
• Windows 11 Home 25H2, Build 26200.8037
• UEFI-Firmware: American Megatrends R02-B0 vom 06.12.2017

Erste Diagnose: Secure Boot selbst prüfen

Nach einem erfolgreichen Start mit deaktiviertem Secure Boot wurde der Zustand in einer als Administrator geöffneten PowerShell kontrolliert:

Confirm-SecureBootUEFI

Der aussagekräftigere Gegenversuch folgte anschließend: Ein aktuell und nativ erstellter Windows-11-25H2-Installationsstick bootete bei aktiviertem Secure Boot erfolgreich. Damit stand fest, dass die Firmware Secure Boot grundsätzlich ausführen und aktuelle Microsoft-Installationsmedien akzeptieren konnte. Das Problem musste enger mit dem Bootpfad der installierten Windows-Instanz zusammenhängen.

Secure-Boot-Schlüssel und CA-2023-Status

PK, KEK, db und dbx waren vorhanden. In der Firmware-db fanden sich unter anderem Microsoft UEFI CA 2011, Microsoft Windows Production PCA 2011, Windows UEFI CA 2023, Microsoft Option ROM UEFI CA 2023, Microsoft UEFI CA 2023 sowie Acer-Zertifikate. Deshalb wäre die pauschale Aussage „Dem BIOS fehlt Windows UEFI CA 2023“ in diesem Fall falsch.

Die relevanten Windows-Werte lauteten:

WindowsUEFICA2023Capable = 2
UEFICA2023Status = NotStarted
AvailableUpdates = 0

Zusätzlich trat TPM-WMI Ereignis-ID 1801 auf. Sie wies darauf hin, dass aktualisierte Secure-Boot-Zertifikate bereitstanden, aber der vorgesehene Firmware-/Windows-Migrationsprozess offenbar noch nicht vollständig abgeschlossen war. Das Ereignis war ein Diagnosehinweis, kein alleiniger Beweis für die Ursache.

BCDBoot half hier nicht

Die EFI-Systempartition wurde nur vorübergehend eingebunden. Vor DiskPart-Eingriffen müssen Datenträger, Partitionsgröße und Dateisystem eindeutig geprüft werden; eine falsche Auswahl kann das System unbootbar machen.

mountvol S: /S
bcdboot C:\Windows /s S: /f UEFI /l de-de

Alternativ lässt sich die ESP mit DiskPart identifizieren und einbinden. Dabei niemals blind eine Nummer übernehmen:

diskpart
list disk
list volume
select volume <Nummer der eindeutig identifizierten EFI-Systempartition>
detail volume
assign letter=S
exit

Der BCDBoot-Lauf meldete zwar keinen grundlegenden Secure-Boot-Defekt, löste den Startfehler aber nicht. Entscheidend war, dass danach eine andere Bootmanager-Datei auf der EFI-Systempartition lag.

Zwei gültige Signaturen, zwei unterschiedliche Dateien

Signatur und SHA-256-Hash wurden für beide Dateien geprüft:

Get-AuthenticodeSignature 'C:\Windows\Boot\EFI\bootmgfw.efi' | Format-List Status,StatusMessage,SignerCertificate
Get-FileHash 'C:\Windows\Boot\EFI\bootmgfw.efi' -Algorithm SHA256

Get-AuthenticodeSignature 'S:\EFI\Microsoft\Boot\bootmgfw.efi' | Format-List Status,StatusMessage,SignerCertificate
Get-FileHash 'S:\EFI\Microsoft\Boot\bootmgfw.efi' -Algorithm SHA256

Der entscheidende A/B-Test

Die 2023-signierte ESP-Version wurde zuerst gesichert. Danach ersetzte ausschließlich für den Test die ältere, ebenfalls gültig signierte Datei aus Windows den Bootmanager auf der ESP.

Warnung: Das Ändern von EFI-Bootdateien kann Windows unbootbar machen. Nur mit geprüftem Backup, eindeutig eingebundener ESP und vorhandenem startfähigem Windows-Installationsmedium arbeiten.

copy /Y S:\EFI\Microsoft\Boot\bootmgfw.efi S:\EFI\Microsoft\Boot\bootmgfw.efi.ca2023.bak
copy /Y C:\Windows\Boot\EFI\bootmgfw.efi S:\EFI\Microsoft\Boot\bootmgfw.efi

Danach wurde Secure Boot aktiviert. Windows startete erfolgreich, und die Kontrolle ergab:

Confirm-SecureBootUEFI
True

Damit bestätigte der praktische A/B-Test einen Zusammenhang zwischen dem Startfehler und der auf der EFI-Systempartition verwendeten Bootmanager-Version.

Technische Einordnung

Bei diesem Acer Aspire XC-780 zeigte sich ein Kompatibilitätsproblem im Zusammenhang mit dem 2023-signierten Windows Boot Manager beziehungsweise einer offenbar noch nicht vollständig abgeschlossenen Secure-Boot-/CA-2023-Migration. Daraus folgt ausdrücklich nicht, dass Acer oder die Firmware Windows UEFI CA 2023 generell nicht unterstützen.

Der Dateiaustausch war ein diagnostischer Workaround, keine allgemeingültige Microsoft-Lösung. Windows Update, BCDBoot und andere Servicing-Vorgänge können bootmgfw.efi erneut ersetzen. Künftige Windows- oder Firmware-Aktualisierungen können das Verhalten außerdem verändern. Nach solchen Vorgängen sollte die Signatur erneut kontrolliert und ein vollständiger Neustart mit aktiviertem Secure Boot getestet werden.

Die ESP kann nach Abschluss wieder ausgehängt werden:

mountvol S: /D

Folgerung für die lokale Wiederherstellung

Beim späteren Aufbau einer lokalen Recovery-Lösung blieb deshalb die funktionierende GPT-/EFI-Struktur bewusst erhalten. Der normale Restore formatiert nur die Windows-Partition und führt kein automatisches BCDBoot aus. Der vollständige Ablauf steht im Beitrag Windows 11 vollständig sichern und lokal wiederherstellen.

Fazit

Der Startfehler sah zunächst nach einem allgemeinen Secure-Boot-Problem aus. Der erfolgreiche Start des aktuellen Setup-Sticks, die vorhandenen Schlüssel, der Dateivergleich und schließlich der kontrollierte A/B-Test grenzten ihn jedoch auf den verwendeten Bootmanager und den CA-2023-Migrationskontext ein. Gerade bei Bootproblemen ist diese Reihenfolge wichtiger als ein vorschnelles Ersetzen von Dateien.