page_fault_in_nonpaged_area

[nova2004de]

ch habe folgendes Problem ich habe mit Partition magic mist gebaut also um es gurz zu fassen ich habe versucht Partition c also windos zu loschen und die große zu undern also ganz blöde Sache nach der Formatierung kam natürlich so eine schöne blaue seite mit der Meldung page_fault_in_nonpaged_area
Technische Info...
Xxx STOP ;0X00000050.....
Xxx ntfs.sys-addressf.....usw
Seit dem kann ich mit der festplatte nichts mehr anfangen sobald ich sie anschliche kommt die blaue seite.

[Schwermetaller]

Klingt eigentlich gar nicht so schlimm. Du müsstest jetzt eben nur von einer CD starten, die ein Betriebssystem enthält und dieses neu installieren. Während der Installation kannst du dann ja auch Partitionsgröße und -anzahl festlegen. Das Windows nicht mehr von einer veränderten Partition starten mag und dabei diese Fehlermeldung ausgibt, ist nichts unbedingt ungewöhnliches.

Also: BIOS Einstellungen überprüfen, Windows-CD einlegen, von CD starten, die Partitionen evtl. neu festlegen und das Betriebssystem installieren. Sollte so funktionieren.

[nova2004de]

Etwas habe ich vergessen also ich hate drei  Partition  c win d leer e halb voll e wollte ich so lassen c und d wollte ich verändern, jetzt ist es noch nicht mall möglich in abgesicherten Modus mit der festplatte zu arbeiten und cd  und Bios habe ich schon versucht  so bald ich die festplatte an schlissen  kommt die blau seite, und ich mochte die daten nicht verlieren die auf e sind wen die noch da sind?

[Schwermetaller]

jetzt ist es noch nicht mall möglich in abgesicherten Modus mit der festplatte zu arbeiten

Windows wird nicht mehr mit dir arbeiten wollen, da du seine Wohnung total demoliert hast.

Mal im ernst: die blaue Seite kommt auch, wenn du von CD startest? Ganz sicher? Dann wird es etwas schwieriger. Da deine Daten auf E: wahrscheinlich erstmal absolute Priorität haben, würde ich vorschlagen, eine Datenrettungsaktion mittels Knoppix oder Kanotix zu starten. Beide Betriebssysteme können von CD gestartet werden und haben im Regelfall ein Programm namens K3b an Board. Mit diesem kannst du deine Daten dann auf CD brennen, vorausgesetzt du hast einen Brenner.

[nova2004de]

Ne  ich kann nicht von cd starte, also ich lade knoppix runter; gib es den eine Anleitung wie man das macht, also zu zeit habe ich eine andre  festplatte angeschlossen soll ich die trennen und nur die nicht funktionierende festplatte anschließen und mit konoppix dann booten?
Oder wie soll ich das machen?

[Schwermetaller]

cd und Bios habe ich schon versucht

Ne ich kann nicht von cd starte

Du kannst also nicht von CD starten? Wenn dem so ist, dann macht auch Knoppix wenig Sinn. Daher auch der Hinweis auf die BIOS-Einstellungen. Hast du dort das CD-Laufwerk in der Bootlaufwerks-Priorität an erster Stelle stehen? Falls nicht, diese Einstellungen bitte vornehmen!
Wenn das geschehen ist, kannst du dein System dann z.B. von der Windows-CD starten und deinen Rechner neu aufsetzen. Oder hast du das schon gemacht und es kommt auch hier zum Bluescreen?

Eine zweite Variante wäre, den Rechner mit beiden Festplatten zu starten. Da du ja derzeit offensichtlich eine intakte Festplatte besitzt, kannst du ja das "defekte" Modell ja am gleichen Controller mit anschließen. Dabei musst du allerdings auf die korrekte Jumperung der Laufwerke achten --> intakte Festplatte als Master, "defekte" Platte als Slave jumpern. Möglicherweise erhältst du dann Zugriff auf deine Daten von E:, wobei sich der Laufwerksbuchstabe verschieben kann.
Und nochmal: Oder hast du das schon gemacht und es kommt auch hier zum Bluescreen?

[nova2004de]

Ja das habe ich schon gemacht Windows-CD zu starten es  kommt auch Bluescreen


Ich habe jetzt knoppix runter geladen, nun mache ich etwas mit den brennen falsch  ich bekomme beim hochfahren Die Meldung: FD 1,44mb System type-(00)
ja und ich habe alle beide schon angeschlosen und es kommt  auch Bluescreen

[Schwermetaller]

Klingt ja gar nicht gut. Wie und womit hast du das *.iso Image gebrannt? Eine Kurzanleitung findet sich z. B. hier -->Link (http://www.edonkey-faq.de/brenn.htm#iso).

[nova2004de]

so ich habe es geschaft mit den brennen  und es klapt auch mit den knoppix, nun ist die festplatte da und die Partition aoch nur ohne daten da wo daten da sein sollten  sind die weg  !!!! oder kann ich noch was machen, also ich hate die  platte nicht formatiert sondern nur die grüße gendert also ist ja nur( denge ich ) ein durcheinander oder ?

[Schwermetaller]

Klingt auch nicht sonderlich besser. Auf dies Schnelle fällt mir da nur GetDataback ein. Das ist zwar Shareware und in der Testversion nur zum überprüfen des Vorhandenseins von Daten geeignet, aber das wäre ja immerhin schon mal was.

Was mich nur nach wie vor etwas stutzig macht, ist die Tatsache, dass das System bei beiden angeschlossenen Platten beim booten von der intakten Platte ebenfalls einen Fehler verursacht. Hier ist definitiv alles richtig angeschlossen und gejumpert? Denn für die Nutzung von GetDataBack wäre ein laufendes System, an das die "defekte" Platte nur noch angeschlossen werden muss, gar nicht so schlecht.

[nova2004de]

in der Partition ist nur ein ordner drin     hbd1= pagfile.sys
in der zweiten eine datei  hbd2= botex.log
in deer driten sind zwei ordner und unter odrdner mit datein drien
hdb= ORDNER= RECYCLE=ORDNER S-1-5-21...usw=ZWEI datein =dektop.ini=info2
ordner =system volume information=restore(4ce66....usw)=ordner=pro0-pro1-pro2
pro0=datei=change.log.1
pro1=datei=change.log.1=restorepaintsize
pro2=change.log
ordner=restore(a966...usw)=ORDNER=RP98=DATEI=change.log
ordner=mount point manager remonte database
ordner=tracking.log

so das ist alles ich hofe jemand kann damit was anfangen??
ja ich habe alle beid platen richtig  gejumpert es klapt nicht wen beide platen dran sind geht nichs auser unter knoppix

[Kischy]

Ein toller Fehler oder den hab ich au grad aber nur wenn ich ein bestimmtes Spiel spiel.
Bei mir kann ichs nicht lösen aber bei dir.
Erstmal ein Bluscreen ist kein böser Fehler sondern eine Schutzmasname von Windows.Dieses fährt herunter um größere Schäden an
den Festplatten etc..
Hajo Schulz
Wenn Windows blaumacht
Ursachen von Bluescreens aufspüren

Zwar sind sie seit Windows XP seltener geworden, aber auch hier gibt es sie noch: rätselhafte Systemneustarts oder die blauen Bildschirme, mit denen das Betriebssystem sich für arbeitsunfähig erklärt. Der gut gemeinte Hinweis "Wenden Sie sich an den Administrator" hilft auch nicht viel weiter, wenn dieses Schicksal den Heim-PC ereilt.

Unterthema: Bluescreen auf Kommando

Verglichen mit Windows 98 oder ME, wo eine marodierende Anwendung schon mal das komplette Betriebssystem in den Abgrund reißen konnte, laufen die neueren Windows-Versionen ab 2000 beinahe unerschütterlich stabil. Trotzdem gibt es auch hier immer mal wieder den Fall, dass Windows komplett den Dienst einstellt. Das äußert sich dann in einem plötzlichen Neustart oder dem Erscheinen des berühmt-berüchtigten "Bluescreen of Death" (BSOD). Dieser Artikel gibt Hinweise, wie man in solchen Fällen dem Schuldigen auf die Spur kommt und ihn aus dem System wirft.

Eigentlich ist so ein Bluescreen nichts Schlechtes: Wenn er erscheint, hat das Betriebssystem festgestellt, dass es in einen Zustand geraten ist, in dem ein sicheres Weiterarbeiten nicht mehr möglich ist. Jede folgende Aktion könnte mehr Schaden anrichten, als ein vielleicht seit einer halben Stunde nicht gespeichertes Word-Dokument für den Anwender bedeutet. Um die Hardware und den Inhalt der Festplatte vor Schäden zu bewahren, fährt sich das System in so einem Fall kontrolliert herunter. Ob es den Rechner danach automatisch neu startet oder einen Bluescreen anzeigt und die CPU anhält, kann der Anwender einstellen.

minpic02.jpg
Auch wenn er meist zur Unzeit auftritt, ist ein Bluescreen of Death doch ein Zeichen für ein kontrolliertes Herunterfahren des Systems.

Die zuständigen Optionen verbergen sich in den Systemeinstellungen (Rechtsklick auf das "Arbeitsplatz"-Symbol und dann "Eigenschaften" oder "System" in der Systemsteuerung) auf dem Register "Erweitert". Hier führt ein Klick auf "Einstellungen" im Bereich "Starten und Wiederherstellen" auf einen Dialog, dessen Einstellmöglichkeiten im Bereich "Systemfehler" definieren, was Windows im Falle eines Komplettabsturzes noch alles unternimmt. Zur Fehlersuche sind hier zwei Optionen wichtig: "Automatisch Neustart durchführen" sollte ausgeschaltet sein, damit ein Bluescreen nicht sofort wieder verschwindet, dem man unter Umständen noch wertvolle Informationen entnehmen kann. Kommt es dann trotzdem zu plötzlichen Reboots, ist in der Regel nicht Windows oder sonst eine Softwarekomponente schuld, sondern es liegt ein Hardwareproblem vor. In Frage kommt zum Beispiel ein Netzteil, das die Versorgungsspannung nicht stabil genug liefert und so einen Reset auslöst.

Zum Aufspüren der Ursache für Bluescreens ist es außerdem wichtig, möglichst genaue Informationen über den Systemzustand zum Zeitpunkt des Absturzes zu haben. Das unter "Debuginformationen speichern" standardmäßig ausgewählte "Kleine Speicherabbild" reicht dazu in der Regel nicht aus. Besser ist es hier, ein Kernelspeicherabbild anzufordern. Die Größe einer solchen Datei entspricht etwa einem Drittel der Hauptspeichergröße. Ein "Vollständiges Hauptspeicherabbild" wird dagegen stets so groß wie der Hauptspeicher (plus einem Megabyte für einen Header und ein paar Verwaltungsinformationen). Dieser zusätzlich belegte Platz zahlt sich aber für die reine Fehlersuche in der Regel nicht aus.

Ob man das Häkchen bei "Vorhandene Dateien überschreiben" setzt, ist nicht nur Geschmackssache: Fehlt es, legt Windows beim nächsten Absturz nicht etwa ein neues Speicherabbild an, sondern schreibt schlicht keines und man hat keine Chance, den Fehler zu analysieren. Ist die Option eingeschaltet, geht beim nächsten Crash eine schon vorhandene und vielleicht noch nicht komplett ausgedeutete Datei verloren. In jedem Fall empfiehlt es sich, nach einem BSOD und anschließendem Neustart den Memory-Dump so schnell wie möglich durch Umbenennen oder Verschieben in Sicherheit zu bringen.
Ermittlung

Auch wenn ein Bluescreen reproduzierbar immer im selben Programm auftritt: Die Anwendung selbst kann daran nicht schuld sein - jedenfalls nicht unmittelbar. Unter Windows-NT-Abkömmlingen laufen ordinäre Programme nämlich im so genannten User-Mode (auch "Ring 3" genannt). Sie bekommen einen eigenen virtuellen Adressraum zugewiesen und können nicht auf den Adressraum anderer Anwendungen oder direkt auf die Hardware zugreifen. Wenn in einer Anwendung etwas Gravierendes schief geht, kommt es daher allenfalls zum Absturz dieses einen Programms, was sich in einer Fehlermeldung der Art "WinBugPro.exe hat ein Problem festgestellt und muss beendet werden" äußert. Windows selbst läuft in so einem Fall unbeeindruckt weiter.

Ein Betriebssystemabsturz in Form eines Bluescreen kann nur entstehen, wenn Code etwas Illegales tut, der im so genannten Kernel-Mode ("Ring 0") läuft. Dazu gehören Gerätetreiber und der Mikrokernel selbst. Im Ring 0 teilen sich alle Treiber einen gemeinsamen Adressraum und können sich durchaus gegenseitig abschießen.

Um herauszufinden, welche Komponente genau den Fehler verursacht hat, muss man sich den Zustand des Systems unmittelbar vor dem Absturz ansehen. Einige Informationen zeigt schon der Bluescreen selbst: Eine Zeile, die mit "*** STOP" gefolgt von einer achtstelligen Hexadezimalzahl beginnt, ist auf jedem BSOD zu sehen. Sie liefert einen ersten Hinweis auf die Art des Fehlers - wenn man sie denn zu interpretieren weiß. Manchmal findet sich in der Nähe der STOP-Zeile eine symbolische Beschreibung des Fehlers, etwa IRQL_NOT_LESS_OR_EQUAL oder INACCESSIBLE_BOOT_DEVICE, und damit zumindest ein Anhaltspunkt für eine Google-Suche. Mit etwas Glück enthält der Bluescreen auch einen Hinweis auf eine Datei mit der Endung .sys. Die ist damit natürlich verdächtig, aber leider noch lange nicht als eindeutig schuldig identifiziert.

Mit den Informationen auf dem Bluescreen selbst kommt man also meist nicht allzu weit. Ein Blick in das Speicherabbild ist angesagt. Glücklicherweise bietet Microsoft dafür ein geeignetes Werkzeug an: den Debugger WinDbg [1], den Sie über den Soft-Link herunterladen können. Die Download-Größe ist mit knapp 9 MByte noch erträglich. Um den Debugger allerdings sinnvoll einsetzen zu können, benötigen Sie noch die so genannten Symboldateien - und die schlagen je nach Windows-Version mit circa 70 bis 170 MByte zu Buche. Ein Komplett-Download ist aber nicht unbedingt nötig, wenn der Rechner, auf dem Sie die Analyse durchführen wollen (das muss nicht notwendigerweise der von den Abstürzen betroffene sein), mit dem Internet verbunden ist. Dann können Sie nämlich WinDbg so einrichten, dass er immer nur die benötigten Symbole lädt und auf dem Rechner zwischenspeichert. Dazu legen Sie nach der Installation des Debuggers zunächst irgendwo auf der Festplatte ein neues Verzeichnis an. In WinDbg wählen Sie den Menübefehl "File/Symbol File Path" und tragen in das Eingabefeld die Zeile SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols ein. Statt "C:\Symbols" müssen Sie dabei den neuen Ordner angeben; hier wird der Debugger die heruntergeladenen Symboldateien zwischenspeichern.

Ein Speicherabbild lädt WinDbg mit dem Menübefehl "File/Open Crash Dump". Daraufhin öffnet der Debugger zwei Fenster mit den Titelzeilen "Command" und "Disassembly". Letzteres kann man der Übersichtlichkeit halber gleich wieder schließen - die dort dargestellten Informationen zu interpretieren erfordert so viel an System- und Programmierkenntnissen, dass eine Beschäftigung damit den Rahmen dieses Artikels sprengt. Das "Command"-Fenster enthält dagegen meist schon durchaus wertvolle Informationen. Beachtenswert sind zwei Zeilen: Eine beginnt mit "Probably caused by:" (zu deutsch: "Vermutlich verursacht von:") gefolgt von einem Dateinamen. Der Tipp, den WinDbg hier abgibt, trifft schon erstaunlich oft ins Schwarze. Zumindest wenn die benannte Datei die Endung .sys trägt, lohnt es sich, zu untersuchen, woher sie stammt.

Die zweite interessante Zeile in WinDbgs Kurzanalyse beginnt mit "BugCheck" und enthält danach eine Hexadezimalzahl und eine Reihe weiterer kryptischer Angaben in geschweiften Klammern. Hier handelt es sich um eine Wiederholung dessen, was der Bluescreen in der STOP-Zeile angezeigt hat. Um Genaueres über die Bedeutung dieser Angaben zu erfahren, gibt man unten im Command-Fenster hinter "kd>" den Befehl

!analyze -v

ein. Er liefert meist einen Wust an Informationen, von denen zunächst die ersten Zeilen besondere Beachtung verdienen: Ein symbolischer, aus Großbuchstaben und Unterstrichen bestehender Name wie NTFS_FILE_SYSTEM nebst einer Kurzbeschreibung erklärt die Art des aufgetretenen Fehlers. In den folgenden Zeilen gibt es eine kurze Erklärung der mitgelieferten Parameter. Wer es noch genauer wissen will, kopiert das Fehlersymbol und fügt es in der Eingabezeile hinter dem Befehl .hh wieder ein:

.hh NTFS_FILE_SYSTEM

startet die WinDbg-Hilfe und zeigt einen Artikel an, der weitere Informationen zu dem Fehler enthält. Bei vielen Fehlerarten finden sich hier auch gleich Erklärungen, wie man die möglichen Fehlerursachen einschränken kann oder was zu tun ist, um den Fehler künftig zu vermeiden. Wenn dort steht, dass die häufigste Fehlerursache defekte Hardware ist, dann sollten Sie das durchaus ernst nehmen und die weitere Fehlersuche zunächst darauf konzentrieren (siehe [2]).
Detektivarbeit

In der Ausgabe von !analyze -v sind außerdem noch die Zeilen unter der Überschrift "STACK_TEXT:" interessant: Sie enthalten eine umgekehrt chronologische Liste der Funktionen, die sich kurz vor dem Crash gegenseitig aufgerufen haben. In der letzten Spalte steht dabei jeweils der Name des zuständigen Moduls und dahinter, abgetrennt durch ein Ausrufe- oder ein Plus-Zeichen, die Adresse innerhalb des Moduls. Taucht hier in den ersten paar Zeilen ein anderer Modulname als "nt" auf, ist dieses Modul zumindest verdächtig, an dem Crash beteiligt gewesen zu sein.

Weitere Kandidaten kann man manchmal identifizieren, indem man den Befehl !thread eingibt. Enthält die Ausgabe die Überschrift "IRP List:", dann sollte man die Adressen aus der ersten Spalte dieser Liste an den Befehl !irp verfüttern: Ein Kommando wie

!irp ffabccd8

gibt detailliert Auskunft über ein so genanntes I/O Request Packet, das an dieser Adresse im Speicher liegt. Es enthält immer auch die Namen der Treiber, die an dieser Ein-/Ausgabeoperation beteiligt sind, und damit weitere mögliche Schuldige für den Absturz.

minpic04.jpg
Wenn der Rechner immer beim Diskettenzugriff oder beim Anstöpseln eines USB-Gerätes abschmiert, lohnt ein Blick auf die I/O Request Packets.
Under Cover

Leider lassen sich mit den bisher vorgestellten Methoden noch nicht alle Fehlerursachen eindeutig erkennen. Vor allem wenn diese Bemühungen bei jedem Crash ein anderes Bild liefern, ist Misstrauen angezeigt: Der Verdacht fällt dann zunächst auf Hardwareprobleme wie vergesslichen Hauptspeicher oder einen unzuverlässigen Festplatten-Controller. Trotzdem kommen immer noch Treiber-Malaisen als Ursache in Frage. Es kann nämlich sein, dass eine Systemdatei Unordnung in die Datenstrukturen des Kernels bringt, was dem aber nicht sofort auffällt. Erst ein späterer, harmloser Aufruf eines eigentlich intakten Treibers stolpert dann über diese Falle und gerät zu Unrecht in Verdacht, den Crash verursacht zu haben.

minpic03.jpg
Häufig versteckt sich der für den Crash verantwortliche Treiber im Aufruf-Stack.

Zum Aufspüren dieser Art von Fehlern bringen Windows 2000 und XP von Haus aus eine erweiterte Treiberüberprüfung mit. Einstellen lässt sich dieses Diagnosewerkzeug, indem man per "Start/Ausführen" das Programm verifier aufruft. Es stellt verschiedene Möglichkeiten zur Auswahl, mit denen Windows geladenen Treibern auf die Finger schaut. Verstößt ein Treiber gegen die verschärften Spielregeln, erzeugt die Treiberüberprüfung einen speziellen BSOD, dessen Speicherabzug sich dann wie oben beschrieben analysieren lässt.

Unter Windows XP ist der verifier als Wizard ausgelegt, bei dem man sich durch verschiedene Schritte klicken muss. Folgende Einstellungen haben sich bewährt: Auf dem ersten Schirm "Benutzerdefinierte Einstellungen verwenden", im zweiten Schritt "Vordefinierte Einstellungen verwenden", "Standardeinstellungen" und "Simulierung geringer Ressourcen". Im dritten Teil der Einstellungen reicht es meist, die nicht signierten Treiber automatisch auswählen zu lassen - die signierten haben diese Tortur ja schon hinter sich. Um Wechselwirkungen auszuschließen, kann man hier auch "Treiber aus einer Liste wählen" anklicken und im letzten Schritt alle Treiber überprüfen lassen, die nicht von Microsoft stammen.

Der verifier von Windows 2000 zeigt alle Optionen gemeinsam auf dem Register "Einstellungen" an. Hier sollte man "Ausgewählte Treiber überprüfen" markieren, in der Liste alle nicht von Microsoft stammenden Treiber auswählen und unten auf "Überprüfen" klicken. Anschließend kann man durch einen Klick auf "Bevorzugte Einstellungen" die gängigsten Überprüfungen aktivieren und das Ganze per "Übernehmen" bestätigen. Sowohl unter Windows XP als auch unter Windows 2000 werden die Einstellungen mit dem nächsten Neustart aktiv.

Nicht übersehen sollte man, dass die Treiberüberprüfung ein zweischneidiges Schwert ist: Zwar identifiziert sie recht zuverlässig Treiber, die sich nicht anständig benehmen. Nimmt man aber zu viele Treiber in die Prüfung auf, kann das das System bis zur Unbrauchbarkeit herunterbremsen. Außerdem kann die Treiberüberprüfung dafür sorgen, dass einer der Checks schon beim Booten zuschlägt und so einen Systemstart verhindert - den man aber braucht, um sie wieder abzuschalten. Ihre Einstellungen speichert die Treiberüberprüfung im Systemzweig der Registry. Von dem sollte man daher sicherheitshalber mit Hilfe der Wiederherstellungskonsole eine Kopie anlegen, bevor man die Treiberüberprüfung aktiviert (siehe Seite 94).
Verurteilung

Mit der Erkenntnis, welche Treiber am Zustandekommen des BSOD beteiligt gewesen sein könnten, geht es nun daran, Abhilfe zu schaffen. Zunächst lohnt es sich, mit WinDbg nach weiteren Informationen über die Treiberdatei zu fahnden. Dazu übergibt man den Namen des verdächtigen Moduls an den Befehl lm. Ist Ihnen beispielsweise die Datei bsod.sys ins Auge gefallen, lautet der komplette Befehl

lm v mbsod

Hinter dem "lm" kommt ein Leerzeichen, dann ein "v", noch ein Leerzeichen und anschließend ein "m", an das der Name des Moduls ohne Dateiendung unmittelbar angehängt wird. Mit etwas Glück enthält die Ausgabe dieses Befehls den kompletten Dateinamen samt Pfad der Treiberdatei und gibt Auskunft über den Hersteller. Wenn nicht, hilft nur noch die Brechstange: Der Befehl

!devnode 0 1

gibt eine Liste aller geladenen Gerätetreiber aus. In der kann man mit dem Menübefehl "Edit/Find" nach dem verdächtigen Modulnamen - wieder ohne Dateiendung - suchen. In dem Eintrag, in dem er hinter "ServiceName" erscheint, ist der "InstancePath" interessant - merken oder notieren. Alsdann startet man das Programm regedit, navigiert nach HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum und von dort weiter entlang dem in InstancePath angegebenen Pfad. Hier verrät der Eintrag "DeviceDesc", um was für ein Gerät oder Treiber es sich handelt, und weitere Informationen, etwa wo auf der Festplatte die Treiberdatei liegt oder wer ihr Hersteller ist, sollten über den Gerätemanager beschaffbar sein.
Abführ'n

Mit diesen Angaben versehen, kann man daran gehen, das Problem zu beseitigen: Erste Anlaufstelle ist der Hersteller, der sich die Frage gefallen lassen muss, ob das Problem bekannt und vielleicht schon ein neuerer Treiber verfügbar ist. Wenn nicht, stellt sich die Frage, was am System verändert wurde, bevor der Fehler zum ersten Mal auftrat. Beim Versuch, diese Änderung rückgängig zu machen, kommen Rettungsversuche über die Systemwiederherstellung, das Einspielen eines gesicherten Festplatten-Image oder eines anderen System-Backup in Betracht. Ist die Treiberdatei schlicht beschädigt, hilft oft eine Neuinstallation des Treibers oder das manuelle Herausfummeln der betroffenen Datei aus einem Installationspaket. Bringt das alles keine Besserung, sollten bei der Ursachenforschung zumindest genug Stichwörter zusammengekommen sein, um eine erfolgversprechende Internet-Recherche zu starten. (hos)
Literatur

[1] Microsoft Debugging Tools, www.microsoft.com/whdc/ddk/debugging

[2] Christof Windeck, PC-System-Check, Funktionsprüfung, richtig konfigurieren, Fehlerbeseitigung, c't 26/02, S. 102

Soft-Link 0410110

Kasten 1
Bluescreen auf Kommando

Es soll ja Windows-Installationen geben, die so stabil laufen, dass ihr Besitzer noch nie einen Bluescreen zu Gesicht bekommen hat. Damit solche beneidenswerten Anwender diesen Artikel nachvollziehen können, brauchen sie eine Möglichkeit, einen BSOD auf Kommando zu provozieren. Daran haben die Windows-Entwickler gedacht, den Weg dorthin aber nicht allzu leicht gemacht - schließlich will man einen so gravierenden Fehler nicht aus Versehen auslösen. Um das Feature freizuschalten, müssen Sie zunächst das Programm regedit bemühen: Navigieren Sie damit zum Registrierungsschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters und legen Sie dort einen neuen DWORD-Eintrag namens CrashOnCtrlScroll an, dem Sie als Wert eine 1 zuweisen. Nach einem Windows-Neustart können Sie nun einen Bluescreen auslösen, indem Sie die rechte Strg-Taste gedrückt halten und zweimal auf "Rollen" drücken. (Das ist die mittlere Taste in der Dreiergruppe über dem Cursorblock; manchmal ist sie auch mit "Scroll" oder "ScrlLock" beschriftet. Auf Notebook-Tastaturen teilt sie sich häufig den Platz mit der Num- oder NumLock-Taste und ist zu erreichen, indem man zusätzlich die Fn-Taste gedrückt hält.)

Diese Tastenkombination zu aktivieren kann selbst dann sinnvoll sein, wenn Sie überhaupt nicht die Absicht haben, mit Bluescreens und dem Debugger zu experimentieren: Gerade auf Notebooks, denen in der Regel eine Reset-Taste fehlt und die auch das Ziehen des Netzsteckers nicht sonderlich beeindruckt, kann sie der letzte Ausweg sein, wenn der Rechner sich mal komplett aufgehängt hat. Sie wirkt häufig auch dann noch, wenn der Mauszeiger sich nicht mehr bewegt und selbst ein Druck auf Strg-Alt-Entf keine Reaktion zeigt. Die eingangs erwähnte Option zum automatischen Neustart des Rechners nach einem Systemfehler sollten Sie für diesen Zweck allerdings aktivieren.



EIN SEHR LANGER TEXT. Mein tipp mach eine cd oder diskette von Windows von einem anderen Pc aus. Wie dass geht hab ich jetzt keine zeit mehr dass zu erklähren guck einfach im I-net da findest immer was.
Da sind dann die Treiber für dein Cd-Laufwerk drauf und dann dürfte es mit der Windows Cd funktioniern.
Gruß Kischy