DE69423151T2

DE69423151T2 - Verwendung der zuletzt gültigen Konfiguration zum Laden eines Rechnersystems

Info

Publication number: DE69423151T2
Application number: DE69423151T
Authority: DE
Inventors: Dan Alvin Hinsley; David Otto Hovel; John David Vert; Bryan M. Willman; Rita Mang Chee Wong
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 1993-07-30
Filing date: 1994-07-06
Publication date: 2000-07-06
Anticipated expiration: 2014-07-07
Also published as: CA2126950A1; JPH0756719A; DE69423151D1; EP0636972B1; US6529966B1; EP0636972A1; JP3279823B2

Description

Gebiet der Erfindung

Diese Erfindung bezieht sich im allgemeinen auf ein Verfahren und eine Vorrichtung zum Booten (Urladen) eines Computers und insbesondere auf ein Verfahren und eine Vorrichtung, welche sicherstellt, daß der Urladevorgang immer erfolgreich sein wird.

Hintergrund der Erfindung

Wenn ein Benutzer ein persönliches Computersystem startet, durchläuft das Computersystem einen komplexen Satz von Vorgängen, um sicherzustellen, daß alle seine Komponenten richtig funktionieren. Dieser Vorgang ist nur der erste Schritt in einem noch komplizierteren Vorgang, der Systemurladevorgang (d. h. das Booten) genannt wird. Das Booten des Systems aktiviert alle Komponenten des Computersystems lange genug, um ein Betriebssystem zu laden. Das Betriebssystem ist ein Computerprogramm, welches dem Computersystem erlaubt, andere Programme zu nutzen. Bevor versucht wird, das Betriebssystem zu laden, versichert sich das Computersystem, daß die Eingabe-Ausgabehardware, der Prozessor (CPU) und der Hauptspeicher des Systems alle funktionsfähig sind. Dies wird durch das Benutzen eines Einschaltselbsttestes (Power-Onself-Test, Post) erreicht.
Nachdem der Post alle Hardwarekomponenten des Computersystems überprüft hat, überprüft ein Urladeprogramm, welches in dem ROM BIOS Baustein des Computers gespeichert ist, das Laufwerk A des Computers, um festzustellen, ob das Laufwerk A eine formatierte Diskette enthält. Wenn eine formatierte Diskette in dem Laufwerk A vorhanden ist, dann lädt das Urladeprogramm den ersten Sektor der Diskette in den Speicher und führt ihn aus. Wenn keine formatierte Diskette in dem Laufwerk A vorhanden ist, dann wird der erste Sektor auf der ersten Festplatte in den Speicher geladen und ausgeführt.
Der erste Sektor der Festplatte enthält ein Programm, welches die Partitionstabelle der Festplatte liest und bestimmt, welche Partition als aktiv gekennzeichnet ist. Der erste Sektor von der aktiven Partition wird dann in den Speicher geladen und ausgeführt.
Der erste Sektor auf der aktiven Partition oder der Diskette enthält ein Programm, welches nach Dateien sucht, die die ersten Dateien des Betriebssystems umfassen. Auf den meisten persönlichen Computersystemen sind die Dateien IO.SYS und MSDOS.SYS genannt. Auf IBM-Computern heißen die zwei Dateien IO.SYS und IBMDOS.COM. Für die Zwecke dieser Diskussion wird angenommen, daß die zwei Systemdateien IO.SYS und MSDOS.SYS sind. IO.SYS stellt eine niedere Schnittstelle (low level interface) den ROM BIOS Geräteroutinen zur Verfügung. MSDOS.SYS ist das DOS-Programm selbst und stellt eine höhere Schnittstelle (high level interface) den Benutzerprogrammen zur Verfügung. Es besteht aus Dateiverwaltungsroutinen, Datenblockieren/aufheben (data blocking/deblocking) für die Diskettenroutinen und eine Vielzahl von eingebauten Funktionen, auf die leicht durch Benutzerprogramme zugegriffen werden kann. Wenn diese Funktionsroutinen durch ein Benutzerprogramm aufgerufen werden, akzeptieren sie höhere Informationen (high level information) über Register und Steuerblockinhalte, übersetzen dann die Anforderung in einen oder mehrere Aufrufe an IBMBIO.COM, um die Anforderungen zu vervollständigen.
Die Bootaufzeichnung (boot record) übernimmt die Steuerung des Computersystems und lädt die zwei Betriebssystemdateien in den Speicher. Die Datei IO.SYS enthält Erweiterungen zu dem ROM BIOS und umfaßt eine Routine, die SYSINIT genannt wird, die den Rest des Urladevorgangs des Systems verwaltet. Nachdem IO.SYS geladen wurde, wird die Bootaufzeichnung in dem Speicher durch einen anderen Programmcode ersetzt und SYSINIT übernimmt die Steuerung des Urladevorgangs des Systems. Dabei lädt SYSINIT MSDOS.SYS in den Speicher. SYSINIT durchsucht dann das Hauptverzeichnis des Computerspeichers nach einer Datei mit dem Namen CONFigurSYS. Wenn CONFigurSYS in dem Computersystem existiert, dann fordert SYSINIT, daß MSDOS.SYS die Befehle ausführt, die in der Datei CONFigurSYS sind. CONFigurSYS ist eine Datei, die durch den Computerbenutzer erzeugt wurde, und enthält Befehle, die dem Betriebssystem sagen, wie bestimmte Vorgänge zu hantieren sind, z. B. wieviele Dateien auf einmal geöffnet werden dürfen und wieviele Systempuffer zu einem Zeitpunkt benutzt werden dürfen.
CONFigurSYS enthält auch Befehle, um Gerätetreiber zu laden. Ein Gerätetreiber ist ein Programm, welches das Betriebssystem benutzt, um Hardware zu steuern, die mit dem Computersystem kommuniziert. Z. B. benutzt MSDOS einen Gerätetreiber, um zu steuern, wie Information auf eine Diskette geschrieben und von einer Diskette gelesen wird. MSDOS hat auch eingebaute Gerätetreiber für die Tastatur, den Monitor, die Festplatten und Kommunikationsanschlüsse (communication portes) des Computersystems.
Als nächstes beauftragt SYSINIT MSDOS.SYS, die Datei COMMAND.COM zu laden. Eine Funktion von COMMAND.COM ist das Hauptverzeichnis des Computerspeichers nach einer Datei mit dem Namen AUTOEXEC.BAT zu durchsuchen.
AUTOEXEC.BAT ist eine durch den Benutzer des Computers erzeugte Datei und enthält eine Serie von MS-DOS Stapeldateibefehlen (batch file commands) und/oder die Namen von Programmen, die der Benutzer laufen lassen will, jedesmal wenn das Computersystem betrieben wird. Typischerweise ist das Computersystem jetzt vollständig gebootet und fertig zum Benutzen.
Wenn jedoch neue Hardwarekomponenten zu dem Computersystem hinzugefügt werden, oder wenn die Bedürfnisse des Benutzers sich ändern, wird es notwendig, die zwei vom Benutzer erzeugten Systembootdateien CONFigurSYS und AUTOEXEC.BAT zu modifizieren. Systeme aus dem Stand der Technik erlauben dem Benutzer, CONFigurSYS Befehle oder AUTOEXEC.BAT Befehle hinzuzufügen und zu ändern, um das Computersystem entsprechend der Bedürfnisse des Benutzers zu konfigurieren. Um die CONFigurSYS Datei zu bearbeiten, wird typischerweise das MS-DOS Textverarbeitungsprogramm oder ein Textverarbeitungsprogramm, das Dateien als unformatierten Text (ASCII Text) speichert, verwendet. Sobald die Änderungen an der CONFigurSYS Datei oder der AUTOEXEC. BAT Datei beendet sind, muß der Benutzer das Computersystem neu starten, um die Änderungen zu bewirken, weil MS-DOS die CONFigurSYS Datei und die AUTOEXEC. BAT Datei nur während dem Urladevorgang (d. h. wenn das Computersystem gestartet wird) liest.
Gelegentlich werden die Änderungen an der CONFigurSYS Datei oder der AUTOEXEC. BAT Datei verursachen, daß das Computersystem "hängt" (d. h. es wird nicht gebootet). Auf eine Art, die den Benutzer daran hindert, die Systemboot dateien zu bearbeiten und deshalb zu korrigieren. Z. B. in manchen Fällen, in denen die Systembootdateien unbenutzbar sind, können die Gerätetreiber für die Festplatte des Computersystems nicht geladen werden. Deshalb kann auf die Systembootdateien, die auf der Festplatte gespeichert sind, nicht zugegriffen werden oder bearbeitet werden. Um aus dieser Sackgasse zu kommen, muß der Benutzer ein Betriebssystem wie MS-DOS von einer Diskette laden. Der Benutzer bearbeitet dann die Systembootdateien unter Verwendung des Textverarbeitungsprogramms des Betriebssystems und versucht, das Computersystem unter Verwendung der bearbeiteten Systembootdateien auf der Festplatte neu zu booten. Dieser Vorgang wird fortgeführt, bis das Computersystem erfolgreich gebootet wurde.
Europäische Patentanmeldung 0 364 127 beschreibt ein System, in dem unterschiedliche Bootprogramme von verschiedenen Eingabegeräten geladen werden können, wie z. B. von einer Festplatte und einer Diskette.
Es wäre wünschenswert, ein Computersystem zu haben, welches automatisch bootet, selbst wenn einige Konfigurationsdaten unbrauchbar geworden sind, so daß der Benutzer des Computersystems auf die Systembootdateien zugreifen kann, ohne zusätzliche Dateien von einer externen Speichervorrichtung laden zu müssen.
Es ist eine Aufgabe der Erfindung, ein Verfahren und eine Vorrichtung zur Verfügung zu stellen, die ein Computersystem booten, selbst nachdem einige Konfigurationsdaten unbrauchbar wurden.
Diese Aufgabe wird durch das Verfahren nach unabhängigem Anspruch 1 und der Vorrichtung nach unabhängigem Anspruch 10 gelöst. Bevorzugte Ausführungsformen der Erfindung sind Gegenstand der abhängigen Ansprüche.
Die Erfindung stellt ein Verfahren und eine Vorrichtung zur Verfügung zum Booten des Computersystems von einem Satz von Konfigurationsdaten, der das Computersystem zuletzt richtig gebootet hat. Die Erfindung versucht als erstes, das Computersystem von einem aktuellen Satz von Konfigurationsdaten zu booten. Wenn der Versuch erfolglos war, bootet die Erfindung automatisch das Computersystem unter Verwendung des letzten Satzes von Kofigurationsdaten, der das Computersystem erfolgreich gebootet hat und welcher vorher gespeichert war. Wenn das Booten des Computersystems unter Verwendung des letzten Satzes von Konfigurationsdaten, die das Computersystem richtig gebootet haben, erfolgreich war, macht die Erfindung einen neuen aktuellen Satz von Konfigurationsdaten, der äquivalent mit dem letzten Satz von Konfigurationsdaten ist, der das Computersystem erfolgreich gebootet hat.
Wenn der Versuch, mit dem aktuellen Satz von Konfigurationsdaten zu booten, erfolgreich war, speichert die vorliegende Erfindung ihn als den letzten Satz von Konfigurationsdaten, der das Computersystem erfolgreich gebootet hat.

Kurze Beschreibung der Zeichnungen

Fig. 1 ist ein Blockdiagramm eines Systems, welches die vorliegende Erfindung zum Booten eines Computersystems verkörpert.
Fig. 2 ist eine bevorzugte Baumstruktur des Bienenhauses des Systems (System Hive) für die Registratur der Fig. 1.
Fig. 3 ist eine bevorzugte Baumstruktur für einen Steuerungsunterschlüssel (Control Subkey) des Bienenhauses des Systems
Fig. 4 ist eine bevorzugte Baumstruktur für einen Dienstunterschlüssel (Services Subkey) des Bienenhauses des Systems.
Fig. 5 zeigt eine bevorzugte Strukur eines Knoten unter dem Dienstunterschlüssel des Bienenhauses des Systems.
Fig. 6 ist ein Flußdiagramm der BootSystem Methode für das System der Fig. 1.
Fig. 7 ist ein Flußdiagramm einer ChooseControlSet Methode für das System der Fig. 1.
Fig. 8 ist ein Flußdiagramm der InitializeRegistryMethode für das System der Fig. 1.
Fig. 9 ist ein Flußdiagramm einer LoadDeviceDrivers Methode für das System der Fig. 1.
Fig. 10 ist ein Flußdiagramm einer InitializeDeviceDrivers Methode für das System der Fig. 1.
Fig. 11 ist ein Flußdiagramm einer UpdateRegistry Methode für das System der Fig. 1.
Fig. 12 ist ein Flußdiagramm einer ManageLastKnownGoodMenu Methode für das System der Fig. 1.
Fig. 13 ist ein Flußdiagramm einer PressOn Methode für das System der Fig. 1.
Fig. 14 ist ein Flußdiagramm einer UpDateLastKnownGood Methode für das System der Fig. 1.
Fig. 15 ist ein Blockdiagamm eines bevorzugten LastKnownGood Benutzerschnittstellen Menu.

Ausführliche Beschreibung der Erfindung

Die vorliegende Erfindung stellt ein Verfahren und ein System zur Verfügung für das erfolgreiche Booten eines Computersystems 100 (Fig. 1), selbst nachdem einige Konfigurationsdaten unbrauchbar geworden sind. Für erläuternde Zwecke wird die vorliegende Erfindung als residierend in einem Windows NTTM Betriebssystem der Microsoft Corporation, Redmond, Washington beschrieben. Die Komponenten eines bevorzugten Betriebssystems 101, die alle bevorzugt in einem Computerspeicher 103 gespeichert sind, booten einen Computer 105 (d. h. "Das System") unter Verwendung der Konfigurationsdaten, die in einer Registratur 107 gespeichert sind. Bevor die Arbeitsweise der vorliegenden Erfindung im Detail erörtert wird, wird es hilfreich sein, zu verstehen, wie Konfigurationsdaten bevorzugt in dem Computersystem der Fig. 1 gespeichert sind.

Die Registratur:

Die Registratur 107 ist eine vereinheitlichte und zentralisierte Datenbank zum Speichern von Betriebssystem-, Anwendungs- und Hardwarekonfigurationsdaten. Die Registratur 107 speichert bevorzugt diese Daten in einer hierarchischen Form, welche mehrere Benutzer unterstützt. Auf diese Art eliminiert die Registratur 107 das Bedürfnis für mehrere Konfigurationsdateien, wie AUTOEXEC.BAT, CONFigurSYS und andere solche Dateien mit Konfigurationsdaten. Die Registratur 107 ist bevorzugt als ein Baum strukturiert. Der bevorzugte Baum der Registratur 107 hat den Namen: HKEY_LOCAL_MACHINE Baum 131 (welcher unten in mehr Details beschrieben ist und in Fig. 2, 3, 4 und 5 gezeigt ist). Der HKEY_LOCAL_MACHINE Baum 131 enthält Daten über das lokale Computersystem. Diese Daten umfassen Hardware- und Betriebssystem-Charakteristiken wie Bus-Typ, Systemspeicher, installierten Gerätetreiber und Bootkonfigurationsdaten (auch bekannt als Bootsteuerdaten).
Jeder der Knoten oder Schlüssel des Baums ist benannt. Jeder Schlüssel kann null oder mehr Datenelemente enthalten, die Werteinträge (value entries) genannt werden, die mit dem Schlüssel verbunden werden. Schlüssel sind analog mit Verzeichnissen während Werteinträge analog zu Dateien sind. Ein Standard Syntax, der mit der vorliegenden Erfindung benutzt wird, definiert Namen, die mit "Schrägstrich" beginnen als Schlüsselnamen, und definiert Namen, die von einem "5" gefolgt werden als Werteinträge, d. h. Attribute eines Schlüssel, wie anhand des Beispiels in Fig. 2 erläutert wird.
Physikalisch existiert die Registratur 107 als ein Satz von Dateien auf einer Festplatte (nicht gezeigt). Zum Zweck des Erzeugens der Dateien ist die Registratur 107 in Sektionen, die Bienenhaus genannt werden, aufgeteilt. Jedes Bienenhaus bildet sich direkt auf eine Datei auf der Festplatte ab.
Die Daten in dem Bienenhaus des Systems der Registratur 107 (d. h. HKEY_LOCAL_MACHINE Baum 131 System) ist in Steuersätzen (Control Sets) organisiert. Ein Steuersatz ist einfach eine Instanz von einem Satz von Systemparametern. Fig. 2 zeigt eine bevorzugte Baumstruktur des Bienenhauses des Systems. Jeder Schlüssel in dem Bienenhaus des Systems wird nun in mehr Details beschrieben.
Jeder Schlüssel, der ControlSetnnn 201 bis 203 genannt ist beschreibt eine unterschiedliche Konfiguration für den Computer 105. Jeder ControlSetnnn residiert bevorzugt in einem nicht flüchtigen Speicher. Der Klon 204 ist eine Kopie des Control-Setnnn, der momentan benutzt wird, um zu versuchen, das System zu booten, die sehr früh in dem Bootvorgang gemacht wurde, bevor irgendeine Veränderung in dem momentanen Steuersatz stattgefunden hat. Der Klon 204 ist bevorzugt in einem flüchtigen Speicher gespeichert.
Jeder ControlSetnnn Schlüssel hat zwei Unterschlüssel, einen Steuerunterschlüssel 206 (in mehr Details in Fig. 3 gezeigt) und einen Dienstunterschlüssel 207 (in mehr Details in Fig. 4 und 5 gezeigt). Der Dienstunterschlüssel 207 führt alle Gebilde auf, die durch den Bootvorgang auf dem Computer 105 geladen werden können und zum Laufen gesetzt werden können. Jeder Unterschlüsselnamen, der in Fig. 4 aufgeführt ist, beschreibt einen unterschiedlichen Gerätetreiber, der in dem Computersystem 100 installiert werden soll. Ein Gerätetreiber ist eine Softwarekomponente, die dem Computersystem 100 erlaubt, mit anderen Geräten zu kommunizieren. Z. B. ein Druckertreiber ist ein Gerätetreiber, der Computerdaten in eine Form übersetzt, die ein Drucker (nicht gezeigt) verstehen kann, der über die Eingabe/Ausgabeeinheit 125 mit dem Computersystem 100 verbunden ist. Der durchschnittliche Fachmann wird verstehen, daß unterschiedliche Computersysteme unterschiedliche Gebilde unter dem Dienstunterschlüssel 207 aufführen werden. In gleicher Weise werden Computersysteme unterschiedliche Werte den Werteinträgen, die in Fig. 4 gezeigt sind, zuweisen.
Der Steuerunterschlüssel 206 hält alle der verschiedenen Werte, die benötigt werden, um den Computer 105 zu booten. Z. B, ein Werteintrag service_group_order 301 (Fig. 3) des Steuerunterschlüssels 206 beschreibt eine Reihenfolge, in der die Gerätetreiber, die von dem Computersystem 100 benutzt werden, aufgerufen werden sollen.
Wie unten in mehr Details beschrieben wird, verhindern die ControlSetnnn Schlüssel zusammen mit dem Klon 204 unbrauchbare Konfigurationsdaten daran, einen Computer zu erzeugen, der nicht gestartet werden kann. Wenn unbrauchbare Konfigurationsdaten anfänglich das System vom Starten verhindern, sucht die vorliegende Erfindung einen Auswahlschlüssel (Select Key) 205 (unten in mehr Details beschrieben) und holt den letzten Steuersatz, der erfolgreich benutzt wurde, um den Computer 105 zu booten. Die vorliegende Erfindung benutzt dann den zurückgewonnen Steuersatz, um den Systembootvorgang zu vervollständigen.
Der Auswahlschlüssel 205 wahrt Information über die Steuersätze. Der Auswahlschlüssel 205 enthält bevorzugt die Werteinträge Current 208, Default 209, Last- KnownGood 210, Failed 211 und AutoSelect 212 (siehe Fig. 2). Current 208 enthält einen Datenwert, der einen Steuersatz darstellt, von dem der Computer 105 momentan bootet (d. h. ein Current Steuersatz 208). Default 209 enthält einen Datenwert, der einen voreingestellten Steuersatz (d. h. ein Default Steuersatz 209) identifiziert. LastKnownGood 210 enthält einen Datenwert, der einen Steuersatz identifiziert, der die Datenwerte enthält, die den Computer 105 zuletzt erfolgreich gebootet haben (d. h. ein LastKnownGood Steuersatz 210). Failed 211, falls gesetzt, identifiziert den Steuersatz, der versagt hat, als der LastKnownGood Steuersatz 210 zuletzt benutzt wurde (d. h. ein Failed Steuersatz 211). AutoSelect 212 enthält einen Datenwert, der steuert, ob ein LastKnownGood Benutzerschnittstellen Menü gezeigt wird. Das LastKnownGood Benutzerschnittstellen Menü erlaubt dem Benutzer auszuwählen, ob der Computer 105 mit dem LastKnownGood Steuersatz 210 oder mit dem Default Steuersatz 209 gebootet werden soll.
Um den Current Steuersatz 208, den Default Steuersatz 209, den LastKnownGood Steuersatz 210 oder den Failed Steuersatz 211 wiederherzustellen, (1) holt das Betriebssystem 101 den Datenwert, der jeweils in dem Werteintrag Default 209, Current 208, Failed 211 oder LastKnownGood 210 gespeichert ist, (2) formatiert diesen Datenwert als eine mit Null gefüllte dreistellige Zeichenkette (z. B. 001) und (3) hängt diese dreistellige Zeichenkette an das Ende der Zeichenkette "ControlSet", um zu dem auszuwählenden Namen des Steuersatzes zu kommen (z. B. Control- Set001).
Eine Diskussion darüber, wie die Komponenten des bevorzugten Betriebssystems 101 zusammen wirken, um den Computer 105 unter Verwendung des durch den Werteintrag LastKnownGood 210 der Registratur 107 angezeigten Steuersatz zu booten, wird helfen, die Methode und das System der vorliegenden Erfindung zu erläutern.

Allgemeiner Betrieb:

In Erwiderung auf die Anforderung eines Benutzers, die über die Eingabe/Ausgabe Einheit 125 empfangen wurde, den Computer 105 zu booten, führt der Computer 105 das BootSystem Programm 109 des Betriebssystems 101 aus, um den Systembootvorgang für den Computer 105 zu verwalten. Das Programm BootSystem 109 ruft bei seiner Ausführung auf einem Zentralprozessor (CPU) 127 ein Programm ChooseControlSet 113 auf, welches einen Satz von Konfigurationsdaten (d. h. ein Steuersatz) auswählt, mit dem der Computer 105 gebootet werden soll. Das ChooseControlSet Programm 113 wird entweder den Default Steuersatz 209 oder den LastKnownGood Steuersatz 210 der Registratur auswählen. Das BootSsystem Programm 109 ruft dann ein InitializeRegistry Programm 111 auf, weiches bei seiner Ausführung auf der CPU 127 Konfigurationsdaten für den Computer 105 wiederherstellt und die wiederhergestellten Konfigurationsdaten in der Registratur 107 speichert. Als nächstes ruft das BootSystem Programm 109 ein LoadDeviceDrivers Programm 121 auf, welches bei seiner Ausführung auf der CPU 127 versucht, einen Satz von Gerätetreibern, der in dem ausgewählten Steuersatz aufgeführt ist, zu laden und zu initialisieren. Fig. 1 zeigt einen Zustand des Systems 101, nachdem die Gerätetreiber 129 in den Computerspeicher 103 geladen wurden. Sollten irgendwelche der Gerätetreiber beim Laden oder Initialisieren versagen, dann entscheidet das LoadDeviceDrivers Programm 121, ob der momentan ausgeführte Systembootvorgang, trotz des Scheiterns den Gerätetreiber richtig zu initialisieren weiter geführt werden soll, oder ob ein neuer Systembootvorgang eingeleitet werden soll, unter Verwendung des LastKnownGood Steuersatz 210 der Registratur 107.
Wenn die Entscheidung getroffen wurde, den Computer 105 unter Verwendung des LastKnownGood Steuersatzes 210 neu zu booten, dann wird der Systembootvorgang neu eingeleitet unter Verwendung der im LastKnownGood Steuersatz 210 gespeicherten Konfigurationsdaten. Nach erfolgreichem Booten des Computers 105 unter Verwendung einer der Steuersätze, ruft das BootSystem Programm 109 das UpdateRegistry Programm 123 auf. In Erwiderung auf ein erfolgreiches Booten von dem Default Steuersatz 209 macht das UpdateRegistry Programm 123 einen neuen LastKnownGood Steuersatz 210, der mit dem Default Steuersatz 209, der den Computer 105 erfolgreich gebootet hat, gleich ist. Die UpdateRegistry Methode, in Erwiderung auf ein erfolgreiches Booten des Computers 105 unter Verwendung des LastKnownGood Steuersatzes 210, verursacht, daß der Default Steuersatz 209 auf den Current Steuersatz 208, der das System erfolgreich gebootet hat, gesetzt wird und erzeugt einen neuen LastKnownGood Steuersatz 210, der mit dem Current Steuersatz 208, der den Computer 105 erfolgreich gebootet hat, gleich ist. Auf diese Weise versichert die vorliegende Erfindung, daß der Computer 105 erfolgreich booten wird, selbst nachdem einige Konfigurationsdaten in dem Default Steuersatz 209 unbrauchbar geworden sind.

Flußdiagramme:

Fig. 6 ist ein Flußdiagramm der Methode BootSystem, welche den Systembootvorgang für den Computer 105 steuert. Die Methode BootSystem wird vorzugsweise durch das BootSystem Programm 109 ausgeführt. In Schritt 601 ruft die Methode BootSystem die Methode ChooseControlSet auf, welche einen Satz von Konfigurationsdaten (d. h. einen Steuersatz) auswählt, mit dem der Computer 105 gebootet werden soll. Die Methode ChooseControlSet wird entweder den Default Steuersatz 209 oder den LastKnownGood Steuersatz 210 der Registratur 107 auswählen. Die Methode ChooseControlSet wird in mehr Details weiter unten beschrieben und ist in Fig. 7 gezeigt. In Schritt 603 ruft die Methode BootSystem die Methode InitializeRegistry auf, welche Konfigurationsdaten für den Computer 105 wieder herstellt und speichert die wieder hergestellten Konfigurationsdaten in der Registratur 107. Die gespeicherten Konfigurationsdaten werden benutzt, um den Computer 105 zu booten. Die Methode InitializeRegistry wird unten in mehr Details beschrieben und ist in Fig. 8 gezeigt. Sobald der richtige Steuersatz ausgewählt wurde und die Registratur initialisiert wurde, ruft die Methode BootSystem in Schritt 605 die Methode LoadDeviceDrivers auf. Die Methode LoadDeviceDrivers lädt in den Computerspeicher 103 und initialisiert einen Satz von Gerätetreibern, der in dem ausgewählten Steuersatz aufgeführt ist. Wenn irgendwelche der Gerätetreiber beim Laden oder Initialisieren versagen, entscheidet die Methode LoadDeviceDrivers dann, ob der momentan ausgeführte Systembootvorgang, trotz des Scheiterns den Gerätetreiber richtig zu laden oder zu initialisieren fortgesetzt werden soll, oder ob ein neuer Systembootvorgang eingeleitet werden soll, unter Verwendung des LastKnownGood Steuersatzes 210 der Registratur 107. Die Methode LoadDeviceDrivers wird unten in mehr Details beschrieben und ist in Fig. 9 gezeigt.
Nach erfolgreichem Booten des Computers 105 unter Verwendung einer der Steuersätze, ruft die Methode BootSystem in Schritt 607 die Methode UpdateRegistry auf. Die Methode UpdateRegistry, in Erwiderung auf ein erfolgreiches Booten des Computers 105 unter Verwendung des LastKnownGood Steuersatzes 210, veranlaßt, daß der Default Steuersatz 209 auf den Current Steuersatz 208 gesetzt wird, der das System erfolgreich gebootet hat und erzeugt einen neuen LastKnownGood Steuersatz 210, der mit dem Current Steuersatz 208, der den Computer 105 erfolgreich gebootet hat, gleich ist. Die Methode UpdateRegistry, in Erwiderung auf ein erfolgreiches Booten des Computers 105 mit dem Default Steuersatz 209, erzeugt einen neuen LastKnownGood Steuersatz 210, der mit dem Current Steuersatz 208, der den Computer 105 erfolgreich gebootet hat, gleich ist. Auf diese Art versichert die vorliegende Erfindung, daß der Computer 105 erfolgreich booten wird, selbst nachdem einige Konfigurationsdaten in dem Default Steuersatz 209 unbrauchbar geworden sind. In Schritt 609 beendet die Methode BootSystem den Vorgang. Vorgänge auf dem Computer 105, die nicht mit der Methode BootSystem verwandt sind, können jedoch fortfahren.
Fig. 7 ist ein Flußdiagramm der Methode ChooseControlSet, welche einen Satz von Konfigurationsdaten (d. h. einen Steuersatz) auswählt mit dem der Computer 105 gebootet werden soll. Die Methode ChooseControlSet wird entweder den Default Steuersatz 209 oder den LastKnownGood Steuersatz 210 der Registratur 107 auswählen. Die Methode ChooseControlSet wird vorzugsweise durch das ChooseControfSet Programm 113 des Betriebssystems 101 ausgeführt.
In Schritt 701 setzt die Methode ChooseControlSet die Variable UseLastKnownGood auf den Wert Falsch. Die Variable UseLastKnownGood wird auf Wahr gesetzt, wenn der LastKnownGood Steuersatz 210 der Registratur 107 verwendet werden soll, um den Computer 105 zu booten. Die Variable UseLastKnownGood wird auf Falsch gesetzt, wenn der Default Steuersatz 209 der Registratur 107 verwendet werden soll, um den Computer 105 zu booten. In Schritt 703 holt die Methode ChooseControlSet eine LastKnownGood Umgebungsvariable (environment variable) zurück. Die Last-KnownGood Umgebungsvariable wird auf Wahr gesetzt, wenn der unmittelbar vorhergehende Versuch, den Computer 105 unter Verwendung des Default Steuersatzes 209 der Registratur 107 zu booten, versagt, ansonsten wird die LastKnownGood Umgebungsvariable auf den Wert Falsch gesetzt. Die LastKnownGood Umgebungsvariable wird vorzugsweise in einem nicht flüchtigen Speichermedium gespeichert.
In Schritt 705 bestimmt die Methode ChooseControlSet, ob der Benutzer des Computers 105 einen Einbrechschlüssel (breakin key) eingegeben hat. Der Einbruchschlüssel zeigt der Methode ChooseControlSet an, daß der Benutzer das Last-KnownGood Benutzerschnittstellen Menü sehen will, welches dem Benutzer des Computers 105 die Wahl gibt, den Computer 105 mit dem LastKnownGood Steuersatz zu booten oder den Computer 105 mit dem Default Steuersatz zu booten. In der bevorzugten Ausführungsform ist der Einbruchschlüssel die Leertaste und wird aufgerufen, durch Drücken der Leertaste. Wenn die Methode bestimmt, daß der Benutzer den Einbruchschlüssel gedrückt hat, dann zeigt die Methode ChoöseControlSet in Schritt 706 ein LastKnownGood Schnittstellen Menu. Das LastKnownGood Benutzerschnittstellen Menü ist in Fig. 15 gezeigt. Das LastKnownGood Benutzerschnittstellen Menü stellt dem Benutzer des Computers 105 Auktionen zum Booten des Computers 105 zur Verfügung. Unter den Verwendung des LastKnownGood Benutzerschnittstellen Menüs der Fig. 15, kann der Benutzer auswählen, den Computer 105 unter Verwendung des Default Steuersatzes 209 der Registratur 107 oder des LastKnownGood Steuersatzes 117 der Registratur zu booten. Nach Vollendung des Schrittes 706 ruft die Methode ChooseControlSet die Methode ManageLastKnown- Good Menu auf, welche Dateneinträge des Benutzers verarbeitet, die in Erwiderung auf die LastKnownGood Menüoptionen eingegeben wurden. Die Methode Manage- LastKnownGood wird unten in mehr Details beschrieben und ist in Fig. 12 gezeigt. Nach Vollendung des Schrittes 707 bestimmt die Methode ChooseControlSet in Schritt 709, ob die Variable UseLastKnownGood mit dem Wert Wahr gleich ist. Wenn die Variable UseLastKnownGood mit dem Wert Wahr gleich ist, dann setzt die Methode ChooseControlSet in Schritt 711 den Werteintrag Current 208 der Registratur 107 mit dem durch den Werteintrag LastKnownGood 210 der Registratur 107 angezeigten Steuersatz gleich. Auf diesem Weg wird der durch den Werteintrag LastKnownGood 210 angezeigte Steuersatz verwendet, um das System zu booten. Nach Beenden des Schrittes 711 gibt die Methode ChooseControlSet im Schritt 713 die Verarbeitungssteuerung an die Methode BootSystem der Fig. 6 zurück.
Zurückkehrend zur Beschreibung des Schrittes 709, wenn die Methode ChooseControlSet bestimmt, daß die Variable UseLastKnownGood mit dem Wert Falsch gleichgesetzt ist, dann setzt die Methode in Schritt 715 den Werteintrag Current 208 mit dem Werteintrag Default 209 gleich. Nach Vollendung des Schrittes 715 gibt die Methode ChooseControlSet in Schritt 713 die Verarbeitungssteuerung an die Methode BootSystem der Fig. 6 zurück.
Zurückkehrend zur Beschreibung des Schrittes 705, wenn der Benutzer den Einbruchschlüssel in Schritt 717 nicht gedrückt hat, bestimmt die Methode ChooseControlSet, ob die LastKnownGood Umgebungsvariable mit dem Wert Wahr gleichgesetzt ist. Wenn die LastKnownGood Umgebungsvariable mit dem Wert Wahr gleichgesetzt ist, dann fährt die Verarbeitung mit den Schritten 709, 711, 713 und 715 fort (oben beschrieben).
Zurückkehrend zur Beschreibung des Schrittes 717, wenn die LastKnownGood Umgebungsvariable mit dem Wert Wahr in Schritt 719 gleichgesetzt ist, bestimmt die Methode, ob der Werteintrag AutoSelect 212 der Registratur 107 mit dem Wert Wahr gleichgesetzt ist. Der Werteintrag AutoSelect 212 steuert, ob das LastKnown-Good Benutzerschnittstellen Menü gezeigt wird. Wenn AutoSelect 212 mit dem Wert falsch gleichgesetzt ist, dann werden die Schritte 701, 707, 708, 711, 713 und 717 wie oben beschrieben ausgeführt.
Wenn der Werteintrag AutoSelect 212 mit dem Wert Wahr gleichgesetzt ist, dann wird die Variable UseLastKnownGood in Schritt 721 auf den Wert Wahr gesetzt. Nach Vollendung des Schrittes 21 werden die Schritte 709 bis 715 wie oben beschrieben ausgeführt.
Fig. 8 ist ein Flußdiagramm der InitializeRegistry Methode, welche Konfigurationsdaten für den Computer 105 erhält und die erhaltenen Konfigurationsdaten in der Registratur 107 speichert. Die gespeicherten Konfigurationsdaten werden durch die vorliegende Erfindung benutzt, um den Computer 105 erfolgreich zu booten. Die Methode InitializeRegistry wird bevorzugt durch das InitializeRegistry Programm 111 des Betriebssystems 101 ausgeführt.
In Schritt 801 erhält die Methode InitializeRegistry Konfigurationsdaten für den Computer 105 und speichert die Konfigurationsdaten in der Registratur 107. Software Konfigurationsdaten werden von der Datei mit dem Bienenhaus des Systems gelesen und Hardware Konfigurationsdaten werden von dem System durch Berechnungen extrahiert. Die gespeicherten Konfigurationsdaten werden später benutzt, um den Computer 105 zu booten. In Schritt 803 erzeugt die Methode InitializeRegistry eine symbolische Verbindung (link) zu dem durch den Werteintrag Current 208 der Registratur 107 angezeigten Steuersatz. Eine symbolische Verbindung ist ein Weg, alle Verweise (references) auf einen bestimmten Schlüssel mit einem definierten Namen ("CurrentControlSet") in Wirklichkeit auf einen anderen Schlüssel ("ControlSetnnn") mit einem anderen Namen verweisen zu lassen. In Schritt 805 initialisiert die Methode die symbolische Verbindung durch das Erzeugen einer Verbindung von dem Schlüssel "CurrentControlSet" zu dem Schlüssel an der Wurzel (root) des ControlSetnnn Steuersatzes, der verwendet wurde, um das System zu booten. In Schritt 807 erzeugt die Methode InitializeRegistry den Klon 204 durch Kopieren des Current Steuersatzes 208 zu dem Klon 204. Nach Beenden des Schrittes 807 gibt die Methode InitializeRegistry in Schritt 809 die Verarbeitungssteuerung zurück an die Methode BootSystem (Fig. 6).
Fig. 9 ist ein Flußdiagramm der Methode LoadDeviceDrivers, welche einen Satz von Gerätetreibern, die in dem momentan zum Booten des Computers 105 verwendeten Steuersatz aufgeführt sind, in den Computerspeicher 103 lädt und initialisiert. Wenn irgendeiner der Gerätetreiber beim Laden in den Computerspeicher 103 versagt, oder zu initialisieren versagt, dann wird eine Entscheidung, den momentanen Bootvorgang fortzusetzen oder das System unter Verwendung des LastKnownGood Steuersatzes neu zu booten, getroffen. Die Methode LoadDeviceDrivers wird bevorzugt durch das LoadDeviceDrivers Programm 121 des Betriebssystems 101 ausgeführt.
In Schritt 901 holt die Methode LoadDeviceDrivers eine Liste von Gerätetreibern, die in den Computerspeicher 103 geladen werden sollen und initialisiert werden sollen, von dem durch den Werteintrag Current 208 angezeigten Steuersatz zurück. In Schritt 903 bestimmt die Methode, ob irgendwelche unverarbeiteten Gerätetreiber verbleiben. Wenn unverarbeitete Gerätetreiber verbleiben, dann lädt die Methode in Schritt 905 den ersten unverarbeiteten Gerätetreiber in den Computerspeicher 103. In Schritt 907 bestimmt die Methode, ob der Gerätetreiber beim Laden in den Computerspeicher 103 versagt hat. Wenn der Gerätetreiber richtig in den Computerspeicher 103 geladen wurde, dann ruft die Methode LoadDeviceDrivers in Schritt 909 die Methode InitializeDeviceDrivers auf, welche den in den Computerspeicher 103 geladenen Gerätetreiber initialisiert. Die Methode LoadDeviceDrivers wird unten im Detail beschrieben und ist in Fig. 10 gezeigt. Nach Vollendung des Schrittes 909 wird die Verarbeitung mit Schritt 903 fortgeführt.
Zurückkehrend zur Beschreibung des Schrittes 907, wenn der Gerätetreiber beim Laden in den Computerspeicher 103 versagt hat, dann ruft die Methode LoadDeviceDrivers in Schritt 911 die Methode PressOn auf, welche bestimmt, ob der Systembootvorgang, der momentan ausgeführt wird, fortgesetzt werden soll, trotz eines Versagens, einen Gerätetreiber richtig zu laden oder zu initialisieren, oder ob ein neuer Systembootvorgang unter Verwendung des LastKnownGood Steuersatzes 210 der Registratur 107 eingeleitet werden soll. Die Methode PressOn ist unten im Detail beschrieben und in Fig. 13 gezeigt. Nach Vollendung des Schrittes 911 bestimmt die Methode LoadDeviceDrivers in Schritt 913, ob die Variable PressOn, welche von der Methode PressOn zurückgegeben wurde, mit dem Wert Wahr gleichgesetzt ist. Wenn die Variable PressOn mit dem Wert Falsch gleichgesetzt ist, dann bootet die Methode LoadDeviceDrivers in Schritt 915 das System neu. Wenn die Methode LoadDeviceDrivers jedoch bestimmt, daß die Variable PressOn mit dem Wert Wahr gleichgesetzt ist, dann ruft die Methode LoadDeviceDrivers in Schritt 909 die Methode InitializeDeviceDrivers auf, welche den in den Computerspeicher 103 geladenen Gerätetreiber initialisiert. Die Methode InitializeDeviceDrivers ist unten im Detail beschrieben und in Fig. 10 gezeigt. Nach Vollendung des Schrittes 909 wird die Verarbeitung mit Schritt 903 fortgeführt.
Wenn in Schritt 903 die Methode LoadDeviceDrivers bestimmt, daß alle Gerätetreiber verarbeitet wurden, gibt die Methode LoadDeviceDrivers in Schritt 917 die Steuerung der Verarbeitung an die Methode BootSystem (Fig. 6) über.
Fig. 10 ist ein Flußdiagramm der Methode InitializeDeviceDrivers, welche die Gerätetreiber initialisiert, die zuvor von der Methode LoadDeviceDrivers (Fig. 9) in den Computerspeicher 103 geladen wurde. Die Methode InitializeDeviceDrivers wird bevorzugt durch das InitializeDeviceDrivers Programm 139 des Betriebssystems 101 ausgeführt.
In Schritt 1001 initialisiert die Methode InitializeDeviceDrivers den Gerätetreiber, der zuvor in den Speicher 103 geladen wurde. In Schritt 1003 bestimmt die Methode InitializeDeviceDrivers, ob der geladene Gerätetreiber versagt hat, richtig zu initialisieren. Wenn der Gerätetreiber richtig initialisiert wurde, dann gibt die Methode InitializeDeviceDrivers in Schritt 1005 die Verarbeitungssteuerung an die Methode LoadDeviceDrivers (Fig. 9) über.
Zurückkehrend zur Beschreibung des Schrittes 1003, wenn der Gerätetreiber versagt hat, richtig initialisiert zu werden, dann bestimmt die Methode InitializeDeviceDrivers in Schritt 1007, ob das Booten fortgeführt werden soll durch Aufrufen der Methode PressOn. Die Methode PressOn wird unten in mehr Details beschrieben und ist in Fig. 13 gezeigt.
Nach Vollendung des Schrittes 1007 bestimmt die Methode InitializeDeviceDrivers in Schritt 1009, ob die Variable PressOn, welche von der Methode PressOn zurückgegeben wurde, mit dem Wert Wahr gleichgesetzt ist. Wenn die Variable PressOn mit dem Wert Falsch gleichgesetzt ist, dann bootet die Methode InitializeDeviceDrivers in Schritt 1011 das System neu.
Zurückkehrend zur Beschreibung des Schrittes 1009, wenn die von der Methode PressOn zurückgegebene Variable PressOn mit dem Wert Wahr gleichgesetzt ist, dann gibt die Methode InitializeDeviceDrivers in Schritt 1005 die Verarbeitungssteuerung an die Methode LoadDeviceDrivers der Fig. 9 über.
Fig. 11 ist ein Flußdiagramm der Methode UpdateRegistry, welche, in Erwiderung auf ein erfolgreiches Booten des Computers 105 unter Verwendung des Last-KnownGood Steuersatzes 210, bewirkt, daß der Default Steuersatz 209 auf den Current Steuersatz 208 gesetzt wird, der das System erfolgreich gebootet hat und erzeugt einen neuen LastKnownGood Steuersatz 210, der mit dem Default Steuersatz 209, der den Computer 105 erfolgreich gebootet hat, äquivalent ist. In Erwiderung auf ein erfolgreiches Booten mit dem Default Steuersatz 209, erzeugt die Methode UpdateRegistry einen neuen LastKnownGood Steuersatz 210, der äquivalent zu dem Current Steuersatz 208 ist. Auf diesem Weg versichert die vorliegende Erfindung, daß der Computer 105 erfolgreich booten wird, selbst nachdem einige Konfigurationsdaten in dem Default Steuersatz 209 unbrauchbar wurden.
In Schritt 1101 ruft die Methode UpdateRegistry die Methode UpdateLastKnown-Good auf, welche den Werteintrag LastKnownGood 210 der Registratur 107 aktualisiert, um auf den Steuersatz in der Registratur 107 zu zeigen, der als letztes den Computer 105 erfolgreich gebootet hat. Die Methode UpdateLastKnownGood wird unten in mehr Details beschrieben und ist in Fig. 14 gezeigt. Nach Vollendung des Schrittes 1101 bestimmt die Methode UpdateRegistry in Schritt 1103, ob der Computer 105 soeben erfolgreich mit dem durch den Werteintrag LastKnownGood 210 der Registratur 107 angezeigten Steuersatz gebootet hat. Ein Systemboot wird bevorzugt als erfolgreich oder erfolglos betrachtet, basierend auf einem voreingestellten Satz von Kriterien. Z. B., wenn es dem Betriebssystem 101 erscheint, als hätte das System richtig gebootet, aber tatsächlich wegen einem Problem, das das Betriebssystem nicht erkennen kann (z. B. der Bildschirm ist unlesbar, weil der falsche Videomodus gesetzt ist) versagt hat, dann wird der momentane Bootvorgang als nicht erfolgreich betrachtet. In der bevorzugten Ausführungsform, jedoch, wird der Systembootvorgang als erfolgreich betrachtet, wenn zwei Kriterien erfüllt sind. Zuerst muß das System versuchen, alle relevanten Gerätetreiber zu starten. Wenn irgendein Treiber zu starten versagt, UND sein ErrorControl-Wert Severe (ernst) oder Critical (kritisch) ist, wird der Bootvorgang als NICHT gut deklariert. Jeder Gerätetreiber hat einen benannten Knoten unter dem Dienstunterschlüssel 207 des Bienenhauses des Systems und jeder Treiberknoten enthält den Werteintrag ErrorControl 401 (siehe Fig. 4). ErrorControl hat einen von vier Werten: (1) Ignore (ignorieren), (2) Normal, (3) Severe und (4) Critical. Der Wert Ignore zeigt an, daß der momentane Systembootvorgang fortgesetzt werden soll und daß, selbst wenn der Treiber zu initialisieren versagt, der Benutzer nicht von dem Versagen durch ein Pop-up Menü benachrichtigt wird. Der Wert Normal zeigt an, daß der momentane Systembootvorgang fortgesetzt werden soll. In der bevorzugten Ausführungsform wird jedoch dem Benutzer eine Nachricht gezeigt, die anzeigt, daß ein Fehler während dem Systembootvorgang aufgetreten ist. Der Wert Severe zeigt an, daß das System neu geboo tet werden sollte unter Verwendung des LastKnownGood Steuersatzes 210, außer wenn das System momentan von dem LastKnownGood Steuersatz 210 gebootet wird, in welchem Fall das momentane Booten mit dem LastKnownGood Steuersatz 210 fortgesetzt werden soll. Der Wert Critical zeigt an, daß wenn der Systembootvorgang momentan mit dem durch den Werteintrag Default 209 angezeigten Steuersatz gebootet wird, dann soll das System neu gebootet werden unter Verwendung des LastKnownGood Steuersatzes 210. Der Wert Critical zeigt auch an, daß, wenn der Systembootvorgang momentan mit dem LastKnownGood Steuersatz 210 betrieben wird, der Systembootvorgang versagt.
Zweitens muß mindestens ein Benutzer sich erfolgreich in das System einloggen. Während der Satz von Kriterien, der oben beschrieben wird, ein voreingestellter Satz von Kriterien ist, erlaubt die bevorzugte Ausführungsform dem Benutzer, einen Satz von Kriterien zum erfolgreichen Booten zu definieren, der anders als der oben beschriebenen voreingestellte Satz ist.
Wenn der Computer 105 mit dem LastKnownGood Steuersatz erfolgreich gebootet hat, dann löscht die Methode in Schritt 1105 den momentan durch den Werteintrag Failed 211 der Registratur 107 angezeigten Steuersatz. In Schritt 1107 setzt die Methode den Werteintrag Failed 211 mit dem Datenwert gleich, der in dem Werteintrag Default 209 enthalten ist. In Schritt 1109 setzt die Methode den Werteintrag Default 209 mit dem Datenwert des Werteintrags LastKnownGood 210 der Registratur 107 gleich. In Schritt 1111 gibt die Methode UpdateRegistry die Verarbeitungssteuerung an die Methode BootSystem (Fig. 6) zurück.
Zurückkehrend zur Beschreibung des Schrittes 1103, wenn der Computer 105 mit einem anderen Steuersatz, als den durch den Werteintrag LastKnownGood 210 angezeigten Steuersatz, erfolgreich bootet, dann gibt die Methode UpdateRegistry in Schritt 1111 die Verarbeitungssteuerung an die Methode BootSystem (Fig. 6) zurück.
Fig. 12 ist ein Flußdiagramm der Methode ManageLastKnownGood Menu, welche in Erwiderung auf Optionen, die in dem LastKnownGood Benutzerschnittstellen Menü dargestellt wurden, verarbeitet. Die Methode ManageLastKnownGoodMenu wird bevorzugt durch das ManageLastKnownGood Menüprogramm 133 der Fig. 1 ausge führt. In Schritt 1201 zeigt die Methode ManageLastKnownGood das LastKnown- Good Benutzerschnittstellen Menü der Fig. 15. In Schritt 1203 bestimmt die Methode, ob der Benutzer des Computers 105 eine Anforderung in Erwiderung auf die Optionen des LastKnownGood Menüs eingegeben hat, um den Computer 105 mit einem durch einen Werteintrag LastKnownGood 210 der Registratur 107 verweisten Steuersatz zu booten. Wenn der Benutzer eine Anforderung, den Computer 105 mit dem Steuersatz, der durch den Werteintrag LastKnownGood 210 verweist wird, eingegeben hat, dann setzt die Methode in Schritt 1205 die Variable UseLastKnown- Good mit dem Wert Wahr gleich. In Schritt 1207 gibt die Methode ManageLast- KnownGood Menu die Verarbeitungssteuerung an die Methode ChooseControlSet (Fig. 7) zurück.
Zurückkehrend zur Beschreibung des Schrittes 1203, wenn der Benutzer eine Anforderung in Erwiderung auf das LastKnownGood Menü eingegeben hat, um das System mit dem auf den Werteintrag Default 209 der Registratur 107 verweisten Steuersatz zu booten, dann setzt die Methode in Schritt 1209 die Variable UseLast-KnownGood mit dem Wert Falsch gleich. Nach Vollendung des Schrittes 1209 gibt die Methode ManageLastKnownGood Menu in Schritt 1207 die Verarbeitungssteuerung an die Methode ChooseControlSet (Fig. 7) zurück.
Fig. 13 ist ein Flußdiagramm der Methode PressOn, welche bestimmt, ob der momentan ausgeführte Systembootvorgang trotz des Versagens, mindestens einen Gerätetreiber richtig zu laden oder zu initialisieren, fortgesetzt werden soll, oder ob ein neuer Systembootvorgang initiiert werden soll, unter Verwendung des Last-KnownGood Steuersatzes 210 der Registratur 107. Die Methode PressOn bestimmt, ob der momentane Systembootvorgang fortgesetzt werden soll, durch Testen sowohl eines mit jedem Gerätetreiber assoziierten Werteintrags-ErrorControl 401 (Fig. 4), als auch durch Testen einer LastKnownGood Umgebungsvariable. Wenn der Error-Control des Treibers Ignore oder Normal ist, dann wird das Booten fortgeführt. Wenn der ErrorControl des Treibers Severe ist und das System mit dem Default Steuersatz 209 bootet, hat das Booten versagt und das System sollte neu gebootet werden, unter Verwendung des LastKnownGood Steuersatzes, um das Booten neu zu versuchen. Wenn ErrorControl Severe ist und das System mit dem LastKnownGood Steuersatz 210 bootet, fährt das Booten fort. Wenn ErrorControl Critical ist und das Sy stem mit dem Default Steuersatz 209 bootet, hat das Booten versagt, und das System kehrt zurück zu dem LastKnownGood Steuersatz des nächsten Bootvorgangs. Wenn ErrorControl Critical ist und das System mit dem LastKnownGood Steuersatz 210 bootet, versagt das Booten ganz. Der ErrorControl Werteintrag des Treibers wird gesetzt, wenn der Treiber installiert wird, kann aber durch Programmierung jederzeit, während das System läuft, geändert werden.
Die LastKnownGood Umgebungsvariable zeigt an, daß das System versagt hat, mit dem Default Steuersatz 209 der Registratur 107 zu booten und neu booten sollte, unter Verwendung des LastKnownGood Steuersatzes 210 der Registratur 107. Die LastKnownGood Umgebungsvariable ist bevorzugt in einem nicht flüchtigen Speicher gespeichert. Die Methode PressOn wird bevorzugt durch das PressOn Programm 135 der Fig. 1 ausgeführt.
In Schritt 1301 bestimmt die Methode PressOn, ob der Werteintrag ErrorControl mit dem Wert Ignore oder dem Wert Normal gleichgesetzt ist. Wenn der Werteintrag mit dem Wert Normal oder Ignore gleichgesetzt ist, dann setzt die Methode PressOn in Schritt 1303 die Variable PressOn mit dem Wert Wahr gleich. Nach Vollendung des Schrittes 1303 kehrt die Methode PressOn zu seinem Aufrufer (d. h. die Methode LoadDeviceDrivers der Fig. 9 oder der Methode InitializeDeviceDrivers der Fig. 10) zurück.
Zurückkehrend zur Diskussion des Schrittes 1301, wenn der Werteintrag ErrorControl nicht mit dem Wert Normal oder Ignore gleichgesetzt ist, dann bestimmt die Methode PressOn in Schritt 1307, ob der Werteintrag ErrorControl mit dem Wert Severe gleichgesetzt ist. Wenn der Werteintrag ErrorControl mit dem Wert Severe gleichgesetzt ist, dann bestimmt die Methode PressOn in Schritt 1309, ob die Last-KnownGood Umgebungsvariable mit dem Wert Wahr gleichgesetzt ist. Wenn die LastKnownGood Umgebungsvariable mit dem Wert Wahr gleichgesetzt ist, setzt die Methode PressOn in Schritt 1303 die Variable PressOn mit dem Wert Wahr gleich. In Schritt 1305 kehrt die Methode PressOn zu ihrem Aufrufer zurück.
Zurückkehrend zur Beschreibung des Schrittes 1309, wenn die LastKnownGood Umgebungsvariable mit dem Wert Falsch gleichgesetzt ist, dann setzt die Methode PressOn in Schritt 1311 die LastKnownGood Umgebung mit dem Wert Wahr gleich.
In Schritt 1313 setzt die Methode PressOn die Variable PressOn mit dem Wert Falsch gleich. Nach Vollendung des Schrittes 1313 kehrt die Methode PressOn in Schritt 1305 zu ihrem Aufrufer zurück.
Zurückkehrend zur Beschreibung des Schrittes 1307, wenn der Werteintrag Error- Control nicht mit dem Wert Severe gleichgesetzt ist, dann bestimmt die Methode PressOn in Schritt 1315, ob der Werteintrag ErrorControl mit dem Wert Critical gleichgesetzt ist. Wenn der Werteintrag ErrorControl nicht mit dem Wert Critical gleichgesetzt ist, dann setzt die Methode PressOn in Schritt 1303 die Variable PressOn mit dem Wert Wahr gleich. Nach Vollendung des Schrittes 1303 kehrt die Methode PressOn in Schritt 1305 zurück zu ihrem Aufrufer.
Zurückkehrend zur Beschreibung des Schrittes 1315, wenn der Werteintrag Error- Control mit dem Wert Critical gleichgesetzt ist, dann bestimmt die Methode PressOn in Schritt 1317, ob die LastKnownGood Umgebungsvariable mit dem Wert Wahr gleichgesetzt ist. Wenn die LastKnownGood Umgebungsvariable mit dem Wert Falsch gleichgesetzt ist, dann setzt die Methode PressOn in Schritt 1311 die Last-KnownGood Umgebungsvariable mit dem Wert Wahr gleich. In Schritt 1313 setzt die Methode die Variable PressOn mit dem Wert Falsch gleich. Nach Vollendung des Schrittes 1313 kehrt die Methode PressOn in Schritt 1305 zurück zu ihrem Aufrufer.
Zurückkehrend zur Beschreibung des Schrittes 1317, wenn die Methode bestimmt, daß die LastKnownGood Umgebungsvariable mit dem Wert Wahr gleichgesetzt ist, dann stürzt das System in Schritt 1319 ab.
Fig. 14 ist ein Flußdiagramm der Methode UpdateLastKnownGood, welche die primäre Aufgabe hat, den Werteintrag LastKnownGood 210 zurückzusetzen, um auf eine Kopie des Klons 204 zu zeigen, um den Werteintrag LastKnownGood nach einem erfolgreichen Systemboot unter Verwendung des Current Steuersatzes 208 der Registratur 107 zu aktualisieren. Die Methode UpdateLastKnownGood wird bevorzugt durch das UpdateLastKnownGood Programm 137 der Fig. 1 ausgeführt.
In Schritt 1401 kopiert die Methode UpdateLastKnownGood den Klon 204 von dem flüchtigen Speicher zu dem nicht flüchtigen Speicher. In Schritt 1403 räumt (flush) die Methode die Registratur 107. Ein Räumen der Registratur 107 zwingt alle Ände rungen an einem Bienenhaus, z. B. dem Bienenhaus des Systems der Fig. 2, seit dem letzten Räumen auf Diskette zu bringen. Das Räumen wird vorzugsweise auf solch einem Weg ausgeführt, daß entweder alle Änderungen vorkommen oder keine Änderungen vorkommen.
In Schritt 1405 löscht die Methode den Steuersatz, auf den durch den Werteintrag LastKnownGood 210 der Registratur 107 verwiesen wird. In Schritt 1407 räumt die Methode die Registratur 107. In Schritt 1409 setzt die Methode den Werteintrag LastKnownGood 210 der Registratur 107, um auf eine Kopie des Klon Steuersatzes zu zeigen, der jetzt im nicht flüchtigen Speicher untergebracht ist. In Schritt 1411 gibt die Methode UpdateLastKnownGood die Verarbeitungssteuerung an die Methode UpdateRegistry (Fig. 11) über.
Der Fachmann wird verstehen, daß andere Systemarchitekturen benutzt werden können, um die Methoden der vorliegenden Erfindung, wie sie oben beschrieben sind, zu implementieren, welche ein Netzwerk, in dem eine Vielzahl von Computern mit Dateienservern verbunden sind, um Zugriff auf Daten unter Computerbenutzern durch ein Datenkommunikationsnetzwerk zu teilen, einschließen, aber nicht darauf beschränkt sind.
Während diese Beschreibung auf Gerätetreiber gerichtet ist, wird der Fachmann erkennen, daß der Umfang der Beschreibung nicht darauf beschränkt ist, aber genauso auf Dateisysteme und Benutzermodusprogrammdienste angewendet werden kann.

Claims

1. Ein Verfahren in einem Computersystem (100) zum Booten des Computersystems (100), wobei das Verfahren ein Urladeprogramm (109) benutzt, das Urladeprogramm (109) während seiner Ausführung ein auswählbares Konfigurationsprofil (203, 206, 207) gebraucht, und die Methode folgende Schritte umfaßt:

Ausführen des Urladeprogramms (109) unter Verwendung eines ersten Konfigurationsprofils; und

wenn die Ausführung des Urladeprogramms (109) unter Verwendung des ersten Konfigurationsprofils versagt,

Laden eines zweiten Konfigurationsprofils, wobei das zweite Konfigurationsprofil bereits vorher durch das Urladeprogramm (109) benutzt wurde, um das Computersystem (100) erfolgreich zu laden, und

Ausführen des Urladeprogramms (109) unter Verwendung des geladenen zweiten Konfigurationsprofils.

2. Verfahren nach Anspruch 1, wobei das geladene zweite Konfigurationsprofil das letzte Konfigurationsprofil ist, welches durch das Urladeprogramm (109) benutzt wurde, um das Computersystem (100) erfolgreich zu booten.

3. Verfahren nach Anspruch 1 oder 2, wobei das erste und das zweite Konfigurationsprofil jeweils ein Satz von Gerätetreibern (129) ist.

4. Verfahren nach einem der Ansprüche 1 bis 3, wobei das erste und zweite Konfigurationsprofil jeweils ein Satz von Hardwaretreibern ist.

5. Verfahren nach einem der Ansprüche 1 bis 4, wobei das Urladeprogramm (109) versucht, bestimmte Gerätetreiber (129) zu laden, basierend auf dem benutzten Konfigurationsprofil, wobei das Verfahren weiterhin umfaßt: Bestimmen, daß die Ausführung des Urladeprogramms (109) unter Verwendung des ersten Konfigurationsprofils versagt, wenn ein Versuch des Urladeprogramms (109), einen Gerätetreiber (129) zu laden, versagt.

6. Verfahren nach einem der Ansprüche 1 bis 4, wobei das Urladeprogramm (109) versucht, bestimmte Gerätetreiber (129) zu initialisieren, basierend auf dem benutzten Konfigurationsprofil, wobei das Verfahren weiterhin umfaßt: Bestimmen, daß die Ausführung des Urladeprogramms (109) unter Verwendung des ersten Konfigurationsprofils versagt, wenn ein Versuch des Urladeprogramms (109) den Gerätetreiber (129) zu initialisieren, versagt.

7. Verfahren nach einem der Ansprüche 1 bis 6, wobei das zweite Konfigurationsprofil in einem andauernden Speicher gespeichert ist, wobei das Verfahren weiterhin umfaßt: falls die Ausführung des Urladeprogramms (109) unter Verwendung des ersten Konfigurationsprofils erfolgreich ist, Ersetzen des zweiten Konfigurationsprofils, welches in dem andauernden Speicher gespeichert ist, mit dem ersten Konfigurationsprofil.

8. Verfahren nach einem der Ansprüche 1 bis 7, weiterhin umfassend: Laden des ersten Konfigurationsprofils.

9. Verfahren nach einem der Ansprüche 1 bis 8, weiterhin umfassend: dynamisches Bestimmen des ersten Konfigurationsprofils.

10. Eine Vorrichtung zum Booten eines Computersystems (100) mit einem Urladeprogramm (109), wobei das Urladeprogramm (109) in seiner Ausführung ein auswählbares Konfigurationsprofil (203, 206, 207) verwendet, umfassend:

Einrichtung (127) zum Ausführen des Urladeprogramms (109) unter Verwendung eines ersten Konfigurationsprofils; und

Einrichtung (113, 127) zum Laden eines zweiten Konfigurationsprofils, wobei das zweite Konfigurationsprofil bereits vorher durch das Urladeprogramm (109) benutzt wurde, um das Computersystem (100) erfolgreich zu booten, und Ausführen des Urladeprogramms (109) unter Verwendung des geladenen zweiten Konfigurationsprofils, wenn die Ausführung des Urladeprogramms (109) unter Verwendung des ersten Konfigurationsprofils versagt.

11. Vorrichtung nach Anspruch 10, wobei das geladene zweite Konfigurationsprofil das letzte Konfigurationsprofil ist, welches durch das Urladeprogramm (109) zum erfolgreichen Booten des Computersystems (100) benutzt wurde.

12. Vorrichtung nach Anspruch 10 oder 11, wobei das erste und zweite Konfigurationsprofil jeweils ein Satz von Gerätetreibern (129) ist.

13. Vorrichtung nach einem der Ansprüche 10 bis 12, wobei das erste und zweite Konfigurationsprofil jeweils ein Satz von Hardwaretreibern ist.

14. Vorrichtung nach einem der Ansprüche 10 bis 13, wobei das Urladeprogramm (109) versucht, bestimmte Gerätetreiber (129), basierend auf das benutzte Konfigurationsprofil zu laden, weiterhin umfassend: Einrichtung (121, 127) zum Bestimmen, daß die Ausführung des Urladeprogramms (109) unter Verwendung des ersten Konfigurationsprofils versagt, wenn ein Versuch des Urladeprogramms (109), einen Gerätetreiber (129) zu laden, versagt.

15. Vorrichtung nach einem der Ansprüche 10 bis 13, wobei das Urladeprogramm (109) versucht, bestimmte Gerätetreiber (129), basierend auf das benutzte Konfigurationsprofil zu initialisieren, weiterhin umfassend: Einrichtung (127, 139) zum Bestimmen, daß die Ausführung des Urladeprogramms (109) unter Verwendung des ersten Konfigurationsprofils versagt, wenn ein Versuch des Urladeprogramms (109), einen Gerätetreiber (129) zu initialisieren, versagt.

16. Vorrichtung nach einem der Ansprüche 10 bis 15, wobei das zweite Konfigurationsprofil in einem andauernden Speicher gespeichert ist, weiterhin umfassend: Einrichtung (127, 137) zum Ersetzen des zweiten Konfigurationsprofils, welches in einem andauernden Speicher gespeichert ist, mit dem ersten Konfigurationsprofil, falls die Ausführung des Urladeprogramms (109) unter Verwendung des ersten Konfigurationsprofils erfolgreich ist.

17. Vorrichtung nach einem der Ansprüche 10 bis 16, weiterhin umfassend: Einrichtung zum Laden des ersten Konfigurationsprofils.

18. Vorrichtung nach einem der Ansprüche 10 bis 17, weiterhin umfassend: Einrichtung (111, 127) zum dynamischen Bestimmen des ersten Konfigurationsprofils.