DE69923085T2

DE69923085T2 - Initialisieren und wiederanlaufen von betriebssystemen

Info

Publication number: DE69923085T2
Application number: DE69923085T
Authority: DE
Inventors: John Merrill
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 1998-04-30
Filing date: 1999-04-13
Publication date: 2005-12-08
Anticipated expiration: 2019-04-14
Also published as: WO1999057632A2; US6393560B1; JP3598272B2; CN1299483A; WO1999057632A3; TW428143B; JP2002513964A; KR100430468B1; AU3492299A; GB2353381B; CN1118750C; KR20010043130A; GB2353381A; DE69923085D1; EP1137987B1; ATE286606T1; EP1137987A2; GB0022497D0; US6173417B1

Description

Die Erfindung betrifft im Allgemeinen Betriebssysteme und im Besonderen das Initialisieren und Neustarten von Betriebssystemen, zum Beispiel nach dem anfänglichen Einschalten oder nach einem Absturz.
Wenn ein Computersystem anfangs eingeschaltet wird, beginnt ein Grund-Eingabe/Ausgabesystem oder "BIOS" (basic input/output system) zu arbeiten. Das BIOS steuert viele wichtige Funktionen des Arbeitsplatzrechners, so wie die Interpretation der Tastenanschläge, die Ausgabe von Buchstaben auf dem Bildschirm und die Kommunikation mit anderen Geräten. Das BIOS instruiert den Rechner typischerweise, sich jedesmal, wenn der Bediener den Rechner einschaltet, selbst zu testen. Dazu benutzt das BIOS einen Einschalteselbsttest oder "POST" (power on self test).
Wenn der Arbeitsplatzrechner startet, tritt er normalerweise als erstes in den sogenannten "Realmodus". Der Rechner greift auf einen speziellen Speicherplatz mit Programminstruktionen zu, die einen Sprungbefehl zum BIOS-Code enthalten. Anfangs instruiert das BIOS den Systemmikroprozessor, die Systemkomponenten durchzugehen und zu entschieden, ob sie korrekt arbeiten. Als nächstes werden alle Erweiterungskarten überprüft, die installiert worden sind. Danach beginnt der Mikroprozessor mit dem eigentlichen Hochfahrvorgang. Während des Hochfahrvorgangs kann der BIOS-Code den Mikroprozessor anweisen, zu einem Codeabschnitt mit Instruktionen für den Mikroprozessor zum Lesen des ersten Abschnitts des Systemdisketten-, Festplatten- oder CD-ROM-Laufwerks zu springen. Der Mikroprozessor lädt dann das Betriebssystem zum Starten tatsächlicher Rechnerabläufe.
Das Betriebssystem Windows^® ist wohl das meistverbreitete Betriebssystem für Arbeitsplatzrechner. Es ist insofern ein "offenes" System, als es an verschiedene Computersysteme und an wechselnde Hardware bei jedem gegebenen Computersystem anpassbar ist. Wegen dieser Offenheit benötigt das Windows^®-Betriebssystem zum Starten wenigstens teilweise beträchtliche Zeit. Für einige Bediener kann diese Verzögerung ein Ärgernis darstellen, und in einigen Beispielfällen kann der Startvorgang die Art und Weise, wie ein System arbeitet, störend beeinflussen.
Zum Beispiel sind Aufsatzcomputer mit Fernsehsystemen verbundene Arbeitsplatzrechner, die sowohl analoge als auch digitale Fernsehfähigkeiten und Rechnerfähigkeiten, wie Internetzugang, verbinden. Es wird erwartet, dass Bediener von Aufsatzcomputern diese Rechner als normalen Elektronikanwendungen ähnlich betrachten. Daher sind die Bediener oft nicht bereit, Verzögerungen beim Starten oder Fehlermeldungen auf ihren Fernsehbildschirmen hinzunehmen. Zum Beispiel könnte ein Bediener in einem Bild-in-Bild-System gleichzeitig ein Spiel spielen, das unter dem Windows^®-Betriebssystem läuft, und fernsehen. Bei einem Absturz des Spiels könnte eine Fehlermeldung auf dem Bildschirm erscheinen, die beim normalen Fernsehen stört. Wenigstens für eine kurze Zeit würde das Fernsehbild vom Computerabsturz beeinträchtigt sein.
In grundsätzlich allen Fällen würden Bediener von einer schnelleren Initiierung von Programmabläufen profitieren. Dies könnte in wenigstens drei Bereichen geschehen. Wenn der Rechner anfangs eingeschaltet wird, wäre ein schnellstmöglicher Beginn von Abläufen wünschenswert. Zweitens wäre es wünschenswert, den Rechner bei einem Programmfehler oder einem Absturz so schnell wie möglich neuzustarten. Ebenso könnten manche Bediener bei Auftreten von einer Vielzahl von Problemen während des Rechnerbetriebs wünschen, einfach den Rechner neuzustarten. Dadurch könnten sie vermeiden, sich mit einem Problem auseinanderzusetzen und die Quelle des Problems zu identifizieren.
Gängige Computersysteme haben einige Fähigkeiten zum Beschleunigen der Initiierung des Computersystems. Zum Beispiel ist die Nutzung einer "Schnell an (fast on)"-Fähigkeit bekannt, die die ganze oder einen Teil der POST-Routine umgeht. Ebenso haben einige Laptops eine Unterbrechung/Wiederaufnahmefunktion. Wenn er will, kann der Bediener einen Unterbrechungsknopf drücken, und alle Einstellungen des Computers werden gespeichert. Wenn der Computer danach hochgefahren wird, erkennt der Computer, dass eine Unterbrechung eingetreten war, und nimmt sofort Abläufe exakt dort wieder auf, wo der Computer zuvor aufgehört hat. Zusätzlich arbeiten einige Computer in einem "Immer an"-Modus, wobei ein Systemneustart außer bei einem Problem nie notwendig ist. Beispielsweise wird Windows^®98 eine Fortgeschrittene Konfigurations- und Energieschnittstellenfunktion (Advanced configuration and power interface function, ACPI-Funktion) haben, welche einem Computersystem ähnlich ist, das nie ausgeschaltet wird. Einige einfache Computersysteme, so wie persönliche Datenassistenten (PDA, personal data assistant), nutzen ein sogenanntes Echtzeitbetriebssystem (RTOS, real time operating system), um einen schnellen Start des Computers zu ermöglichen.
Andere Methoden, die das Wiederherstellen oder Neustarten eines Betriebssystems betreffen, sind in EP-A-838 753, EP-A- 516 159 und US-A-5 325 532 offenbart.
In "Fast DOS Soft Boot", IBM Technical Disclosure Bulletin, Vol.37, Nr. 028 von Februar 1994 ist offenbart, wie ein DOS-Softboot implementiert werden kann. Ein vollständiges DOS-Systemspeicherabbild wird komprimiert und in einem erweiterten Speicher gespeichert. Ein Realmodus BIOS-CBIOS liest und lädt das gespeicherte Systemabbild auf Drücken einer Schneller-Softboot-Taste durch den Bediener hin: das Abbild wird dekomprimiert und wiederhergestellt, wenn eine Verifikation der Datenintegrität erfolgreich war. Andernfalls fährt CBIOS das System wieder von einer Diskette oder Festplatte hoch.
Ebenso offenbart EP-A-838 753 ein Computersystem, bei dem eine vollständige Kopie des Betriebssystems in einem flüchtigen Speichergerät gespeichert wird und bei Bedarf für einen Neustart eines Computers 24 verwendet wird.
US-A-5 089 058 offenbart ein Computerbackupsystem, bei dem eine dynamische Datensicherung eingebaut ist, die zum Speichern von Zustandsänderungen des Hauptcomputers von einer Adresstabelle Gebrauch macht.
Keine der oben beschriebenen Techniken hilft bei einem Programmabsturz. In jedem dieser Fälle muss wenigstens ein beträchtlicher Teil des Hochfahrvorgangs nach einem Absturz wiederholt werden. Dies kann eine beträchtliche Verzögerung nach sich ziehen und behindert die Gestaltung einer nahtlosen Erscheinung für den Systembediener. Daher besteht ein zunehmender Bedarf für Methoden, die Betriebssysteme zu schnellerem Initiieren und Neustarten befähigen, beispielsweise nach einem Absturz oder beim anfänglichen Einschalten besonders von offenen Betriebssystemen. Genauso wäre es in Verbindung mit spezialisierten Computersystemen, so wie Aufsatzcomputern, wünschenswert, normale Rechnerabläufe für den Bediener unsichtbar zu machen.
Zusammenfassung
Gemäß einem Aspekt der vorliegenden Erfindung umfasst ein Verfahren zum Verhindern eines Systemfehlers das Bilden eines Abbildes für ein Betriebssystem, das an eine spezielle Konfiguration angepasst ist. Das Abbild wird dann gespeichert. Bei Erfassung eines Programmfehlers wird das Abbild in den Systemspeicher geladen.
Kurzbeschreibung der Zeichnung
1 ist eine schematische Darstellung einer Ausführungsform der Erfindung;
2 ist ein Flussdiagramm eines schnellen Initiierungsprogrammes;
3 zeigt ein Blockdiagramm eines Computersystems, das die Ausführungsform der Erfindung aus 1 implementieren könnte;
4 ist eine detailliertere schematische Darstellung des Basisbetriebssystemabbildes aus 1;
5 ist ein Flussdiagramm für ein Programm zum Verhindern eines Systemfehlers;
6 ist eine schematische Abbildung davon, wie das Basisabbild erzeugt und verwendet wird;
7 ist ein Flussdiagramm, das eine Initiierung eines Betriebssystems gemäß einer Ausführungsform der Erfindung zeigt;
8 ist ein Flussdiagramm einer anderen Ausführungsform entsprechend 2; und
9 ist ein Flussdiagramm, das den Ablauf einer Ausführungsform der Erfindung nach einem Programmabsturz zeigt.
Detaillierte Beschreibung
In Bezug auf 1 kann ein Festplattenlaufwerk 10 eine Anzahl von Dateien für ein Betriebssystem, wie das Windows^® Betriebssystem, speichern. Typische Dateien 12 wären Bedienerdateien, Registrierungsdateien und andere Betriebssystemdateien. Eine spezielle Partition 14 stellt einen Bereich für ein neues Basisabbild 16 und ein Basisbetriebssystemabbild 18 bereit.
Das Basisbetriebssystemabbild 18 kann ein gespeichertes virtuelles Abbild sein, das bei einer schaffenden Herkunftseinrichtung für die Herstellung von Rechnern im Voraus geladen werden könnte. Das Abbild spiegelt eine Systemkonfiguration für ein Basiscomputersystem mit einem vorbestimmten Satz von Hardware- und Softwarekonfigurationsparametern wider. Diese Parameter können auf einen bestimmten Rechner anwendbar sein, wie er ursprünglich konfiguriert ist, oder es kann ein hypothetischer Konfigurationssatz sein, der genau der Konfiguration des Rechners entspricht oder nicht. Das Basisbetriebssystemabbild 18 kann zum Beispiel Anfangsregistereinstellungen, Geräteeinstellungen, Basisspeicherseitendateien und so weiter umfassen. Kurz, es schließt alles ein, was während der Laufzeit in den Speicher geladen worden ist, einschließlich zugehörigen Anwendungen und einer Bedienershell.
Grundsätzlich umfasst das Abbild alle notwendigen Parameter für ein Betriebssystem wie Windows^® zum Betreiben einer tatsächlichen oder hypothetischen Rechnerkonfiguration. Es entspricht der Information über die Register und den Speicher, die während der Betriebssystembootsequenz für die vorbestimmte Basiscomputerkonfiguration entwickelt wird. Daher ist das Abbild effektiv ein virtuelles Abbild des Betriebssystems nach dem Hochfahren mit den vorbestimmten Charakteristika, analog zu einem Konfigurationsschnappschuss. Das Abbild 18 umfasst Information über den Speicher und die Register einer tatsächlichen oder hypothetischen Basismaschine nach der Hochfahrzeit.
Beim Start wird die in der speziellen Plattenpartition 14 enthaltene Information in den Systemspeicher 22 übertragen, wie von Block 20 angedeutet. Auf diese Art und Weise ist es nicht notwendig, den normalen Betriebssystemhochfahrvorgang zu durchlaufen, weil diese Funktion für die Grundkonfiguration in der Tat im Voraus ausgeführt wurde. Als Ergebnis kann der Betriebssystembetrieb schneller begonnen werden.
Besonders bei offenen Betriebssystemen wie Windows^® kann die Hochfahrzeit wegen der Anzahl von Konfigurationen, die untersucht und gespeichert werden müssen, beträchtlich sein. In einer veranschaulichenden Ausführungsform kann die Datei, die mit dem virtuellen Abbild assoziiert ist, relativ groß sein. Beispielsweise kann in einem System mit einer großen Anzahl von unterschiedlichen Hardware- und Softwarekonfigurationseinstellungen das Abbild eine relativ große Datenmenge aufweisen. Deswegen kann die Nutzung von Funktionen mit sehr niedrigem Pegel zum Codieren der Datei wünschenswert sein, die sehr schnell gelesen werden können. Daher kann die Initiierungszeit für ein System wie das Windows^®-Betriebssystem von einer Zeitdauer in der Größenordnung einer Minute oder so auf eine Zeit in der Größenordnung von Sekunden bei gängigen Übertragungsraten von Festplatten reduziert werden.
Ein Beispiel für den Betrieb einer veranschaulichenden Ausführungsform könnte einen Aufsatzcomputer umfassen, der einen Fernsehtuner und ein Videospiel in einem Bildschirm in einer Bildschirmbildanzeige betreibt. Wenn ein Neustart des Systems notwendig wird, wäre ein nahtloses Eintreten des Übergangs wünschenswert. Und zwar wäre ein Neustart des Systems wünschenswert, ohne dass der Bediener eine signifikante Veränderung im Videospiel oder im Fernsehbild feststellt.
Durch schnelles Übertragen eine Abbildes des Betriebssystems zum Systemspeicher und Erlangen der aktuellen Einstellungen können beide Anzeigen aufrechterhalten werden. Die aktuellen Einstellungsinformationen könnten die Anwendungen (z.B. das Videospiel, den Spielstand, den Fernsehtuner und die Kanaleinstellung) umfassen.
Dieses Abbild könnte in viel kürzerer Zeit geladen werden, als zum Neustart eines offenen Betriebssystems für den Computer erforderlich wäre. Durch Übertragen des Abbildes und der Software zum Implementieren des Abbildes kann das System schnell gestartet werden, ohne in einer maßgeblichen Art und Weise auf die Erwartungen des Bedieners störend einzuwirken.
Wiederum in Bezug auf 1 umfasst die spezielle Plattenpartition 14 auch ein neues Basisabbild 16. Das Abbild 16 kann nach einem Wechsel der Software- oder Hardwarekonfiguration des Computersystems gespeichert werden. Das Computersystem kann zum automatischen Speichern dieser Veränderungen im Speicherplatz 16 eingerichtet werden, so dass das Betriebssystem unter Beachtung der neuen Software- und Hardwarekonfiguration schnell wieder initialisiert werden kann, wann immer es notwendig ist.
Dieser Ansatz ist grundsätzlich verschieden von dem, der in gängigen offenen Betriebssystemen verwendet wird. Weil diese Systeme offene Systeme sind, beginnen sie jedesmal bei einem Neustart oder einer Wieder-Initiierung des Systems mit dem Abfragen aller Einstellungen und Konfigurationen. Das dauert einige Zeit, sichert aber die Berücksichtigung einen großen Anzahl von Variationen, ohne verschiedene Betriebssysteme für verschiedene Umstände zu erfordern. Der in 1 gezeigte Ansatz funktioniert im Wesentlichen gegensätzlich. Er erfasst ein anfängliches virtuelles Abbild und passt dieses Abbild danach je nach Notwendigkeit neu an. Tatsächlich trifft er eine Annahme über eine Grundkonfiguration, speichert dieses Abbild zum Vermeiden der Notwendigkeit einer komplizierten Hochfahrsequenz, und modifiziert dieses Abbild dann, wie es durch die Entwicklung des Computersystems notwendig wird.
Ein beispielhafter Ablauf für ein schnelles Initiierungsprogramm, gezeigt in 2, beginnt mit dem Bereitstellen eines offenen Betriebssystems, wie in Block 120 angedeutet. Danach wird ein Basisabbild wie hier beschrieben gebildet und gespeichert, wie in den Blöcken 122 und 124 gezeigt. Nachdem das System hochgefahren ist (Block 126), wird das Abbild in den Speicher geladen (Block 128). Die Steuerung wird dann an das Betriebssystem übertragen, wie in Block 130 angezeigt.
Ein beispielhaftes Computersystem 23, gezeigt in 3, umfasst einen mit dem Systemspeicher 22 verbundenen Prozessor 24. Der Prozessor 24 und der Systemspeicher 22 können durch eine Brücke 26 mit einem Bus 28 verbunden sein. Der Bus 28 kann jeder konventioneller Bus sein, der in Computersystemen verwendet wird, wie der Peripheral-Component-Interconnect(PCI)-Bus. In der dargestellten Ausführungsform können Videogeräte 30, zum Beispiel ein Fernsehtuner oder ein Monitor, mit dem Bus 28 verbunden sein. Eine zweite Brücke 32 ist ebenfalls zwischen Bus 28 und einen anderen Bus 34 gekoppelt. Der Bus 34 kann ein konventioneller Extended-Industry-System-Architecture(EISA)-Bus oder jeder andere konventionelle Bus sein. In der dargestellten Ausführungsform verbindet eine Eingangs-/Ausgangsschnittstelle 36 den Bus 34 mit einer Maus 40 und einer Tastatur 38. Ebenso schließt eine Schnittstelle 42 eine Festplatte 10 an, die die vorher beschriebenen Dateien 12, 16 und 18 enthält.
Andere Computersysteme einschließlich solcher, die als Aufsatzcomputer verwendet werden, können unter Verwendung der Abbilder 16 und 18 initiiert oder neugestartet werden. Diese Geräte könnten dieselbe allgemeine Konfiguration haben wie oben beschrieben, könnten aber beispielsweise Geräte zum Bereitstellen von mehr Videofunktionen 30 haben. Die Aufsatzcomputer weisen ein Modem für Internetverbindungen auf und akzeptieren einen Bus wie einen Universal-Serial-Bus (USB) zum Anschließen wünschenswerter Peripheriegeräte wie einer Tastatur, Disketten- oder CD-ROM-Laufwerke usw. Normalerweise verwenden sie ein Fernsehgerät als Monitor.
Nun in Bezug auf 4, enthält das Basisabbild 18 einen virtuellen Gerätetreiber (VxD) 102, eine Anwendung-Programm-Schnittstelle (API) 100 und einen VxD und Ausführung 102. Die VxD API 100 kann zum Beispiel die Geräteeingangs/Ausgangssteuerungs-API sein, die mit den Windows^®-32Bit-Betriebssystemen bereitgestellt wird. Die API 100 initiiert den VxD 102 und veranlasst den VxD 102 dazu, das Basisabbild 18 oder das neue Abbild 16 zu erzeugen.
Die zugehörigen Anwendungen 106 sind kritische Programmanwendungen, die vorteilhaft in einer nahtlosen Weise sogar nach einem Absturz ablaufen. Beispielsweise in einem Aufsatzcomputer laufen die für eine digitale Fernsehfunktion verantwortlichen Anwendungsprogramme wünschenswerterweise in einer nahtlosen Art und Weise, so dass der Bediener im Fall eines Absturzes, beispielsweise bei einer Windows^®-Anwendung wie einem Spiel, den Absturz bei seinem oder ihrem digitalen Fernsehbild nicht bemerken würde. Diese zugehörigen Anwendungen 106 können mit dem Abbild 16 oder 18, der API 100 und dem VxD und Ausführung 102 geladen werden.
Der virtuelle Maschinenmanager (VMM) 104 ist ein bei Windows^®-32Bit-Betriebssystemen verfügbarer Manager. Der VxD 102 kann den VMM 104 nach Anwendungsstatusinformationen abfragen. Beispielsweise kann der VxD 102 den VMM 104 verwenden, um zu entscheiden, ob ein Absturz stattgefunden hat. Ein VMM-Befehl kann eingehakt werden, um festzustellen, ob eine allgemeine Schutzverletzung oder eine Programmfehleranzeige ausgegeben wurde, was die Entdeckung eines Absturzes anzeigt.
Das Register 112 ist eine Zustandsdatenbank, so wie die Windows^®-Registrierung. Die Registrierung 112 ist nicht Teil des Abbildes 16 oder 18, sondern stellt die neuesten Informationen über die Hardware- und Softwarekonfigurationen bereit. Sie wird vom Abbild 18 verwendet, um das System (nach einem Absturz) mit allen Einstellungen zurückzubringen, die direkt vor dem Absturz existierten. In anderen Worten können bei der Wiederherstellung des Systems die letzten Einstellungen unter Verwendung von durch die zugehörigen Anwendungen 106 von der Registrierung 112 erhaltenen Informationen abgerufen werden. Zum Beispiel kann bei einer Aufsatzcomputeranwendung der beim Absturz gesehene Fernsehkanal von der Registrierung 112 erhalten werden.
Der gemeinsame Speicher 110 ermöglicht dem Basisabbild 18, mit dem Systemmanagementmodus(SMM)speicher 108 zu kommunizieren. Wie in 4 angedeutet, läuft der SMM in einem geschützten Systemmanagementspeicherbereich. Dieser Bereich existiert im Ring 0 und ist stark geschützt. Daher können der VxD und die Ausführung 102 eventuell nicht direkt auf den SMM-Speicher 108 zugreifen. Auf einen gemeinsamer Speicher 110 wird von VxD 102 zugegriffen. Der gemeinsame Speicher kann vorteilhaft dem Betriebssystem, so wie dem Windows^®-Betriebssystem, unbekannt sein. Wenn der gemeinsame Speicher 110 nicht speicherkonform zum Betriebssystem ist, kann das Betriebssystem nicht auf ihn zugreifen. Jedoch kann der VxD 102 auf den Speicher 110 zugreifen, um Kommunikation zwischen dem Systemmanagementmodusspeicher 108 und dem VxD und Ausführung 102 zuzulassen.
Ein Programm zum Verhindern von Systemversagen, gezeigt in 5, beginnt mit dem Bilden eines Abbildes einer Grundkonfiguration, wie in Block 132 angezeigt. Das Abbild wird gespeichert (Block 134). Wenn ein Programmfehler entdeckt wird (Raute 136), wird das Abbild geladen (Block 138).
Nun in Bezug auf 6, wird das Abbild 16 oder 18 durch die Ausführung 102 erzeugt. Der VxD und Ausführung 102 werden an einem Punkt aufgerufen, an dem die zugehörigen Anwendungen und die Bedienershell geladen und zum Abfragen des VxD API 100 nach einem Aufwachsignal bereit sind. Das Abbild kann den vollständigen Speicherzustand der Maschine einschließlich Hardwareregistern des Prozessors und der Geräte enthalten, zusammen mit einigen Systemdateien. Das Abbild kann in der Computerherstellungsanlage erzeugt werden, aber neue Abbilder können durch denselben VxD-Aufruf erzeugt werden, beispielsweise bei einer Änderung der Systemkonfiguration. Beispielsweise wäre das Speichern eines neuen Abbildes wünschenswert, wenn eine neue zugehörige Anwendung hinzugefügt werden würde.
Wenn gewünscht wird, das Abbild zum Beispiel nach einem Systemabsturz wiederherzustellen, lädt der SMM das Abbild in den Systemspeicher 22 und gibt die Steuerung an den VxD 102 weiter, wie in Block 108 angezeigt. Der VxD 102 vervollständigt die Wiederherstellung und kehrt dann von dem Eintrag in der API 100, wo er aufgerufen wurde, zurück. Die zugehörigen Anwendungen 106 sind dann bereit zum Einsatz und dürfen weiterlaufen. Sie fragen jeweils den VxD und Ausführung 102 durch die API 100 ab, wie von den Pfeilen "A" angedeutet, stellen fest, dass sie wach sind, und rufen ihre Konfigurationszustände ab. Dadurch scheinen für den Bediener die zugehörigen Anwendungen nahtlos abzulaufen. Sie erscheinen quasi ununterbrochen im selben Zustand, in dem sie vor dem Crash waren.
In der Tat ist der VxD fähig, die Funktionalitäten des Kernlevels des Windows^®-Betriebssystems zu ergänzen und zu erweitern. Natürlich kann dieselbe Funktionalität auch in den Betriebssystemkern geschrieben werden, wenn man Zugang zum Betriebssystemkern hat. Durch Einsatz des VxD kann eine gewünschte Funktionalität zu existierenden Betriebssystemkernen hinzugefügt werden.
Die Verwendung des virtuellen Abbildes in Verbindung mit Betriebssysteminitiierung, veranschaulicht in 7, kann in bestimmten Ausführungsformen beginnen, nachdem das DOS (disk operating system)-Booten vervollständigt ist. Wenn gewünscht, kann eine verkürzte DOS-Bootsequenz durch Entfernen einer Vielzahl von nicht wesentlichen Abläufen initiiert werden. Beispielsweise kann die ganze oder ein Teil der POST-Routine unterdrückt werden. Wie in Block 50 gezeigt, beginnt die Initiierungssequenz mit einem schnellen DOS-Booten im Realmodus. Bei Block 52 schaltet die Bootsequenz in den geschützten Modus, und die DOS-Bootsequenz wird fortgesetzt.
Bei Block 54 beginnt die Betriebssysteminitiierungssequenz. Anfangs kann die Sequenz, wie in Schritt 56 angedeutet, in den Systemmanagementmodus schalten. Die Verwendung des Systemmanagementmodus kann vorteilhaft sein, weil er in einem stark geschützten Adressraum arbeitet. Auerdem fährt der SMM trotz einer Anzahl relativ schwerwiegender Systemfehler fort, zu operieren.
Als nächstes prüft die Betriebssysteminitiierungssequenz, ob das Betriebssystem zum erste Mal initiiert worden ist, wie in Raute 58 angezeigt. Wenn das der Fall ist, wird ein Erstes-Mal-Geladen-Flag geändert, so dass das System beim nächsten Mal weiß, dass das Betriebssystem nicht zum ersten Mal initiiert wurde (siehe Block 60).
Wurde das Betriebssystem nicht zum ersten Mal geladen, wird bei Raute 62 eine Überprüfung in einer Konfigurationsdatenbank nach irgendwelchen Veränderungen der Computerkonfiguration gegenüber der Grundkonfiguration durchgeführt. Eine Möglichkeit zum Implementieren dieser Funktion ist das Setzen eines Flags bei jedem Neustart des Systems. Die Überprüfung bei Block 62 kann dann entscheiden, ob das Flag einen Neustart anzeigt, was die Generierung eines neuen Basisabbildes nahelegt. Wenn das Flag nicht gesetzt ist, springt der Ablauf weiter, und die Ausführung 102 wird ausgeführt (Block 68). Wenn Änderungen gemacht worden sind, wird bei 64 ein neues Basisabbild generiert und bei 66 gespeichert. Das gespeicherte Abbild wird dann in den Systemspeicher 22 (Block 67) übertragen, und die Ausführung wird ausgeführt (Block 68).
Die Echtzeitausführung 102 vollführt Planung, lädt Programme und lässt sie zusammen ablaufen. Sie umfasst einige, aber nicht alle Funktionalitäten eines Echtzeitbetriebssystems (Real Time Operating System, RTOS). Ein RTOS kann auch beispielsweise externe Geräte verwalten. Daher umfasst ein RTOS eine Ausführung.
Die Echtzeitausführung 102 läuft in Ring 0 unter anderen, besser sichtbaren Prozessen ab. Sie wird zum Ermöglichen einer Ausweitung des Betriebssystemkerns verwendet, der eventuell nicht für die hier beschriebene Funktionalität zugänglich (nach der Tat) ist, weil er vorprogrammiert ist. Die Ausführungsfunktionalität könnte jedoch bei der Entwicklung eines neuen Betriebssystems in den Kern integriert werden. Die Ausführung implementiert dann die Betriebssystemfunktionalität mit der Hilfe einer speziellen Plattenpartition 14.
Die Bereitstellung des virtuellen Abbildes ist nicht nur bei der Initiierung nützlich, sondern auch bei der Vielzahl von Umständen, die einen Neustart des Betriebssystems erforderlich machen. Der wichtigste Umstand ist ein Programmfehler oder -absturz. Ein Absturz ist ein Programmfehler, der von Hardware- oder Softwareproblemen verursacht wird. Ein Programm kann in Reaktion auf eine Ausnahme, eine Endlosschleife, eine Wettbewerbssituation, einen Ressourcenmangel oder eine Speicherverletzung abstürzen.
Normalerweise schaltet der Bediener beim Absturz einer Anwendung das System aus und startet es in der Hoffnung neu, dadurch das Problem zu beheben. Ebenso könnte der Bediener einfach das Computersystem neustarten, wenn er mit einer gegebenen Situation nicht zurechtkommt, um herauszufinden, ob das Problem dadurch gelöst wird. In jedem Fall ist durch die Verwendung des virtuellen Abbildes eine schnelle und effiziente Überwindung dieser Probleme in einer nahtlosen Art und Weise möglich. Es ist insofern eine nahtlose Lösung, als der Bediener oft keine oder wenig Ahnung hat, was tatsächlich passiert ist, und vielleicht nie eine korrigierende Aktion ausführen muss.
Ein beispielhaftes Softwareprogramm zum Implementieren des oben beschriebenen Programms, gezeigt in 8, schließt den Schritt des Bildens eines Abbildes einer Basissystemkonfiguration (Block 140) mit ein. Als nächstes wird ein virtueller Gerätetreiber erstellt, wie in Block 142 angedeutet, und das in Block 140 gebildete Abbild sowie der in Block 142 erstellte Gerätetreiber werden gespeichert, was in Block 144 angezeigt wird. Wenn eine schnelle Aktivierung gewünscht wird, werden das Abbild und der virtuelle Gerätetreiber geladen, wie in Blöcken 146 und 148 dargestellt.
In Bezug auf 9 entscheidet der Kern bei Raute 70, ob ein Absturz stattgefunden hat oder nicht. Wenn der Kern in Betrieb ist und entscheidet, dass ein Absturz stattgefunden hat, kann der Kern korrigierende Aktionen vornehmen, wie in Block 72 gezeigt. Wenn der Kern nicht in Betrieb ist oder keinen Absturz ermittelt hat, wird bei Raute 74 überprüft, ob der Systemmanagementmodus den Absturz festgestellt hat.
Der Systemmanagementmodus überwacht eine Anzahl verschiedener Absturzumstände und ermittelt routinemäßig eine Vielzahl verschiedener Fehler. Andere Systemfehlerdetektoren, einschließlich der wechselnd als Herzschlagüberwachungen, Watchdog-Timer und Absturzdetektoren beschriebenen, können ebenso verwendet werden. In jedem Fall entdecken die Systeme irgendein Fehlersymptom wie ein Hängen, ein Fehlen von Busoperationen oder ein anderes System, das mit einem Absturz verbunden ist.
Wenn bei Raute 74 entweder vom Systemverwaltungmodus oder auf eine andere Weise ein Absturz entdeckt wird, wird bei Raute 76 eine Überprüfung durchgeführt, ob eine Bewältigung des Problems allein durch Schließen der Anwendung möglich ist oder nicht. Ist dies der Fall, wird die Anwendung bei Block 72 lediglich geschlossen. Der Systemverwaltungsmodus oder der andere Absturzdetektor kann einen Cache haben, der über verschiedene, möglicherweise auftretende Fehler Informationen bereitstellt. Der Cache, der auf dem Festplattenlaufwerk 10 gespeichert werden kann, stellt Informationen über die beste Art und Weise für die Behandlung dieser Fehler bereit. Gehört der Fehler zu denen, bei welchen das Problem allein durch Schließen der Anwendung bewältigt werden kann, wäre eine Ausführung dieses Ansatzes normalerweise wünschenswert.
Wenn die gespeicherte Cacheinformation nahe legt, dass ein einfaches Schließen der Anwendung nicht möglich ist, wird bei Raute 78 eine Überprüfung ausgeführt, ob die Ausführung ausgeführt werden sollte oder nicht. Wiederum wird der Cache überprüft, um zu entscheiden, ob der Einsatz des virtuellen Abbildes das Problem bewältigen wird oder nicht. Wenn nicht, geht der Ablauf weiter zu einem Reset 80, und das System wird in einer konventionellen Weise zurückgesetzt. Wenn die Cacheinformation andeutet, dass das virtuelle Abbild zum Bewältigen des Problems verwendet werden könnte, wird der VxD initiiert, wie in Block 82 angezeigt. Danach wird in Block 84 das virtuelle Abbild aufgerufen, und die Ausführung übernimmt bei 86 die Steuerung. Die Ausführung bringt das System unter Verwendung des vordefinierten virtuellen Abbildes hoch, wie es ursprünglich in das System geladen wurde, oder wie es wie zuvor beschrieben modifiziert wurde, um geänderten Systemkonfigurationen Rechnung zu tragen.
Daher kann das virtuelle Abbild eines Basisabbildes oder eines neuen Basisabbildes nicht nur die Initiierung des Betriebssystems beschleunigen, sondern auch ein nützliches Werkzeug für die Absturzbehandlung bereitstellen. Zusätzlich kann das virtuelle Abbild bei vielen Anwendungen, einschließlich des Aufsatzcomputers, normale Rechnerabläufe in einer Weise anpassen, die einen nahtlosen Eindruck beim Bediener hinterlässt. Und zwar bemerkt der Bediener vielleicht nie die mit der Initiierung verbundene Zeitverzögerung, oder der Bediener kann nach dem meisten Absturzumständen effektiv vor nachteiligen Folgen des Absturzes bewahrt werden. Beispielsweise bei Aufsatzcomputern beeinträchtigt der Absturz das normale Fernsehbild meist nicht, weil er schnell bearbeitet wird.
Während die Erfindung in Bezug auf eine begrenzte Anzahl von Ausführungsformen beschrieben wurde, wird der Fachmann zahlreiche Modifikationen und Abwandlungen annehmen. Es ist beabsichtigt, dass die beigefügten Ansprüche all solche Modifikationen und Abwandlungen abdecken, die in den Bereich der Erfindung fallen.

Claims

Verfahren zum Verhindern eines Computersystemfehlers, wobei das Computersystem einen Systemspeicher und einen Speicher aufweist, und wobei ein offenes Betriebssystem in einem solchen Computersystem implementiert ist, welches umfaßt: Bilden eines Abbildes einer speziellen Computersystemkonfiguration umfassend Parameter für das Betriebssystem, um das Computersystem zu betreiben, wobei das Abbild Information über den Speicher und die Register des Computersystems umfaßt, welche während der Betriebssystem-Bootsequenz für das Computersystem erstellt wird; Speichern des Abbildes im Speicher; Erfassen eines Fehlers eines Programms, welches auf dem Betriebssystem läuft; und wenn ein Programmfehler erfaßt wird, automatisches Laden des Abbildes in den Systemspeicher.
Verfahren nach Anspruch 1, welches ein automatisches Aktualisieren des Abbildes umfaßt, um Veränderungen der Systemkonfiguration zu berücksichtigen.
Verfahren nach Anspruch 1, welches ein Laden des Abbildes in einem geschützten Modus umfaßt.
Verfahren nach Anspruch 3, welches ein Laden des Abbildes im Systemmanagementmodus umfaßt.
Verfahren nach Anspruch 1, welches ein Bereitstellen von Information darüber umfaßt, wie verschiedene Programmfehler zu behandeln sind, und ein Prüfen der Information, wenn ein Programmfehler ermittelt wird.
Verfahren nach Anspruch 1, bei welchem ein virtueller Gerätetreiber läuft, das Abbild auf den Systemspeicher übertragen wird und eine Ausführung abläuft, welche die Steuerung von dem Kernbereich nach einem Programmfehler übernimmt.
Verfahren nach Anspruch 1, welches ein Speichern des Abbildes des Betriebssystems während des Verfahrens zur Herstellung des Computersystems umfaßt.
Verfahren nach Anspruch 1, welches ein Speichern eines virtuellen Gerätetreibers zusammen mit dem Abbild umfaßt.