Troubleshooting: Secure Boot, CSM und GPT richtig reparieren

Fall 1: Wenn plötzlich nichts mehr startet

Ein Klassiker nach der Umstellung auf UEFI: Nach dem Deaktivieren des CSM-Modus verschwinden alle Boot-Optionen. Das sieht dann so aus, als hätte das Mainboard plötzlich jede Information über das installierte System vergessen. Tatsächlich hat es das nicht. Es erkennt nur keine gültige EFI-Struktur. Ursache ist meist eine Systemdisk, die noch im alten MBR-Format vorliegt. UEFI erwartet jedoch eine GPT-Partitionstabelle mit einer eigenen EFI-Systempartition (ESP). Fehlt diese, wird schlicht nichts mehr als "bootfähig" erkannt.

Windows lässt sich in solchen Fällen zwar reparieren, allerdings nicht immer elegant. Wer seine Installation behalten möchte, kann mit mbr2gpt.exe konvertieren, sofern genug freier, zusammenhängender Platz am Anfang der Platte vorhanden ist. Fehlt die ESP ganz, bleibt nur das manuelle Anlegen, oder im Worst Case eine Neuinstallation im nativen UEFI-Modus.

Problematisch sind auch alte Datenträger, die vom System noch als "Legacy Disk" eingestuft werden. Das BIOS blendet sie dann schlicht aus, sobald CSM deaktiviert ist. Das betrifft nicht nur alte SSDs mit Windows-7-Resten, sondern auch Klonmedien und Testinstallationen. Kurz gesagt: Sobald UEFI aktiv ist, zählen nur noch GPT und saubere Bootstrukturen. Alles andere wird ignoriert.

Fall 2: Alte Relikte im Weg

Eine alte SSD, auf der irgendwann einmal Windows 7 lief, steckt noch im System, und blockiert plötzlich den Start. Der Grund liegt selten im Datenträger selbst, sondern in den Überresten alter Bootsektoren. Diese enthalten teils noch aktive Einträge für den Windows Boot Manager, die vom UEFI bevorzugt werden, sobald Secure Boot aktiv ist. Das Resultat: Das System versucht, von einer nicht mehr existierenden Installation zu starten, und bleibt hängen.

Quelle: PCGH Mit Diskpart die entsprechende SSD auswählen und dann mit dem Befehl clean säubern. Solche Geistereinträge überstehen mitunter sogar komplette Neuinstallationen, wenn sie auf einer anderen Platte durchgeführt wurden. In der Praxis hilft oft nur, die betroffene SSD kurzzeitig physisch abzustecken und den Bootloader auf der aktiven Systemplatte neu zu schreiben. Alternativ lässt sich das Laufwerk auch über die Eingabeaufforderung mit diskpart clean bereinigen, allerdings vollständig, inklusive Partitionstabelle.

Wer nach der Umstellung auf Secure Boot also plötzlich einen "falschen" Windows-Boot-Manager sieht oder in der Bootliste eine unbekannte Partition auftaucht, hat mit hoher Wahrscheinlichkeit noch alte MBR-Reste im System. Die saubere Lösung lautet dann nicht Workaround, sondern Aufräumen, und zwar auf Dateisystemebene.

Fall 3: Bluescreen nach der Umstellung

Wenn nach der Aktivierung von Secure Boot plötzlich der Bluescreen grüßt, liegt das meist nicht an einem Hardwarefehler, sondern an der Historie des Systems. Viele Windows-Installationen stammen ursprünglich aus Zeiten, in denen der Legacy-Modus Standard war. Beim Wechsel auf UEFI und Secure Boot sucht der Kernel dann nach signierten Starttreibern und findet keine. Der Bootvorgang bricht ab, weil alte Module schlicht nicht mit aktuellen, von Microsoft anerkannten Zertifikaten signiert sind.

Quelle: Reddit/Nonsneakyanon Nach der Aktivierung verweigert Windows den Start, weil alte, unsignierte Bootmodule aus der Legacy-Ära blockiert werden. In der Praxis trifft das vor allem Systeme, die mehrfach geupgradet wurden, etwa von Windows 7 auf 10 und später auf 11. Treiberreste aus der Legacy-Ära bleiben im Kernel-Verzeichnis erhalten und sind zwar funktionsfähig, aber unsigniert. Sobald Secure Boot greift, werden sie blockiert. Das Ergebnis: Code 0xC0000225 oder ähnliche Fehlermeldungen, die auf fehlende Startdateien hinweisen.

Manchmal genügt es, betroffene Module zu entfernen oder über den Geräte-Manager neu zu installieren. In hartnäckigen Fällen hilft jedoch nur eine Neuinstallation unter nativem UEFI mit aktiviertem Secure Boot. Kurz gesagt: Wer beim Booten in den Bluescreen läuft, hat kein defektes Windows, sondern eines, das nie für Secure Boot gebaut war. Und selbst wenn Windows wieder startet, lauern weitere Stolperfallen, etwa dann, wenn nach der Secure-Boot-Umstellung plötzlich nur noch Reset hilft. Warum auch Treiber problematisch sein können, lesen Sie auf der nächsten Seite.

Artikel teilen

Battlefield 6 und Co.: 11 Probleme mit TPM 2.0 und Secure Boot In der Praxis zeigt sich manchmal: Die Umstellung auf UEFI und Secure Boot läuft nicht immer reibungslos.

Per E-Mail versenden

31

1. Seite 1 Übersicht und was zu unterlassen ist
2. Seite 2 Secure Boot, CSM und GPT richtig reparieren
3. Seite 3 Wenn Secure Boot mehr blockiert als schützt
4. Seite 4 TPM und BIOS-Fallen: Funktionierende Systeme können scheitern
5. Seite 5 TPM-Fallen und OEM-Sperren
6. Seite 6 Bitlocker-Alarm nach BIOS-Update