Du drückst den Einschaltknopf. Die Lüfter zucken, irgendwo glimmt eine Diode, vielleicht erscheint nach ein paar Sekunden ein Herstellerbild. In der Alltagssprache fährt jetzt Windows hoch. Technisch ist Windows zu diesem Zeitpunkt oft noch nicht einmal im Gebäude. Der erste Akteur kennt weder deinen Desktop noch Laufwerk C:, weder Steam noch den Ordner mit den Urlaubsfotos. Er hat Strom, einen Prozessor in definiertem Startzustand und gerade genug Firmware, um die nächste Tür zu suchen. Das macht den Bootvorgang zu einem ziemlich eleganten Einbruch in eine Maschine, die sich bei jedem Kaltstart zunächst selbst verschlossen vorfindet. Kein einzelner Täter knackt alles. Stromversorgung, frühe Firmware, Hardwareinitialisierung, UEFI Boot Manager, Secure Boot und schließlich ein Betriebssystem-Loader reichen den Schlüssel weiter. Jede Stufe öffnet nur den Raum, den die nächste braucht. Die folgenden Stationen sind deshalb keine behaupteten Sekundenmarken. Manche Rechner rasen hindurch, andere trainieren Speicher, prüfen Geräte oder zeigen lange gar nichts. Minutiös ist hier die Rekonstruktion: Wer hatte wann die Kontrolle, welche Tür konnte er öffnen und welches Signal hinterließ er? Diese Frage ist mehr als nerdige Schönheit. Sie verhindert den beliebtesten Kurzschluss jeder privaten PC-Notaufnahme: schwarzer Bildschirm gleich Windows kaputt. Wenn das Gerät nie bis zum Windows Boot Manager kam, kann Windows nichts dafür. Wenn bereits ein Linux-Kernel nach seinem Root-Dateisystem ruft, ist UEFI längst aus dem Hauptgeschehen verschwunden. Wer die Schlüsselübergaben kennt, kann beim nächsten Hilferuf im Freundeskreis erst zuhören, dann eingrenzen und den großen Hammer im Schrank lassen.
Tür eins: Der Taster macht noch keinen Computer
Der Knopf an der Gehäusefront ist kein Startbefehl an Windows. Er löst eine elektrische und plattformspezifische Folge aus. Spannungen müssen stabil werden, Takt und Resetlogik einen definierten Zustand erreichen, dann beginnt ein Prozessor an einer vorgesehenen Startposition Firmwarecode auszuführen. In diesem Moment gibt es nicht einmal die Garantie, dass gewöhnlicher Arbeitsspeicher, Grafikausgabe oder USB-Eingabe schon benutzbar sind.
Genau deshalb kann ein früher Defekt so unhöflich schweigen. Ein Betriebssystem könnte einen Dialog zeichnen, eine Protokolldatei schreiben oder einen freundlichen QR-Code anbieten. Frühe Firmware hat diese luxuriöse Welt noch nicht gebaut. Sie kann je nach Gerät vielleicht eine Diagnose-LED, einen Piepton oder einen wiederholten Neustart erzeugen. Auch diese Signale sind keine universelle Sprache: Ihre Bedeutung gehört zur Dokumentation des konkreten Mainboards oder Komplettsystems.
Die UEFI Platform Initialization Architecture beginnt ihren beschriebenen Weg mit einer sehr kleinen Ausführungsumgebung. Die aktuelle PI-Spezifikation ordnet der frühen Vorbereitung unter anderem die Herstellung von dauerhaft nutzbarem Speicher zu, bevor spätere Firmwarekomponenten komfortabler arbeiten können. [1] Das ist die erste geöffnete Tür: Aus elektrisch vorhanden wird überhaupt erst ausführbar.
Bleiben Lüfter, Anzeigen und jede Reaktion aus, ist die Geschichte also nicht automatisch an einem kaputten Betriebssystem gescheitert. Windows, Ubuntu und selbst der UEFI Boot Manager hatten noch keine Gelegenheit, einen Fehler zu machen. Das klingt banal, ist aber die wichtigste Entlastung des ganzen Abends.
Tür zwei: Die Firmware baut sich erst einen Raum
Sobald früher Code läuft, muss die Firmware aus einem Haufen vorhandener Teile eine benutzbare Plattform machen. Speicher wird initialisiert, Prozessor- und Chipsatzfunktionen werden vorbereitet, Gerätepfade entstehen, Konsolen und Speichermedien werden auffindbar. In der PI-Architektur heißen wichtige Abschnitte PEI und DXE: PEI bereitet unter anderem permanenten Speicher vor, DXE lädt Komponenten und stellt Dienste für die weitere Initialisierung bereit. [1]
Das ist weniger ein einzelner Selbsttest als eine Crew, die in einem dunklen Gebäude nacheinander Licht, Aufzug und Türschilder in Betrieb nimmt. Der verbreitete Ausdruck POST bündelt vieles, was konkrete Hersteller unterschiedlich verteilen. Ein RAM-Training kann mehrere Neustarts verursachen. Eine grafische Ausgabe kann später verfügbar werden als Speicher und Prozessor. Das UEFI-Setup kann funktionieren, obwohl kein startfähiges System gefunden wird.
UEFI 2.11 ist dabei der gemeinsame Übergabevertrag, nicht die vollständige Innenarchitektur jedes Mainboards. Die Spezifikation definiert Schnittstellen, Datentypen, Boot- und Runtime-Dienste sowie die Art, wie UEFI-Anwendungen gestartet werden. Sie schreibt einem Hersteller nicht jede interne Reihenfolge seiner Initialisierung vor. [2] Wer Begriffe wie PEI und DXE kennt, besitzt deshalb ein hilfreiches Modell, aber kein Röntgenbild jeder Firmware.
Das erste sichtbare Setup-Menü ist bereits ein ziemlich großer Erfolg. Prozessor, ein Teil des Speichers, Eingabe, Ausgabe und wesentliche Firmwarelogik arbeiten dann weit genug zusammen, um dich hereinzulassen. Ein Betriebssystem ist dadurch noch nicht gefunden. Aber die Crew hat den Eingangsbereich beleuchtet.
Tür drei: Secure Boot ist Türsteher, nicht Leibwächter
Wenn die Firmware ein startbares UEFI-Image findet, kann eine Vertrauensprüfung vor dem nächsten Sprung stehen. Secure Boot vergleicht Signaturen oder Hashes mit der auf der Plattform eingerichteten Richtlinie. Im Modell von UEFI gehören dazu ein Platform Key, Key Exchange Keys sowie Datenbanken für erlaubte und gesperrte Signaturen. [4] Der Türsteher prüft also nicht, ob ein Programm sympathisch oder fehlerfrei ist. Er prüft, ob es nach den hinterlegten Regeln hinein darf.
Diese Unterscheidung rettet viele Gespräche vor Technikmystik. Ein gültig signierter Loader kann einen Bug besitzen. Ein selbst gebauter, sauberer Linux-Kernel kann abgewiesen werden, wenn sein Schlüssel nicht vertraut wird. Und eine aktuelle Sperrliste kann ein früher erlaubtes Image plötzlich blockieren, weil dessen Schlüssel oder Hash widerrufen wurde. Secure Boot ist eine Autorisierungskette, kein metaphysisches Gütesiegel.
Microsoft trennt diese frühe Prüfung von Trusted Boot. Nach dem von UEFI geschützten Übergang prüft der Windows-Loader den Windows-Kernel; der Kernel prüft wiederum nachfolgende Startkomponenten und frühe Treiber. [10] Der Türsteher bleibt also nicht den ganzen Abend für jeden Raum zuständig. Er übergibt an weitere Verantwortliche, die mit ihren eigenen Regeln fortfahren.
Eine Meldung wie Security Violation ist deshalb schon erstaunlich präzise: Strom, frühe Firmware, ein Teil der Geräteerkennung und die Suche nach einem EFI-Image haben funktioniert. Der Einbruch scheitert nicht an der Haustür, sondern an der Gästeliste. Das ist eine ganz andere Baustelle als ein Rechner ohne jedes Lebenszeichen.
Tür vier: UEFI sucht keine Festplatte, sondern eine Adresse
Im typischen Gespräch heißt es: Stell die richtige SSD an erste Stelle. Der UEFI Boot Manager arbeitet genauer. Seine normalen Ziele stehen in BootOrder, einer geordneten Liste von Nummern. Jede Nummer verweist auf eine Boot####-Variable mit Beschreibung, Attributen und einem Gerätepfad zu einem konkreten UEFI-Image. BootNext kann genau einen folgenden Start umleiten und wird anschließend wieder entfernt. [3]
Die Firmware wählt also nicht bloß einen Metallkasten oder eine NVMe-Karte. Sie verfolgt eine Adresse über Controller, Datenträger, Partition und Datei. Häufig liegt das Image auf einer EFI System Partition, kurz ESP. Diese kleine Systempartition ist weder automatisch Laufwerk C: noch das Linux-Root-Dateisystem. Sie ist der Vorraum, in dem EFI-Anwendungen verschiedener Betriebssysteme nebeneinander liegen können.
Das erklärt einen Fehler, der von außen paradox wirkt: Die SSD wird im UEFI-Setup korrekt angezeigt, aber das Gerät meldet trotzdem No bootable device. Vorhandene Hardware beweist nicht, dass BootOrder auf einen gültigen Eintrag zeigt, dass dessen Gerätepfad noch stimmt oder dass die erwartete EFI-Datei existiert. Umgekehrt löscht ein verlorener Boot####-Eintrag nicht automatisch alle Daten des Betriebssystems.
Der UEFI Boot Manager ist laut Spezifikation ein Firmware-Policy-Modul. Er kann normale Bootoptionen, einen einmaligen BootNext-Weg und Recoverypfade verarbeiten; anschließend lädt und startet er das gewählte Image. [3] Jetzt wird aus der allgemeinen Plattform ein konkreter Plan: heute Windows, ein Linux-Kernel, GRUB, ein Installationsmedium oder eine Wiederherstellungsumgebung.
Tür fünf: Windows Boot Manager trägt nicht denselben Schlüssel wie Windows
Auf einem typischen UEFI-Windows-System führt ein Firmwareeintrag zum Windows Boot Manager, der als bootmgfw.efi auf der EFI-Systempartition liegt. Microsoft dokumentiert daneben winload.efi als getrennten Windows OS Loader auf der Windows-Partition. [11] Das sind keine zwei Namen für dasselbe Programm. Der Manager entscheidet, welcher Windows-Eintrag, welche Recovery-Umgebung oder welche andere Bootanwendung folgen soll. Erst der OS Loader bereitet den konkreten Windows-Kernel vor.
Zwischen beiden liegt die Boot Configuration Data, kurz BCD. Sie beschreibt Bootobjekte und ihre Einstellungen. Deshalb sind UEFI-NVRAM und BCD zwei verschiedene Schlüsselbunde. Der Firmwareeintrag muss zunächst den Windows Boot Manager finden. Dieser muss anschließend einen passenden Loader und dessen Systempfad aus seiner Konfiguration bestimmen. Ein sichtbarer Eintrag namens Windows Boot Manager beweist nur, dass die erste Referenz existiert; er garantiert nicht, dass die zweite gesund ist.
Microsoft ordnet Startprobleme entsprechend in PreBoot, Windows Boot Manager, OS Loader und Kernel. [12] Diese Trennung ist nicht bloß für Supportformulare nützlich. Ein BCD-Fehler gehört hinter eine bereits erfolgreiche Firmwareübergabe. Ein später Absturz bei einem Boot-Treiber gehört noch eine Tür weiter. Erst wenn der Kernel und der Session Manager ihre Arbeit getan haben, nähert sich die Maschine dem Login.
Windows ist beim Einschalten also nicht der Hausherr, der alle Räume öffnet. Es kommt als Gast ziemlich spät an, bringt dann allerdings noch einmal eigenes Sicherheitspersonal, eigene Konfiguration und eigene Schlüssel mit. Wer das auseinanderhält, muss nicht mehr jede frühe Pause dem Betriebssystem anlasten.
Tür sechs: Linux kann den Seiteneingang nehmen
Linux zeigt besonders schön, dass Bootloader eine Rolle und nicht zwingend ein separates Produkt sind. Ein klassischer Weg führt über GRUB: Die Firmware startet die EFI-Anwendung, GRUB bietet bei Bedarf ein Menü, lädt Linux-Kernel und initramfs und übergibt Parameter. Das Linux/x86-Bootprotokoll beschreibt, welche Daten ein Loader für den Kernel vorbereitet, darunter Kommandozeile und Angaben zur initrd. [6]
Ein Linux-Kernel mit EFI Boot Stub kann aber selbst wie eine EFI-Anwendung auftreten. Die Firmware kann ihn direkt laden; der Stub übernimmt die nötige Brücke in den Kernel. [7] Distributionen können außerdem ein Unified Kernel Image verwenden, das mehrere benötigte Bestandteile bündelt. Es gibt daher nicht den einen Linux-Türplan, den jedes System exakt nachspielen müsste.
Nach dem Kernelsprung ist der dauerhafte Linux-Alltag ebenfalls noch nicht fertig. Ein initramfs wird in ein temporäres rootfs im Arbeitsspeicher entpackt. Dessen frühes /init kann Speichertreiber laden, verschlüsselte Volumes öffnen, RAID oder Netzwerk vorbereiten und erst dann das eigentliche Root-Dateisystem finden. [8] Die Passwortabfrage für eine verschlüsselte Platte kann also erscheinen, obwohl das System auf dieser Platte noch gar nicht vollständig läuft.
Das ist der Moment, in dem ein schwarzer Bildschirm bereits sehr spät sein kann. Vielleicht lebt der Kernel, vielleicht wartet das initramfs auf ein Gerät, vielleicht scheitert erst die grafische Sitzung. UEFI hat den Schlüssel dann längst weitergegeben. Wer trotzdem im Firmwaremenü wild Optionen umlegt, arbeitet zwei Räume zu früh.
Tür sieben: ExitBootServices fällt hinter dem Loader ins Schloss
Bis zu einem bestimmten Punkt darf ein OS-Loader die bequemen Bootdienste der Firmware nutzen: Speicher anfordern, Geräte über Protokolle finden, Dateien laden und die aktuelle Speicherkarte abfragen. Dann kommt ExitBootServices. Bei erfolgreichem Aufruf hat der UEFI OS Loader die Kontrolle über die Plattform übernommen; die Funktionszeiger der Boot Services sind anschließend nicht mehr gültig. [5]
Das ist der eigentliche Souveränitätswechsel. Vorher arbeitet der Loader noch in einem eingerichteten Vorraum der Firmware. Danach muss das Betriebssystem sein eigenes Maschinenmodell durchsetzen: Speicherverwaltung, Interrupts, Scheduler, Treiber und Gerätezugriff. Einige klar definierte Runtime Services können fortbestehen, etwa für bestimmte Variablen oder einen Reset. Die Firmware führt aber nicht mehr gemütlich den Bootvorgang für Windows oder Linux weiter.
Die Tür fällt auch erzählerisch hörbar ins Schloss. Kehrt ein gewöhnliches UEFI-Programm zurück, kann der Firmware-Boot-Manager eventuell den nächsten Weg versuchen. Nach einem erfolgreichen ExitBootServices gibt es diese höfliche Rückgabe nicht. Der Kernel übernimmt die Verantwortung und kommt bei einem Fehler nicht einfach in das vorherige Menü zurück.
Darum ist ein Kernelpanic-Text oder ein Windows-Fehler aus der Loader- oder Kernelphase wertvolle Ortsangabe. Er beweist nicht die Ursache, aber er beweist, dass Strom, frühe Firmware, wesentliche Hardwareinitialisierung, Bootauswahl und zumindest ein Teil des Loaderwegs bereits hinter der Maschine liegen.
Tür acht: Das letzte offene Licht ist die beste Spur
Am Ende muss aus dem Einbruch keine Tabellenprüfung werden. Es genügt zunächst, das letzte belastbare Signal ernst zu nehmen. Gar keine Reaktion verweist weit vor das Betriebssystem. Eine Diagnose-LED ohne Bild gehört in die frühe Plattformphase und muss mit der Dokumentation des konkreten Geräts gelesen werden. Ein erreichbares UEFI-Setup beweist bereits funktionierende Teile von CPU, Speicher, Eingabe und Ausgabe. No bootable device bedeutet, dass die Firmware weit genug kam, um nach einem Startziel zu suchen. Eine Security-Violation setzt sogar ein gefundenes, aber nicht autorisiertes Image voraus.
Ein sichtbares GRUB-Menü oder der Windows Boot Manager verschiebt die Grenze erneut. Jetzt hat die Firmware ein EFI-Image gestartet. Meldet Windows fehlende BCD-Daten oder findet der Manager winload.efi nicht, liegt das Problem hinter UEFI und vor dem Kernel. Zeigt Linux bereits Kernelmeldungen, sucht aber vergeblich nach seinem Root-Dateisystem, sind Loader und Kernelsprung erfolgt. Die Linux-Dokumentation trennt dabei fehlendes Root, fehlendes init, unpassende Binärformate und fehlende Abhängigkeiten als unterschiedliche späte Ursachen. [9]
Selbst ein schwarzer Bildschirm nach einem sichtbaren Logo bleibt mehrdeutig. Vielleicht wechselt die Grafikausgabe gerade von einem Firmware-Framebuffer zu einem Betriebssystemtreiber. Vielleicht läuft das System schon und nur die grafische Sitzung fehlt. Reagiert die Tastaturanzeige, ist der Rechner im Netzwerk erreichbar oder ändert sich die Bildschirmauflösung, entstehen neue Spuren. Keine einzelne davon ersetzt Diagnose; zusammen zeigen sie, wie weit die Crew kam.
Microsofts Supportdokumentation beginnt aus gutem Grund mit der Frage nach der betroffenen Startphase. [12] Diese Haltung ist auch im Freundeskreis die coolere: nicht sofort mit Neuinstallation, BCDEdit-Zeilen aus irgendeinem Forum oder fünf gleichzeitig geänderten UEFI-Schaltern beeindrucken. Erst den genauen Wortlaut fotografieren, den letzten sichtbaren Übergang benennen und die passende Schicht prüfen. Veränderungen an BCD, Partitionen oder Firmwareeinträgen kommen erst mit Sicherung und Rückweg.
Wenn Windows schließlich am Login ankommt oder Linux seinen dauerhaften Init-Prozess startet, wirkt der Weg im Rückblick fast selbstverständlich. Das ist er nicht. Bei jedem kalten Start wird aus elektrischer Bereitschaft eine initialisierte Plattform, aus Plattformpolitik eine konkrete EFI-Anwendung und aus einem Loader ein Betriebssystem, das seine eigene Ordnung errichtet. Der Einschaltknopf weckt Windows nicht. Er gibt der ersten Crew nur das Zeichen, Tür eins zu öffnen. Alles Weitere ist eine bemerkenswert gut choreografierte Übergabe – und jede kleine Leuchte darin kann im richtigen Moment zum Alibi werden.
Geöffnete Quellen zu UEFI, Secure Boot, Windows- und Linux-Startpfaden
- UEFI Platform Initialization Specification 1.9 – Overview (standard-primary)
- UEFI Specification 2.11 (standard-primary)
- UEFI Specification 2.11 – Boot Manager (standard-primary)
- UEFI Specification 2.11 – Secure Boot and Driver Signing (standard-primary)
- UEFI Specification 2.11 – EFI System Table and ExitBootServices (standard-primary)
- Linux Kernel Documentation – Booting (technical-primary)
- Linux Kernel Documentation – The EFI Boot Stub (technical-primary)
- Linux Kernel Documentation – Ramfs, Rootfs and Initramfs (technical-primary)
- Linux Kernel Documentation – No Working Init Found (technical-primary)
- Microsoft Learn – Secure Boot and Trusted Boot (technical-primary)
- Microsoft Learn – BCD System Store Settings for UEFI (technical-primary)
- Microsoft Learn – Windows Startup Issues and Boot Phases (technical-primary)
Recherche- und Redaktionsstand: 17. August 2026. Redaktionell verantwortlich: Benjamin Metzig.