Start und Wiederherstellung

Ein Server, der nicht mehr startet, ist der Fall, in dem alle gewohnten Werkzeuge fehlen — keine Anmeldung, kein Remoting, keine Konsole außer der, die man vorher eingerichtet hat. Dieses Modul zeigt die vier Stufen bis zur Anmeldung und für jede ihr eigenes Fehlerbild: einen abgesicherten Modus, der als BCD-Wert stehen bleibt und den Server unerreichbar macht; eine Reparatur, die aus einer kaputten Quelle repariert; und eine Auslagerungsdatei, deren Verschiebung unbemerkt die Absturzdiagnose abgeschaltet hat.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-03

Vier Stufen bis zur Anmeldung

Zwischen dem Einschalten und dem Anmeldebildschirm liegen vier Stufen. Jede hat ein eigenes Fehlerbild, ein eigenes Werkzeug und einen eigenen Ort, an dem ihre Konfiguration steht. Wer die Stufe benennen kann, an der ein Server hängen bleibt, hat den Großteil der Diagnose bereits hinter sich — und wer es nicht kann, probiert Reparaturen aus, die für eine andere Stufe gedacht sind.

Vier Stufen, vier Fehlerbilder. Der Reparaturweg hängt daran, wo es stehen bleibt.

BCD-Speicher — Die Boot Configuration Data — eine kleine Registry-Hive, die dem Bootmanager sagt, welche Betriebssysteme es gibt, wo sie liegen und mit welchen Optionen sie starten. Sie hat auf UEFI-Systemen ihren Platz auf der EFI-Systempartition und ersetzt die frühere boot.ini.

WinRE — Die Windows-Wiederherstellungsumgebung — ein kleines Windows in einer eigenen Abbilddatei, das startet, wenn das eigentliche System nicht mehr startet. Sie bringt eine Eingabeaufforderung mit und Zugriff auf die Platte des defekten Systems.

Die vierte Stufe ist die, die am häufigsten mit den ersten drei verwechselt wird. Ein Server, der bis zum Anmeldebildschirm kommt, hat den Start bestanden — was danach fehlt, ist ein Dienstproblem und gehört nicht in den BCD-Speicher. Umgekehrt hilft kein Blick in die Dienstkonfiguration, solange der Bootmanager gar nicht erst erscheint. Die erste Frage bei einem Server, der nicht startet, lautet deshalb nicht „was ist kaputt“, sondern „wie weit kommt er“.

Der BCD-Speicher und `bcdedit`

bcdedit ist das Werkzeug für diesen Speicher. Ohne Parameter zeigt es die aktiven Einträge; mit /v werden die Kurzformen durch die vollständigen Bezeichner ersetzt, was beim Skripten nötig ist.

Der Speicher ist kein Textfile und lässt sich nicht sinnvoll von Hand öffnen. Er ist als Hive aufgebaut, mit Einträgen für den Bootmanager und für jedes startbare System, und jeder Eintrag trägt eine eindeutige Kennung. Für die geläufigen Einträge gibt es Kurzformen in geschweiften Klammern, die man statt der Kennung schreiben kann.

bcdedit /enum: Zeigt die Einträge des Systemspeichers. Voreinstellung, wenn nichts angegeben wird.
{bootmgr}: Der Bootmanager selbst — Anzeigereihenfolge, Zeitlimit, Startgerät.
{current}: Der Eintrag, mit dem das gerade laufende System gestartet wurde.
{default}: Der Eintrag, der ohne Auswahl genommen wird. Nicht zwingend derselbe wie {current}.
bcdedit /store <Datei>: Arbeitet auf einem anderen Speicher statt auf dem des laufenden Systems.

Der Rückweg, der zwei Sekunden kostetVor jeder Änderung bcdedit /export C:\bcd-vorher ausführen. /import stellt den Zustand später vollständig wieder her — die Dokumentation weist ausdrücklich darauf hin, dass der Import vorhandene Einträge des Systemspeichers vorher löscht, also den Stand von damals herstellt und nicht dazumischt. Ein BCD-Speicher, den man ohne Sicherung verändert hat, ist der Fall, in dem eine falsche Zeile den Server bis zur Neuinstallation kostet.

Der abgesicherte Modus ist eine Einstellung, kein Modus

Der abgesicherte Modus wird nicht bei jedem Start neu gewählt, sondern als Wert im BCD-Speicher hinterlegt: bcdedit /set {default} safeboot minimal. Ab diesem Moment startet der Server dorthin — bei jedem Neustart, unbegrenzt.

Die Falle mit AnsageDer Wert verschwindet nicht von selbst. Wer ihn setzt, sein Problem löst und neu startet, landet wieder im abgesicherten Modus — und dort läuft der Anwendungsdienst nicht, den man gerade prüfen wollte. Der Ausweg ist bcdedit /deletevalue {default} safeboot, und er gehört in denselben Arbeitsschritt wie das Setzen, nicht in eine Erinnerung für später. Auf einem Server ohne Konsole ist ein vergessener safeboot-Wert eine Fernwartungssitzung, die man nicht mehr bekommt, weil der Netzwerkstapel im minimalen Modus fehlt.

Dieselbe Vorsicht gilt für jede andere Startoption. bcdedit /set {current} bootlog yes erzeugt beim nächsten Start ein Protokoll der geladenen Treiber unter %SystemRoot%\ntbtlog.txt — nützlich, aber ebenfalls ein Wert, der bleibt, bis ihn jemand entfernt.

Es gibt drei Varianten: minimal startet nur die nötigsten Treiber und Dienste, network nimmt den Netzwerkstapel dazu, und die Variante mit Eingabeaufforderung verzichtet auf die grafische Oberfläche. Für einen Server, den man ausschließlich über das Netz erreicht, ist network die einzige brauchbare — mit minimal ist der Server zwar gestartet, aber für dich unerreichbar. Wer diese Wahl aus der Ferne trifft, entscheidet damit, ob er sein eigenes Werkzeug behält.

WinRE: die Umgebung, die vorhanden sein muss

WinRE ist kein selbstverständlicher Bestandteil eines Servers. Sie liegt als Winre.wim in einer eigenen Partition oder unter \Windows\System32\Recovery und wird über den BCD-Speicher eingebunden. Bei geklonten Vorlagen, verkleinerten Datenträgern oder Migrationen geht diese Einbindung regelmäßig verloren, ohne dass es jemandem auffällt — bis sie gebraucht wird.

reagentc /info zeigt den Status und den Ort des Wiederherstellungsabbilds.
reagentc /enable bindet es wieder ein; ohne Angabe wird die Standarddatei benutzt.
reagentc /info /target <Pfad> prüft dasselbe für ein eingehängtes fremdes System.

Eine Zeile in der ÜbernahmeprüfungDie Frage, ob WinRE eingebunden ist, kostet einen Befehl und wird fast nie gestellt. Sie beantwortet aber, ob es für diesen Server überhaupt einen Reparaturweg gibt, der ohne Installationsmedium auskommt. Wo sie nicht eingebunden ist, gehört ein erreichbares Installationsmedium in den Wiederanlaufplan — und zwar bevor es gebraucht wird, nicht danach.

Zu wissen ist außerdem, dass WinRE selbst über den BCD-Speicher eingebunden ist. Fällt dieser Speicher aus, fehlt damit auch der Weg in die Reparaturumgebung — beides bricht gemeinsam. Das ist der Grund, warum ein Installationsmedium der passenden Version im Wiederanlaufplan steht, obwohl WinRE eingerichtet ist: Es ist der einzige Weg, der nicht von der Konfiguration des defekten Servers abhängt.

Was in WinRE geht

In der Eingabeaufforderung von WinRE läuft ein eigenes Windows. Die Platte des defekten Systems ist eingehängt, aber sie ist nicht das laufende System — und das ändert, welche Werkzeuge sinnvoll sind.

Registry des defekten Systems: Über reg load als fremde Hive einhängen. Dort gibt es kein CurrentControlSet, nur die nummerierten Kontrollsätze.
Treiber und Dienste abschalten: Im richtigen Kontrollsatz unter Services den Start-Wert ändern.
Abbild reparieren: DISM /Image:<Pfad> /Cleanup-Image /RestoreHealth gegen das eingehängte System.
Startdateien neu schreiben: bcdboot <Pfad>\Windows erzeugt die Startumgebung neu.

Der Fehler, den man offline zweimal machtWelcher Kontrollsatz gilt, steht in Select\Current der eingehängten SYSTEM-Hive. Wer stattdessen ControlSet001 nimmt, weil das der übliche Name ist, ändert unter Umständen den Satz, der beim nächsten Start gar nicht gewählt wird — der Server startet unverändert nicht, und der Eingriff sieht trotzdem korrekt aus. Das ist derselbe Mechanismus wie im Modul über Registry und NTFS, nur mit teureren Folgen.

Der Musterfall: Bugcheck 0x7B

INACCESSIBLE_BOOT_DEVICE ist der Stoppfehler, der nach Änderungen an der Speicherumgebung auftritt. Er bedeutet: Der Kernel ist geladen, findet aber keinen Treiber, mit dem er die Systemplatte ansprechen kann. Die dokumentierten Ursachen sind fast alle Änderungen, die jemand bewusst vorgenommen hat.

Die Reihenfolge in dieser Liste ist kein Zufall: Sie geht von der Software zur Hardware. In der Praxis lohnt es, sie umgekehrt zu lesen und zuerst zu fragen, was sich zuletzt geändert hat. Ein Server, der seit Monaten läuft und nach einem Wartungsfenster mit 0x7B stehen bleibt, ist fast nie ein Hardwaredefekt — er ist die Folge dessen, was im Wartungsfenster passiert ist.

Fehlende, beschädigte oder fehlerhafte Filtertreiber im Speicherstapel.
Ein geänderter Modus oder geänderte Einstellungen des Speichercontrollers im BIOS.
Ein anderer Speichercontroller als der, mit dem Windows installiert wurde.
Eine Platte, die in einen anderen Rechner mit anderem Controller umgezogen ist.

Die virtuelle Maschine nach dem Hostwechsel

Szenario

Eine virtuelle Maschine wurde auf einen anderen Virtualisierungshost verschoben. Dort ist der virtuelle Datenträgercontroller anders eingestellt als vorher. Beim ersten Start erscheint 0x7B.

Anforderungen

Der Server soll ohne Neuinstallation wieder starten.
Der Eingriff soll nachvollziehbar bleiben.

Schritte

Aus WinRE oder einem Installationsmedium starten und die Eingabeaufforderung öffnen.
Die SYSTEM-Hive des defekten Systems mit reg load einhängen und Select\Current lesen.
Im ermittelten Kontrollsatz unter Services den Treiber des jetzt vorhandenen Controllers auf einen Starttyp setzen, der ihn beim Systemstart lädt.
Die Hive wieder aushängen und starten.
Nach dem erfolgreichen Start prüfen, ob der Eingriff dokumentiert und für die übrigen Maschinen derselben Vorlage vorgesehen ist.

Merksatz: Die eigentliche Entscheidung fiel beim Verschieben: Ein Wechsel der Controllereinstellung ist kein reines Infrastrukturthema, sondern verändert, welche Treiber das Gastsystem beim Start braucht. Wer das vorher prüft, spart sich den Umweg über WinRE.

Komponentenspeicher reparieren: DISM vor SFC

sfc /scannow prüft geschützte Systemdateien und ersetzt beschädigte durch Kopien. Die entscheidende Frage ist, woher diese Kopien kommen: aus dem Komponentenspeicher desselben Systems. Ist der beschädigt, hat sfc keine gesunde Quelle — und meldet, dass es beschädigte Dateien gefunden, aber nicht repariert hat.

DISM /Online /Cleanup-Image /CheckHealth: Meldet, ob eine Beschädigung bereits vermerkt ist. Schnell, prüft aber nicht neu.
DISM /Online /Cleanup-Image /ScanHealth: Prüft den Speicher neu. Dauert einige Minuten.
DISM /Online /Cleanup-Image /RestoreHealth: Repariert den Speicher. Holt fehlende Dateien standardmäßig von Windows Update.
… /RestoreHealth /Source:<Pfad> /LimitAccess: Repariert aus einer eigenen Quelle und verbietet den Rückgriff auf Windows Update.
sfc /scannow: Danach: ersetzt die Systemdateien aus dem jetzt gesunden Speicher.

Die Reihenfolge ist die halbe LösungDer dokumentierte Ablauf ist erst DISM /RestoreHealth, dann sfc /scannow. Umgekehrt betrieben repariert man Dateien aus einer Quelle, die selbst kaputt ist — das Ergebnis ist ein Lauf, der nichts bewirkt, und die Schlussfolgerung, das Werkzeug helfe nicht. Beide schreiben in dieselbe Protokolldatei %windir%\Logs\CBS\CBS.log; wer wissen will, was tatsächlich passiert ist, liest dort nach statt in der Zusammenfassung auf dem Bildschirm.

Für die Quelle gilt dieselbe Regel wie bei Rollen und Features: Sie muss zur Version des Servers passen. Ein Reparaturlauf gegen ein Abbild einer anderen Windows-Version findet die Dateien nicht, die er sucht.

Beide Läufe brauchen Zeit und Plattenplatz und sind auf einem produktiven Server keine Nebenbei-Maßnahme. Der Nutzen ist außerdem begrenzt: Sie stellen Systemdateien und Komponentenmanifeste wieder her, nicht die Konfiguration einer Anwendung und nicht die Daten eines Dienstes. Wer nach einem gescheiterten Update repariert, gewinnt damit die Voraussetzung dafür, das Update erneut zu versuchen — nicht das Ergebnis des Updates.

Absturzabbilder: was geschrieben wird

Stürzt der Kernel ab, schreibt Windows den Speicherinhalt weg — aber nur, wenn es dafür Platz gibt und wenn der eingestellte Umfang zur Umgebung passt. Der Umfang steht in HKLM\SYSTEM\CurrentControlSet\Control\CrashControl im Wert CrashDumpEnabled, und zwar als REG_DWORD.

0x1 — vollständiges Abbild: Der gesamte Arbeitsspeicher. Erfordert eine Auslagerungsdatei auf einem lokalen Volume von mindestens Arbeitsspeichergröße plus 257 MB.
0x2 — Kernelabbild: Nur der Kernelspeicher. Die Auslagerungsdatei muss den Kernelspeicher fassen.
0x3 — kleines Abbild: 64 KB, benötigt mindestens 2 MB auf dem Startvolume. Landet als eigene Datei je Absturz unter %SystemRoot%\Minidump.
Automatisches Abbild: Verhält sich wie das Kernelabbild, verwaltet die Größe der Auslagerungsdatei aber selbst.

Warum das Abbild fehltDer Speicherinhalt wird beim Absturz zunächst in die Auslagerungsdatei auf der Systempartition geschrieben und erst beim nächsten Start in die eigentliche Abbilddatei überführt. Wer die Auslagerungsdatei verkleinert oder auf ein anderes Volume verschoben hat — ein häufiger Handgriff, wenn die Systemplatte eng wird —, hat damit ohne es zu merken die Absturzdiagnose abgeschaltet. Der Server stürzt weiter ab, nur ohne Beweismittel.

Der Wert ist ein REG_DWORD, und das ist keine Formalie: Ein per Skript als Zeichenkette angelegter Eintrag mit dem Inhalt 2 wird nicht gelesen, das System bleibt bei seiner Voreinstellung, und der Unterschied fällt erst beim nächsten Absturz auf. Nach jeder Änderung an dieser Stelle gehört deshalb ein Rücklesen mit reg query dazu, das den Typ mit anzeigt.

Was nach einem Absturz im Protokoll steht

Nach einem unerwarteten Neustart protokolliert Windows beim nächsten Start ein Ereignis mit der Kennung 41 aus der Quelle Kernel-Power: Das System wurde neu gestartet, ohne vorher ordnungsgemäß heruntergefahren zu werden. Dazu kommt üblicherweise die Kennung 6008 für das unerwartete Herunterfahren.

Ereignis 41 ist keine DiagnoseDie Dokumentation sagt es direkt: Für sich genommen enthält Ereignis 41 oft nicht genug Information, um zu bestimmen, was passiert ist. Entscheidend sind die Daten des Ereignisses — steht dort ein Stoppfehlercode, gab es einen Bugcheck und es existiert vermutlich ein Abbild. Stehen dort Nullen, deutet das auf einen Stromausfall, ein Hardwareproblem oder ein Halten der Einschalttaste hin, und ein Abbild wird es nicht geben. Wer nur die Kennung liest und nicht die Daten, verwechselt drei sehr verschiedene Fälle.

Praktisch heißt das: Ereignis 41 sagt „unerwartet“, nicht „warum“. Die Antwort auf das Warum steht entweder im Abbild oder in Protokollen außerhalb von Windows — der Fernwartungskarte, dem Virtualisierungshost, der unterbrechungsfreien Stromversorgung. Wer diese Quellen nicht hat, kann die dritte Möglichkeit nicht von den ersten beiden trennen.

Die Ereignisse stehen im Systemprotokoll und lassen sich gezielt herausziehen, statt sie zu suchen: eine Abfrage auf die Kennungen 41, 1001 und 6008 im fraglichen Zeitfenster liefert die unerwarteten Neustarts, den zugehörigen Fehlerbericht und die Meldung über das unerwartete Herunterfahren. Wichtig ist dabei die Reihenfolge der Zeitstempel — Ereignis 41 wird beim nächsten Start geschrieben und trägt deshalb einen Zeitpunkt nach dem Ausfall, nicht während.

Der automatische Neustart und was er verdeckt

Windows startet nach einem Bugcheck voreingestellt sofort neu. Für einen produktiven Server ist das meist richtig — der Dienst kommt schneller zurück. Für die Diagnose ist es der Grund, warum niemand den Stoppfehlercode gesehen hat.

Der Schalter dafür liegt im selben Schlüssel CrashControl und ist in der Systemoberfläche als automatischer Neustart geführt. Ihn abzuschalten ist eine Entscheidung mit klarem Preis: Der Server bleibt nach einem Absturz stehen, bis jemand hinsieht. Auf einem Cluster-Knoten mit funktionierendem Failover kann das genau richtig sein, auf einem Einzelserver mit Nutzern daran fast nie.

Die bessere AlternativeIn den meisten Fällen ist nicht der Neustart das Problem, sondern das fehlende Abbild. Wer sicherstellt, dass Abbildtyp und Auslagerungsdatei zusammenpassen, braucht den stehengebliebenen Server nicht: Der Stoppfehlercode steht dann in den Daten von Ereignis 41 und der Rest im Abbild. Der automatische Neustart bleibt an, und die Diagnose bleibt trotzdem möglich.

Bevor der Server nicht startet

Fast alles an diesem Modul lässt sich nicht mehr vorbereiten, wenn es gebraucht wird. Die folgenden Punkte gehören deshalb in die Übernahme eines Servers, nicht in seine Störung.

reagentc /info — ist ein Wiederherstellungsweg eingebunden?→bcdedit /export — liegt eine Sicherung des Startspeichers, und wo?→CrashDumpEnabled und Auslagerungsdatei — passen Abbildtyp und Platz zusammen?→Konsolenzugang unabhängig vom Betriebssystem — Fernwartungskarte oder Virtualisierungskonsole, geprüft und mit bekannten Zugangsdaten.→Installationsmedium der passenden Version erreichbar, falls WinRE fehlt.

Der vierte Punkt ist der, den man am teuersten nachholt: Ohne Konsole hilft kein Reparaturwissen.

Die Reihenfolge im Ernstfall

Wenn ein Server nicht mehr startet, ist die Versuchung groß, sofort ein Reparaturwerkzeug laufen zu lassen. Die Reihenfolge unten kostet ein paar Minuten mehr und verhindert, dass man den Zustand zerstört, den man noch braucht.

Die Stufe bestimmen, an der es stehen bleibt — Firmware, Bootmanager, Ladeprogramm oder Dienste. Das Fehlerbild sagt es.→Die letzte Änderung suchen: Update, Treiber, Controllereinstellung, Verschiebung. 0x7B nach einer Infrastrukturänderung ist selten ein Zufall.→Beweismittel sichern, bevor repariert wird — Abbild, Protokolle, ein Datenträgerabbild bei unklarer Lage.→Den kleinsten Eingriff wählen, der zur Stufe passt, und ihn einzeln durchführen.→Nach jedem Eingriff neu starten und das Ergebnis notieren, statt mehrere Änderungen zu bündeln.

Mehrere Reparaturen auf einmal bringen den Server vielleicht hoch — und niemand weiß danach, welche davon nötig war und ob sie auf den übrigen Servern derselben Vorlage auch ansteht.

Der Preis dieser SorgfaltSie kostet Zeit, die im Ausfall besonders weh tut, und sie ist bei einem Server ohne Nutzer übertrieben. Der Maßstab ist nicht die Vorsicht selbst, sondern die Frage, ob der Fall wiederkommt: Ein Einzelfall darf schnell und undokumentiert repariert werden. Ein Server aus einer Vorlage, von der zwanzig weitere existieren, ist nie ein Einzelfall.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität10 Primärquellen · zuletzt geprüft: 2026-09-03