BOOT.INI + (logische)RAM-Rettung

Boot.ini_______Ein Beitrag des "Best-Of-Teams" (BOT)

Hinweis: Die Forensoftware bricht längere Textstücke, die kein Leerzeichen enthalten, unmotiviert, also auch mitten im Wort um. - Leerzeichen sind zwischen Anführungszeichen zB. "XP_Home" und vor einem Schalter zB. _/fastdetect erlaubt, sonst nicht. - Bei der Editierung der BOOT.INI (per NOTEPAD.EXE) ist es daher auch eine gute Idee, den Zeilenumbruch zu entfernen.

Aufbau:

1 [boot loader]
2 timeout=-1
3 default=multi(0)disk(0)rdisk(0)partition(2) \Windows
4 [operating systems]
5 multi(0)disk(0)rdisk(0)partition(2)\Windows= “Microsoft Windows XP Professional“ /fastdetect
6 multi(0)disk(0)rdisk(1)partition(1)\Winnt= “Microsoft Windows 2000 Professional“ /fastdetect
7 C:\=“Microsoft Windows 98SE“
8 C:\Boot.deb=“Debian GNU/Linux 3.1“

Das ist eine typische BOOT.INI eines Multiboot-Systems. Die Zeilennummern am Anfang dienen der Übersicht! Analyse Zeile für Zeile:

1 [boot loader]
Fehlt diese Zeile, so wird der erste Eintrag nach [Operating Systems] ohne Auswahlmenü und Wartezeit geladen.

2 timeout=-1
Timeout gibt die Wartezeit in Sekunden an, in der das Bootmenü zur Auswahl des zu startenden Betriebssystems angezeigt wird. Ist die Zeit verstrichen, wird das unter default= angegebene Betriebssystem geladen. Im Beispiel ist ein negativer Wert angegeben. Dies zwingt NTLDR dazu, ewig und drei Tage auf die Auswahl des Betriebssystems zu warten. Dummerweise kennt keines der Standardwerkzeuge von Microsoft einen negativen Wert für Timeout. Das Betrachten der BOOT.INI in Msconfig Register BOOT.INI und der beherzte Klick auf Abbrechen führen dazu, dass Timeout plötzlich auf 3 Sekunden gesetzt ist. Dasselbe gilt für den Weg über Systemeigenschaften / Erweitert / bei Starten und Wiederherstellen einmal auf Einstellungen und dann auf Abbrechen geklickt -> 3 Sekunden.

3 default=multi(0)disk(0)rdisk(0)partition(2) \Windows
In der Default-Zeile wird das nach Ablauf der Wartezeit zu startende Betriebssystem angegeben. Für Win98SE würde der Eintrag: default=c:\ lauten, für Debian default=c:\boot.deb. Bei Windows 2000 default=multi(0)disk(0)rdisk(1)partition(1)\Winnt
Fehlt die Zeile oder Default zeigt auf ein nicht unter [Operating Systems] eingetragenes OS, wird das erste unter [Operating Systems] eingetragene OS kurzerhand zum Standard erklärt.

4 [operating systems]
Eine Auflistung der vorhandenen Betriebssysteme. Dasselbe Betriebssystem kann hier auch mehrfach mit unterschiedlichen Parametern aufgeführt werden, z.B. mit der /3GB Option, wenn Datenbanken diese benötigen bzw. man hin und wieder auch spielen will.
Fehlt diese Zeile, kann man nur noch „zwischen“ dem in default angegebenen System wechseln. Im Beispiel würde NTLDR 4-mal Windows XP anbieten.
Fehlt zusätzlich noch [boot loader], ist das gleichzusetzen mit dem vollständigen Fehlen der BOOT.INI, siehe Zeile 9

5 multi(0)disk(0)rdisk(0)partition(2)\Windows= “Microsoft Windows XP Professional“ /fastdetect
Auf der 2-ten Partition der 1-ten Festplatte (dies betrifft rdisk) befindet sich im Verzeichnis \WINDOWS eine XP-Installation – anscheinend ohne SP2.

6 multi(0)disk(0)rdisk(1)partition(1) \Winnt=“Microsoft Windows 2000 Professional“ /fastdetect
Auf der 1-ten Partition der 2-ten Festplatte befindet sich im Verzeichnis \WINNT eine 2000-Installation.

7 C:\=“Microsoft Windows 98SE“
Hier ist nicht ersichtlich, auf welcher Partition sich Windows 98 befindet. Der erste Schnellschluss, dass sich Win98 auf derselben Partition wie die BOOT.INI befindet, ist ein falscher. Es befindet sich auf der 4ten Partition, die aktuelle ist mit NTFS formatiert.
Dieses wird dadurch gestartet, dass NTLDR den Win98-Bootsektor, der sich in der Datei c:\bootsect.dos befindet, in den Speicher lädt, der Startcode wird ausgeführt und übernimmt die Steuerung des Rechners.

8 C:\Boot.deb=“Debian GNU/Linux 3.1“
Wo sich die Linux-Installation befindet, ist auch hier nicht ersichtlich. Der Mechanismus ist derselbe wie bei 7, der in der Datei c:\boot.deb vorhandene Bootsektor wird in den Speicher geladen und gestartet.

9 Die Boot.ini fehlt.
In diesem Fall informiert NTLDR über eine „Fehlende oder Fehlerhafte Boot.ini“ und sucht beginnend mit der aktiven Partition nach einer Windows-NT- Installation und startet diese. Allerdings klappt das nur, wenn sich die NT- Installation mit einem multi()-Aufruf starten lässt. Sind scsi() oder gar signature()-Aufrufe notwendig, scheitert der Start ohne BOOT.INI. Im Beispiel würde XP jedoch starten.

Obiges Multiboot-System veranschaulicht – so gut es hier eben möglich ist.

Platte 1:[Linux Swap][NTFS wXP ][NTFS Daten][FAT32 w98]
8GB_____:[128MB_____][3GB______][3GB_Aktiv_][2GB______]
Platte 2:[NTFS w2000][Ext3 linux Root][Ext3 Linux home]
8GB_____:[3GB_______][3GB____________][2GB____________]
(Alle Partitionen sind Primär)


ARC-Pfade

In der BOOT.INI werden die Pfade nach der ARC-Namenskonvention (Advanced RISC Computing) definiert. - Es gibt 3 Formate:

multi(W)disk(X)rdisk(Y)partition(Z)\ %systemroot%=“Beschreibung“ /Parameter

scsi(W)disk(X)rdisk(Y)partition(Z)\ %systemroot%=“Beschreibung“ /Parameter

signature(V)disk(X)rdisk(Y)partition(Z)\ %systemroot%=“Beschreibung“ /Parameter

Zusätzlich ist noch das Starten von in Dateien gespeicherten Bootsektoren möglich. NTLDR lädt diesen Bootsektor dann in den Speicher und übergibt die Steuerung des Computers dann an den enthaltenen Startcode. Damit ist es möglich, auch MSDOS, UNIX, Linux, *BSD etc. zu starten.

Die Multi()-Syntax
Hiermit wird NTLDR angewiesen, die Systemdateien mittels SystemBIOS-Aufrufen zu laden. Dazu verwendet NTLDR Interrupt-13- Firmwareanweisungen, um zum Beispiel die NTOSKRNL.EXE zu finden. Die multi()-Syntax wird für alle Rechner verwendet, die ATA- und SCSI-Datenträger über INT-13 unterstützen.

multi(W)disk(X)rdisk(Y)partition(Z)\%systemroot%= “Beschreibung“

W -> Gibt die Nummer des Laufwerkscontrollers an, in der Regel 0. Der erste gültige Wert ist 0.
X -> Ist in der multi()-syntax immer 0
Y -> Gibt eine Festplatte an, die an den Laufwerkscontroller (W) angeschlossen ist. Bei ATA-Controllern liegt dieser Wert normalerweise zwischen 0 und 3. Bei SCSI-Adaptern je nach Typ zwischen 0 und 7 bzw. 0 und 15. Der erste gültige Wert ist 0.
Z -> Gibt die Partitionsnummer auf der Festplatte (Y) an, die am Laufwerkscontroller(W) angeschlossen ist. Alle Partitionen erhalten eine Nummer. Der erste gültige Wert ist 1.

Die Scsi()-Syntax
Hiermit wird NTLDR darüber informiert, dass der SCSI-Adapter INT-13 Aufrufe nicht unterstützt. NTLDR benutzt daher die NTBOOTDD.SYS, um die Dateien zu laden. NTBOOTDD.SYS ist eine Kopie des zum Adapter passenden Treibers.

scsi(W)disk(X)rdisk(Y)partition(Z)\%systemroot%= “Beschreibung“

W -> Gibt die Nummer des Laufwerkscontrollers an, in der Regel 0. Der erste gültige Wert ist 0.
X -> Gibt eine Festplatte an, die an den Laufwerkscontroller (W) angeschlossen ist. Bei SCSI-Adaptern je nach Typ zwischen 0 und 7 bzw. 0 und 15. Der erste gültige Wert ist 0.
Y -> Gibt die logische SCSI-Gerätenummer (LUN) des Datenträgers an, der die Startpartition enthält. Dieser Wert ist in der Regel (0). Der erste gültige Wert ist 0.
Z -> Gibt die Partitionsnummer auf der Festplatte (Y) an, die am Laufwerkscontroller(W) angeschlossen ist. Alle Partitionen erhalten eine Nummer. Der erste gültige Wert ist 1.

Die Signature()-Syntax
Kommt nur in wenigen Ausnahmefällen zum Einsatz. Typische Szenarien sind zusätzliche Laufwerkscontroller, dabei ist es unerheblich, ob es sich um ATA oder SCSI-Laufwerke handelt. Die Signature()-Syntax informiert NTLDR über den Standort des Datenträgers anhand der in (V) angegebenen Datenträgersignatur. Dabei spielt es keine Rolle, an welchem Controller die Platte angeschlossen ist.
Die Datenträgersignatur ist eine global eindeutige Kennung (Globally Unique Identifier -> GUID), die während der Textmodusphase von Windows aus Informationen des MBR generiert und auf den Datenträger geschrieben wird. Mit dieser 128-Bit-Hexadezimalzahl wird der Datenräger eindeutig gekennzeichnet. Signatur() nutzt allerdings nur die ersten 32-Bit dieser GUID, um den Datenträger zu identifizieren.

Wenn Signature() in der BOOT.INI verwendet wird, bedeutet das, dass NTBOOTDD.SYS für den Zugriff auf die Startpartition benötigt wird und eine oder beide der Bedingungen vorliegen:

• Windows befindet sich auf einer Festplattenpartition, die größer als 7,8 Gbyte ist, die Nummer des letzten Zylinders der Partition ist höher als 1024, und das BIOS der Systemfirmware oder des Bootcontrollers unterstützen keine erweiterten INT-13-Aufrufe.
  
• Das BIOS des Festplattencontrollers unterstützt keine erweiterten INT-13-Aufrufe oder die Option ist im BIOS des Adapters deaktiviert.

signature(V)disk(X)rdisk(Y)partition(Z)\ %systemroot%= “Beschreibung“

V -> Eine 32-Bit-Hexadezimalzahl, die den Datenträger eindeutig kennzeichnet
X -> Gibt eine Festplatte an, die an den Laufwerkscontroller (W) angeschlossen ist. Bei SCSI-Adaptern je nach Typ zwischen 0 und 7 bzw. 0 und 15. Der erste gültige Wert ist 0.
Y -> Dieser Wert ist stets 0, wenn die Signature()-Syntax verwendet wird.
Z -> Die Partitionsnummer auf der Festplatte die der Signatur (V) entspricht. Die erste gültige Nummer ist 1.

! Die Signature()-Syntax verlangsamt den Windows-Start mit je nach Anzahl vorhandener Controller und Festplatten erheblich. Wenn möglich sollten Festplattencontroller immer so konfiguriert werden, dass erweiterte INT-13-BIOS-Aufrufe verwendet werden. Erste Anlaufstelle ist hier die Dokumentation des Herstellers, eventuell ist auch ein Firmwareupgrade möglich. !​

Parameter der Boot.ini

Parameter werden grundsätzlich unter [Operating Systems] hinter der Beschreibung angefügt (Durch Leerzeichen getrennt)

/3GB -> Gibt an, dass das Betriebssystem einen Virtuellen Adressbereich von 3GByte für Anwendungen und von 1Gbyte für den Kernel und Executive-Komponenten reservieren kann. Kleine Bemerkung an die Optimierungsfront: Wenn die verwendeten Anwendungen nicht explizit dafür konzipiert sind, können sie den Adressbereich von 3GByte auch nicht nutzen! Spiele sind grundsätzlich nicht dafür konzipiert. Software, die diese Option benötigt, informiert in der Dokumentation explizit darüber.

/basevideo -> Erzwingt das Verwenden des Standard-VGA-Treibers mit einer Auflösung von 640x480, 16 Farben.

/baudrate= -> Gibt die Baudrate an, die für das Kerneldebugging verwendet wird. In der Regel 9600 KBit/sec für Modems und bis zu 115.200 Kbit/s bei 1394 (Firewire). Dieser Parameter erfordert auch das Vorhandensein von /debug

/bootlog -> Aktiviert die Startprotokollierung in die Datei %systemroot%\Ntbtlog.txt

/bootlogo -> Ab XP: Zeigt statt des Bootscreens eine 16 Farben Grafik (640x480), die in der Datei %systemroot%\boot.bmp abzulegen ist. Erfordert den Parameter /noguiboot, ansonsten wird der im Kernel integrierte Bootscreen angezeigt.

/break -> Zwingt den Hardware Abstraction Layer (HAL) auf den Kerneldebugger zu warten. Dieser Parameter muss zusammen mit /debug übergeben werden, ansonsten gibt es einen netten Bluescreen STOP 0x00000078 PHASE0_ EXCEPTION

/cmdcons -> Startet die Wiederherstellunskonsole von der Festplatte. Wird nicht über ARC-Pfade, sondern per Bootsektor geladen. Format: c:\cmdcons\bootsect.dat=“Beschreibung“ /cmdcons. Diese Option ist natürlich nur verfügbar, wenn die Wiederherstellungskonsole auch unter laufendem Windows installiert wurde und setzt vorraus, das sich noch eine NT-Installation auf dem System befindet. Installieren läßt sich die Wiederherstellungskonsole per Start->Ausführen-> x:\i386\winnt32 /cmdcons. Man sollte immer die Wiederherstellungskonsole des neuesten, eingesetzten Windows Installieren.

/burnmemory=Zahl -> Gibt in Megabyte die Größe des Arbeitsspeichers an, den Windows nicht verwenden kann. Siehe auch Burnmemory (vs.) Maxmem.

/clklvl -> Die Multiprozessor HAL (HALMPS.DLL) wird für eine gepufferte Systemuhr konfiguriert.

/channel=Zahl -> Gibt den Übertragungskanal der 1394-Schnittstelle (Firewire) in Verbindung mit /debugport an. Gültige Werte sind 0 – 62. Beim Standard 0 kann /channel weggelassen werden.

/crashdebug -> Lädt den Kerneldebugger beim Start. Dieser bleibt jedoch so lange inaktiv, bis eine Stoppnachricht angezeigt wird. Nützlich, wenn willkürlich Kernelfehler auftreten.

/debug -> Lädt den Kerneldebugger beim Start.

/debugport= -> Bestimmt den COM-Anschluss für das Kerneldebugging, in der Regel COM1, COM2 oder 1394. Dieser Parameter erfordert auch das Vorhandensein von /debug

/execute -> Deaktiviert die Datenausführungsverhinderung (Data Execution Protection, DEP)

/fastdetect=comx,y,z -> Deaktiviert in NTDETECT.COM die Erkennung einer seriellen Maus oder Busmaus an den angegebenen Schnittstellen. Mit der Option /fastdetect=com1 wird nur die Erkennung an COM1 deaktiviert, mehrere COM-Anschlüße werden durch Kommata getrennt angegebn, /fastdetect com1,3,4,5,6 veranlasst NTDETECT.com also dazu, nur an den COM-Anschlüssen 2, 7 und höher nach einer Maus zu suchen. Wird nur /fastdetect angegeben, sucht NTDETECT.COM überhaupt nicht nach einer seriellen Maus. Über diese Logik läst sich hervorragend philosophieren.

/hal=Dateiname -> Gibt die zu verwendene HAL an. Kann man nette Bluescreens mit produzieren.

/kernel=Dateiname -> Gibt den zu verwendenen Kernel an, zum Beispiel einen Debugging-Kernel oder zum Testen Fragwürdiger Bootscreen-Manipulationen.

/maxmem=Zahl -> Gibt in Megabyte die Größe des Arbeitsspeichers an, den Windows verwenden kann. Siehe auch Burnmemory (vs.) Maxmem

/noexecute=Parameter -> Steuert die Datenausführungsverhinderung (Data Execution Protection, DEP) Gültige Einträge sind:

• /NOEXECUTE=OPTIN Aktiviert DEP für die in Leistungsoptionen -> Datenausführungsverhinderung konfigurierten Programme
• /NOEXECUTE=OPTOUT Deaktiviert DEP für die in Leistungsoptionen -> Datenausführungsverhinderung konfigurierten Programme
• /NOEXECUTE=ALWAYSON Aktiviert DEP für alle Programme
• /NOEXECUTE=ALWAYSOFF Deaktiviert DEP.

/noguiboot -> Deaktiviert das Bild, dass die Statusanzeige für den Startvorgang anzeigt.

/nodebug -> Deaktiviert das Kerneldebugging

/nolowmem -> Deaktiviert die untersten 4 GByte RAM. Setzt den /PAE-Parameter voraus. Nur für Systeme mit mehr als 4 GByte RAM, sinnvoll nur für Diagnosezwecke.

/nopae -> Zwingt NTLDR auch auf Systemen mit mehr als 4 GByte RAM dazu, NTOSKRNL.EXE anstatt NTKRLNPA.EXE zu verwenden.

/numproc=Zahl -> Weist Windows an, nur (Zahl)-Prozessoren zu verwenden. /numproc=0 wird trotzdem als /numproc=1 interpretiert – also keine Chance, damit zu testen, wie Windows ohne CPU so läuft.

/onecpu -> Es wird nur 1 Prozessor verwendet.

/pae -> NTLDR lädt NTKRNLPA.EXE (statt NTOSKRNL.EXE, der es ermöglicht, auf 32Bit-Systemen mehr als 4GByte RAM zu adressieren.

/pcilock -> Hindert Windows daran, PCI-Geräten I/O- und IRQ-Resourcen dynamisch zuzuordnen. Ermöglicht die Konfiguration der Geräte durch das BIOS

/sos -> Zeigt den Namen jedes Gerätetreibers an, wenn der Treiber geladen (nicht gestartet!) wird. Kann nützlich sein, wenn während des Bootens beim Laden von Treibern Fehler auftreten.

/safeboot:Parameter -> Erzwingt unter Verwendung der angegebenen Parameter einen Start im abgesicherten Modus. Folgende Parameter sind verfügbar:

• minimal
• network
• minimal(alternateshell)

Natürlich kann /safeboot auch mit weiteren sinnvollen Parametern kombiniert werden. Im erweiterten Bootmenü (über F8 beim Start zu erreichen) werden folgende Kombinationen bei den Abgesichert-Optionen wirksam:

• Abgesicherter Modus -> /safeboot:minimal /sos /bootlog /noguiboot
• Abgesicherter Modus mit Netzwerktreibern -> /safeboot:network /sos /bootlog /noguiboot
• Abgesicherter Modus mit Eingabeaufforderung -> /safeboot:minimal(alternateshell) /sos /bootlog /noguiboot

/USERVA=Zahl -> Ab WindowsXP. Feintuning des /3GB Parameters. Zahl ist ein Wert zwischen 2048 und 3072 und gibt an, wieviel des virtuellen Adressbereichs für Anwendungen bereitgestellt wird. Erfordert das Vorhandensein des /3gb Parameters.

/win95 -> Nur für Triple-Boot Konfigurationen (NT, Win9x und DOS (oder ein 2tes 9x)): Sind DOS-Startdateien mit der Erweiterung .w40 vorhanden (io.w40 msdos.w40 config.w40 autoexec.w40), so werden die Aktuell vorhandenen DOS-Startdateien (io.sys msdos.sys config.sys autoexec.bat) in .dos umbenannt und die mit .w40 am Ende in .sys bzw. .bat. bevor NTLDR den vorne angegebenen Bootsektor in den Speicher lädt und ausführt.

/win95dos -> Nur für Triple-Boot Konfigurationen: Sind DOS-Startdateien mit der Erweiterung .dos vorhanden (io.dos msdos.dos config.dos autoexec.dos) so werden die aktuell vorhandenen DOS-Startdateien (io.sys msdos.sys config.sys autoexec.bat) in .w40 umbenannt und die mit .dos am Ende in .sys und .bat. bevor NTLDR den vorne angegebenen Bootsector in den Speicher lädt und ausführt. Das entspricht in etwa dem Vorgang beim Multiboot von Win9x, allerdings mit der Ausnhame, das NTLDR den Inhalt der IO.SYS nicht analysiert. Damit sind also auch 2 Installationen von Win9x dauerhaft möglich, im Gegensatz zu der 9x-Multiboot-Option, wo die IO.SYS sich nur in IO.w40 umbenennen konnte - und die restlichen Dateien gleich mit.

/YEAR=Zahl -> Weist Windows an, die im BIOS gespeicherte Jahreszahl zu ignorieren und stattdessen den angegeben Wert zu nutzen. Wer Jahr-3000 Probleme aufspüren möchte, hat hier eine bequeme Möglichkeit.

*klick*-> Best-of: Windows 2000 ___(wenn es klemmt)

 

Burnmemory (vs.) Maxmem___Ein Beitrag des "Best-Of-Teams" (BOT)

Häufig liest man den Satz: „Teste mal mit nur einem Ram“, wenn es um abstürzende Systeme geht. Dabei ist ein Aufschrauben des Rechners und wildes RAM-Wechseln ohne System eigentlich nicht notwendig.

Burnmemory „verbrennt“ am Anfang des Speichers die angegebenen MBytes, Maxmemory die hinteren.

Ein Beispiel: Es seien gegeben 3 RAM-Riegel zu jeweils 512 Mbytes. Um nun den Störenfried zu finden, erweitert man seine BOOT.INI, um einige Zeilen und kann dann systematisch durchtesten.

Die Originalzeile...
_____multi(0)disk(0)rdisk(0)partition(1)\Windows= “Microsoft Windows XP Professional“ /fastdetect

...kopiert man zu:
_____multi(0)disk(0)rdisk(0)partition(1)\Windows= “Ram 1“ /fastdetect /maxmem=512
_____multi(0)disk(0)rdisk(0)partition(1)\Windows= “Ram 2“ /burnmemory=512 /maxmem=512
_____multi(0)disk(0)rdisk(0)partition(1)\Windows= “Ram 3“ /fastdetect /burnmemory=1024
_____multi(0)disk(0)rdisk(0)partition(1)\Windows= “Ram 1 und 2“ /fastdetect /maxmem=1024
_____multi(0)disk(0)rdisk(0)partition(1)\Windows= “Ram 2 und 3“ /fastdetect /burnmemory=512

Damit sollte es immer möglich sein, den Übeltäter zu finden. Im nächsten Schritt könnte man den fehlerhaften Bereich sogar noch weiter eingrenzen. Mit etwas Glück treten Fehler - bei abgelaufener (oder wegen Entfernung des Aufklebers verwehrter) Garantie – ja nur in den letzen (oder ersten) 10 MBytes des Riegels auf. Nehmen wir im Beispiel mal an, das der 3-te RAM-Stein einen Fehler hat:

_____multi(0)disk(0)rdisk(0)partition(1)\Windows= “Ram 3“ /fastdetect /burnmemory=1280
Funktioniert das, liegt der Fehler hinten, also zwischen 256 und 512 Mbytes.

_____multi(0)disk(0)rdisk(0)partition(1)\Windows=“Ram 3“ /fastdetect /burnmemory=1408
Funktioniert das, liegt der Fehler zwischen 384 und 512 MBytes

Der Start mit 64 MBytes ist wenig spannend, also auf Maxmem wechseln:
_____multi(0)disk(0)rdisk(0)partition(1)\Windows=“Ram 3“ /fastdetect /maxmem=1472

Da man mit Maxmem und Burnmemory nur hinten und vorne Speicherbereiche stilllegen kann, muss der fehlerhafte RAM-Stein bis zum finalen Austausch durch einen neuen, entweder in Slot 1 (Fehler im vorderen Bereich) oder im letzten Slot (Fehler im hinteren Bereich) sitzen. Das kann man dann gezielt tauschen.​

*klick*-> Best-of: Windows 2000 ___(wenn es klemmt)