Profi-Know-how: Windows boot.ini

Bei Veränderungen an der Festplatten-Partitionierung ist der Adrenalinstoß vorprogrammiert: Windows NT/2000/2003/XP meldet sich beim Booten mit "NTOSKRNL not found", das System steht. Manch einer weiß sich am Ende nur noch mit einer kompletten Windows-Neuinstallation zu helfen. Dabei hätte es genügt, die Konfigurationsdatei boot.ini des Windows-Bootmanagers minimal anzupassen.

Der integrierte Bootmanager von Windows wird oft unterschätzt. Er enthält jedoch einige Funktionen, die externe Bootmanager nicht bieten können. Eine davon ist die Auswahl der HAL, mit der Windows startet.

Ohne Zutun ermittelt Windows selbstständig, welches Basisset aus Kernel und HAL installiert wird. Bei einem ACPI-fähigen System nutzt es auch den entsprechenden Kernel samt HAL. Das kann aber zu einem instabilen System führen, denn Windows 2000 vergibt bei der ACPI-HAL an alle PCI-Karten nur einen einzigen Interrupt. Dieser wird dann über das IRQ-Steering unter den Karten aufgeteilt.

Allerdings gibt es Steckkarten, die damit Probleme haben, beispielsweise die TV-Karte Studio PCTV von Pinnaclesys, die mit der ACPI-HAL das ganze System einfriert. Aber auch beim Harddisk-Recording kann es zu Problemen kommen, weil es sehr anfällig für Verzögerungen ist.

Deshalb hat Microsoft, ganz versteckt, die Möglichkeit eingebaut, bei der Installation die HAL auszuwählen. Dazu muss man lediglich bei der Aufforderung zur Installation zusätzlicher Speichertreiber die Taste F5 drücken. Dann erhält man ein Auswahlmenü, in dem die Setup-Routine die verschiedenen Kernel- (Single- und Multiprozessor) und HAL-Varianten (ACPI, Standard-PC) auflistet.

Will man aber nicht auf die Annehmlichkeiten von ACPI verzichten, nur weil eine Komponente damit nicht läuft, bietet die boot.ini eine interessante Möglichkeit: Windows lässt sich auch mit mehreren parallelen HALs installieren. Bei einer entsprechend angepassten boot.ini kann beim Start der gewünschte Kernel gewählt werden.

Der Aufbau der boot.ini

Die als Hidden, System und Read-only markierte Bootkonfigurationsdatei boot.ini liegt normalerweise im Root-Verzeichnis der ersten Partition auf der ersten Festplatte. Man kann sie mit einem normalen Texteditor öffnen und bearbeiten. Um die Änderungen allerdings wieder speichern zu können, müssen Sie zunächst das Read-only-Flag entfernen.

Die Datei ist wie eine normale ini-Datei von Windows aufgebaut. Sie besteht aus den beiden Sektionen [boot loader] und [operating systems]. Unter Letzterer sind alle verfügbaren Betriebssysteme aufgeführt. Der prinzipielle Aufbau jedes Eintrags ist:

Partitionsangabe="Anzeige" <Parameter>

Aufbau eines ARC-Pfades

Die Partitionsangabe erfolgt nach den so genannten "Advanced RISC Computing"-Spezifikationen (ARC) und kann drei verschiedene Formate haben:

• multi(X)disk(Y)rdisk(Z)partition(W)\\

• scsi(X)disk(Y)rdisk(Z)partition(W)\\

• signature(X)disk(Y)rdisk(Z)partition(W)\\

Für den Typ des Bootmediums steht das erste Wort des ARC-Pfades (multi, scsi oder signature).

Das Schlüsselwort multi gibt an, dass der Bootloader sich auf das BIOS des Rechners verlassen kann, um die Systemdateien zu laden. Windows verwendet dazu den Interrupt 13. Es kann sich dabei um IDE-, ESDI-, aber auch um SCSI-Platten handeln. Wichtig ist nur, dass die angeschlossene Platte vom Interrupt 13 angesprochen werden kann. Der Wert X steht dabei für die Nummer des Controllers. Y ist normalerweise 0, und Z steht für die Nummer des Laufwerks: Nummer 0 ist Master und 1 Slave am ersten IDE-Channel, 2 ist Master und 3 Slave am zweiten IDE-Channel.

Mit der Angabe scsi als erstes Schlüsselwort veranlassen Sie Windows, den Treiber NTBOOTDD.SYS aus dem Root-Verzeichnis des Bootmediums zu laden. Das muss übrigens nicht unbedingt ein SCSI-Gerät sein. Es kann sich dabei beispielsweise auch um einen speziellen IDE-Controller handeln, der nicht durch den Interrupt 13 des BIOS behandelt wird. X steht dabei für die Nummer des Adapters, wie sie von NTBOOTDD.SYS zurückgeliefert wird. Y ist die SCSI-ID des Laufwerks und Z die logical unit number (LUN). In den allermeisten Fällen ist die LUN 0.

Das Schlüsselwort signature wird nur eingesetzt, wenn

• das BIOS die INT13-Erweiterungen nicht unterstützt und die Systempartition größer als 7,8 GByte ist oder das Partitionsende nach dem Zylinder 1024 liegt.

• das BIOS des SCSI-Host-Adapters ausgeschaltet ist, so dass die Systempartition nicht per INT-13-Aufruf angesprochen werden kann.

• bei signature die Signatur des Bootlaufwerks X ist, wie sie im MBR steht. Ntldr durchsucht dann alle Platten unabhängig vom Controller, an den sie angeschlossen sind.

Für alle drei Verfahren gleich ist die Partitionszählung, die im nächsten Abschnitt beschrieben wird.

ARC-Pfade Partitionszählung

Windows nummeriert die Partitionen auf einer Festplatte nicht sequenziell, sondern nach Typ - erst die primären Partitionen und dann die logischen. Wenn Sie also beispielsweise zunächst eine primäre und zwei logische Partitionen haben, bekommt die primäre Partition die Nummer eins, die beiden anderen Nummer zwei und drei. Befindet sich nun auf der ersten logischen Partition eine Windows-Installation, sieht der Eintrag in der boot.ini so aus:

multi(0)disk(0)rdisk(0)partition(2)\\WINNT="Windows" /fastdetect

Wenn Sie noch freien Platz auf der Platte haben und eine neue primäre Partition anlegen, bekommt diese die Nummer zwei, und die beiden logischen wandern auf die Plätze drei und vier. Die Folge: Der ARC-Pfad verweist jetzt auf die neue primäre Partition, die kein Betriebssystem enthält, und beim Booten kommt es zum berüchtigten "NTOSKRNL not found".

Der Diskmanager von Windows 2000/XP ist so intelligent, das zumindest zu erkennen und eine Warnung auszugeben. Er kann allerdings die boot.ini nicht automatisch anpassen. Das sollten Sie unbedingt vornehmen, bevor das System neu startet. Arbeiten Sie mit einem anderen Partitionierungstool, passen Sie den Pfad in der boot.ini am besten vorher an. Liegt die boot.ini auf einer NTFS-Partition, ist das nachträgliche Editieren im Fehlerfall nur mit vielen Klimmzügen und Spezialtools möglich.

Bootdisketten und versteckte Installationen

Der NT-Bootloader kann nur Installationen ansprechen, die auch in der boot.ini verzeichnet sind. Damit kann ein Systemadministrator beispielsweise auf allen Arbeitsrechnern eine Service-Installation einrichten, die von den normalen Benutzern nicht gesehen wird.

Um die spezielle Installation zu verstecken, muss der Administrator nur auf der Arbeitsstation den Eintrag aus der boot.ini löschen. Für den Zugriff benötigt er eine Bootdiskette mit der richtigen boot.ini.

Um die Bootdiskette zu erstellen, sind nur wenige Schritte notwendig:

• Formatieren Sie die Diskette unter Windows NT/2000/XP. Damit ist auf der Diskette automatisch der richtige Bootsektor.

• Kopieren Sie die Dateien Ntldr, Ntdetect.com und boot.ini auf die Diskette.

• Passen Sie die boot.ini so an, dass sie auch die "versteckte" Installation enthält.

• Wenn Sie SCSI-Treiber benötigen, kopieren Sie den Treiber (etwa AIC78XX.SYS für den Adaptec 2940) unter dem Namen ntbootdd.sys auf die Diskette.

Mit dieser Diskette können Sie dann auch die Service-Installation des Rechners starten.

Diskettenboot als Menüeintrag

Eine versehentlich im Laufwerk vergessene Diskette kann fatale Folgen haben, wenn diese mit einem Bootsektor-Virus verseucht ist. Die einfachste Lösung ist eine Änderung der Bootreihenfolge im BIOS, so dass nicht vom Diskettenlaufwerk gestartet werden kann.

Der Nachteil: Müssen Sie dennoch von Diskette booten, ist zunächst eine Änderung in den BIOS-Einstellungen erforderlich. Mit dem NT-Bootloader gibt es jedoch auch die Möglichkeit, den Systemstart von Diskette per Menü einzuleiten. Am besten verwenden Sie dazu das Programm bootpart aus dem Artikel Tools für Windows NT/2000/XP. Mit der Kommandozeile:

BOOTPART a: BOOTLINX.BIN Floppy

erzeugt das Programm einen passenden Bootsektor in der Datei bootlinx.bin und den folgenden Eintrag in der boot.ini

C:\\bootlinx.bin="Floppy"

Wenn Sie nun den Eintrag Floppy auswählen, lädt der NT-Bootloader den Bootsektor bootlinx.bin und startet darauf von Diskette. Allerdings sollten Sie dieses Verfahren nicht verwenden, wenn Sie auf Ihrer Festplatte einen Bootsektor-Virus vermuten und einen Virenscanner starten wollen. In diesem Fall ist es besser, den Umweg über das BIOS zu nehmen und dort das Diskettenlaufwerk als Startlaufwerk einzutragen.

Verschiedene Kernels und HALs booten

Wie eingangs beschrieben, kann es durchaus wünschenswert sein, auch einen ACPI-fähigen Rechner als Standard-PC zu booten. Im tecCHANNEL-Labor hat sich diese Notwendigkeit aus zwei Gründen ergeben. Zum einen wollte eine Studio-PCTV-Karte von Pinnaclesys partout nicht in einem ACPI-System funktionieren, und zum anderen verweigerte Windows XP nach einem Wechsel des Motherboards den Systemstart.

Im ersten Fall funktioniert die Karte problemlos, wenn das System als Standard-PC gestartet wird, im zweiten durchläuft Windows XP einwandfrei die Hardware-Erkennung und lässt sich danach auch wieder als ACPI-System booten.

Um eine andere Kombination aus HAL und Kernel zu starten als die Default-Installation, müssen Sie in der boot.ini lediglich die Dateinamen von Kernel und HAL als zusätzliche Parameter übergeben, indem Sie den folgenden Eintrag an die entsprechende Zeile in der Sektion [operating systems] anfügen:

/HAL=meinehal.dll /KERNEL=meinkernel.exe

Die Default-Namen für HAL und Kernel sind hal.dll und ntoskrnl.exe.

Auf der Windows-CD finden Sie die entsprechenden Dateien im Ordner i386. Von dort kopieren Sie die gewünschte Version ins System32-Verzeichnis von Windows und entpacken sie. Um also beispielsweise die HAL für einen Standard-PC mit ACPI zu kopieren, verwenden Sie die Befehle:

copy halacpi.dl_ c:\\winxp\\system32\\meinehal.dl_
expand meinehal.dl_ meinehal.dll

Dasselbe Verfahren führen Sie mit dem NT-Kernel durch. Welche Varianten von HAL und Kernel es gibt, zeigt die Tabelle auf der nächsten Seite.

Update: Kernel- und HAL-Varianten

Im Verzeichnis i386 der Windows-CD finden sich unter anderem die folgenden HAL- und Kernel-Versionen. Bei der Installation wird jeweils die von Windows ausgewählte unter dem Namen hal.dll beziehungsweise ntoskrnl.exe in das System32-Verzeichnis von Windows kopiert. Im Falle eines Systems mit PAE-Unterstützung muss der Kernel ntkrnlpa.exe heißen.

Achtung: Nach der Installation eines Service Pack sollten Sie immer auch die alternativen HALs und Kernels durch Extrahieren und Kopieren aus den Service Packs aktualisieren. Dazu entpacken Sie das Service Pack, indem Sie es mit dem Parameter -x aufrufen.

Sonstige Optionen in der boot.ini

Neben den beschriebenen Parametern /HAL und /KERNEL kennt der Bootloader noch eine Vielzahl weiterer Parameter. Die wichtigsten finden Sie in der folgenden Tabelle.

Speicher begrenzen

Gerade Arbeitsrechner, die zur Software-Entwicklung eingesetzt werden, sind oft mit viel RAM ausgestattet. Aber um die Anwendung auch unter realen Bedingungen zu testen, sollte man einen Rechner mit einer realitätsnahen RAM-Bestückung verwenden. Über den Schalter /MAXMEM in der boot.ini kann man das auch auf dem Entwicklungsrechner erledigen.

Dazu muss man lediglich eine zusätzliche Zeile aufnehmen:

multi(0)disk(0)rdisk(0)partition(1)\\WIN="Windows XP 128 RAM" /fastdetect /maxmem=128

Damit startet Windows ganz normal, außer dass jetzt weniger Speicher zur Verfügung steht und das System deutlich häufiger Daten in die Swap-Datei auslagern muss. Damit bekommen die Entwickler immerhin ein Gefühl dafür, wie ihre Anwendungen sich auf schwach bestückten Rechnern verhalten.

Neu: Speicherverwaltung mit /PAE und /3GB

Die Datacenter-Editionen von Windows 2000 Server und Windows Server 2003, sowie Windows 2003 Enterprise und Windows 2000 Advanced Server unterstützen mehr als vier GByte RAM im System. Damit Windows diesen zusätzlichen Speicher auch ansprechen kann, muss zusätzlich der Parameter /PAE in der boot.ini angegeben werden. Er ist ebenfalls notwendig, wenn Sie ein System mit NUMA-Architektur einsetzen. NUMA-Unterstützung bringen allerdings nur die Versionen von Windows Server 2003 mit. /PAE wird automatisch auf Systemen eingeschaltet, die über Hot-Add-Speichersysteme verfügen, über die der Hauptspeicher auf über vier GByte ausgebaut werden könnte. Treten Probleme auf, schalten Sie testweise PAE mittels /nopae aus.

Normalerweise teilt Windows den Adressraum für Applikationen wie folgt auf: Zwei GByte für Usermode-Programme und zwei GByte für Kernelmode-Programme. Braucht eine Applikation (etwa ein Datenbank-Server) nun mehr als diese zwei GByte, kann sie das nur erreichen, indem sie vom Betriebssystem virtuellen Speicher anfordert. Diese Vorgehensweise ist natürlich deutlich langsamer als direkter Speicherzugriff, auch wenn das Betriebssystem den virtuellen Speicher im RAM vorhält. Der Schalter /3GB sorgt dafür, dass die Aufteilung stattdessen drei GByte für Usermode- und ein GByte für Kernelmode-Programme lautet. Allerdings muss die Software mit dem Flag LargeAddressAware übersetzt und gelinkt werden, um das zusätzliche GByte nutzen zu können. Diese Option ist für Windows NT Server Enterprise ab SP3, Windows XP und Windows Server 2003 sowie Windows 2000 Advanced Server und Datacenter Server voll nutzbar. Bei anderen Versionen von NT und 2000 beschränkt er zwar den Kernelmode-Speicher auf ein GByte, aber Applikationen können trotzdem nicht mehr als zwei GByte nutzen.

Der Schalter /3GB unterstützt einen zusätzlichen Parameter /userva=Speicher_in_MByte, bei dem Sie die Größe des Usermode-Speichers selbst bestimmen können, falls Sie nicht die kompletten drei GByte für eine Applikation benötigen. Speicher_in_MByte darf eine Zahl zwischen 2048 (zwei GByte) und 3072 (drei GByte) enthalten.

multi(0)disk(0)rdisk(0)partition(1)\\WINDOWS="Windows Server 2003, Enterprise" /fastdetect /3GB

multi(0)disk(0)rdisk(0)partition(1)\\WINDOWS="Windows Server 2003, Enterprise" /fastdetect /3GB /userva=3030

Probleme mit dem Schalter /3GB können in Verbindung mit manchen Treibern auftreten, insbesondere bei Grafikkarten, die auf Onboard-RAM zurückgreifen, weil dort das eine GByte Kernelmode-Speicher nicht ausreicht.

Bei 64-Bit-Versionen von Windows benötigen Sie die beiden Schalter überhaupt nicht, da Windows automatisch sämtlichen Speicher sieht und Applikationen per Default vier GByte Usermode-Speicher erhält.

Neu: Data Execution Prevention

AMD hat in alle Prozessoren der achten Generation ein neues Sicherheits-Feature implementiert: Das so genannte NX- (No-Execution-) Bit verspricht beim Opteron und Athlon 64 einen Schutz vor einem der häufigsten Angriffsvektoren von Schadprogrammen, dem Buffer Overflow mit Code auf dem Stack. Marketing-gerecht bezeichnet AMD dieses Feature offiziell mit "Enhanced Virus Protection". Auch Intel hat diese Hardware-Erweiterung bei seinen neuen Prozessoren integriert, bezeichnet es aber als XD- (Execution-Disable-) Technologie.

Windows XP ab SP2 und Windows Server 2003 ab SP1 unterstützen dieses Feature im Rahmen der Data Execution Prevention (DEP). Normalerweise kann der Benutzer DEP über die Systemeigenschaften konfigurieren, es lässt sich allerdings mit dem Parameter /noexecute=DEP_Modus auch über die boot.ini einstellen. DEP_Modus kann einen der folgenden Werte annehmen:

alwayson: DEP ist für das Betriebssystem und alle Anwendungen eingeschaltet. Es lässt sich auch nicht über die Systemeigenschaften ausschalten.

optout: DEP ist komplett eingeschaltet, es lässt sich allerdings für einzelne Programme abschalten. (Default für Server-Versionen von Windows)

optin: DEP ist nur für Betriebssystem-Komponenten eingeschaltet, es lässt sich jedoch für einzelne Programme zusätzlich einschalten. (Default für Client-Versionen von Windows)

alwaysoff: DEP ist komplett abgeschaltet und lässt sich auch nicht selektiv für Programme einschalten. Hierbei wird zusätzlich PAE abgeschaltet. Um PAE wieder zu ermöglichen, nutzen Sie die Option /PAE.

Der Parameter /noexecute betrifft nur 32-Bit-Anwendungen. Bei 64-Bit-Anwendungen ist DEP generell eingeschaltet und lässt sich nicht abschalten. Das DEP von Windows geht über das NX-Flag noch einen Schritt hinaus.

Neu: Software-DEP

Bei Prozessoren, die das NX-Flag nicht unterstützen, bleibt zumindest noch der Software-seitige Schutz. Unter Software-DEP hat Microsoft mehrere Adresskontrollen an den Schnittstellen zum Betriebssystem zusammengefasst. Betrachtet man die Adresslage verschiedener Speicherbereiche eines Programms, ergibt sich standardmäßig folgende Reihenfolge der Blöcke: Code - Daten - Dynamische Puffer - Heap - Stack. Übergibt ein Programm bei einem Systemaufruf eine Adresse als Parameter, so kann das Betriebssystem prüfen, auf welchen der Blöcke die Adresse verweist. Stellt Windows dabei eine Inkonsistenz fest, bricht es das Programm ab.

Als wichtigstes Beispiel sei hier der Fall genannt, dass ein Programm einen Betriebssystemaufruf zur Anmeldung eines Interrupt-Vektors oder einer Callback-Routine macht. Software-DEP überprüft dabei, in welchem Block die anzumeldende Funktion abgelegt ist und akzeptiert keine Adressen aus Datenbereichen. Das Ausführen von Programmroutinen und demzufolge die Akzeptanz von Codevektoren wird somit ausdrücklich auf die Bereiche beschränkt, die der Compiler bei der Erstellung des Programms dafür angelegt hat.

Fazit

Die Möglichkeiten des NT-Bootloader sind vielfältig, leider aber ungenügend von Microsoft dokumentiert. Einige Schalter sind im DDK (Device Driver Developer Kit) dokumentiert, andere finden eine - eher zufällige - Erwähnung in der Knowledgebase. Auf der Website von Sysinternals ist die derzeit ausführlichste Beschreibung aller (bekannten) Parameter erhältlich.

Eine Warnung zum Schluss: Bevor Sie jetzt anfangen, sich eine Unzahl verschiedener Bootkonfigurationen für jede mögliche und unmögliche Gelegenheit in die boot.ini einzutragen: Die maximale Anzahl von Betriebssystem-Einträgen ist auf zehn beschränkt. Alle weiteren Einträge ignoriert Windows geflissentlich. (mha)