Zitat von
foobar
Die Fehlermeldung sagt, dass das BIOS die Bootplatte nicht finden kann. Zu diesem Zeitpunkt ist noch kein Betriebssystem geladen. Im Gegenteil, das BIOS wollte das Betriebssystem von der Platte starten, fand aber nix. Ergo kann es nicht am Betriebssystem oder dessen Treibern liegen. Die laufen zu diesem Zeitpunkt ja noch nicht.
Ich gehe davon aus, dass kompliziertes Fehlerlesen wenig bringt, wenn nicht mal diese Voraussetzung erfüllt ist. Trotzdem habe ich es mal, nur ansatzweise (mit WinDbg könnte man sonst Tage verbringen), versucht:
Deine Minidumps geben mir (mit zugegebenermaßen sehr unvollständigem Wissen) keine klaren Anhaltspunkte. Einmal (BAD_POOL_CALLER) ist es der Treiber für den Firewire-Controller, in dem es gekracht hat. Wenn du das nicht brauchst, kannst du den Chip mal probehalber im BIOS-Setup deaktivieren.
Das wurde auch mir (seltsamerweise) in BluescreenView angezeigt. Doch dann habe ich WinDbg bemüht, wo Ntfs.sys (teilweise nachvollziehbar) verantwortlich gemacht wird. Der Fehler soll unter dem IRQ-Level 0 passieren, also bei normaler Anwendungspriorität (aber schon im Kernel selbst, Prozess ist "System"). Es soll versucht worden sein, bereits freigegebenen Speicher erneut freizugeben. Ich finde keinen Widerspruch zum Disassembly, weswegen mir das mit BluescreenView seltsam vorkommt. Aber ich weiß natürlich nicht, wie tiefgehend das Tool analysiert. Vielleicht kann es etwas, womit man nicht unbedingt rechnet.
Aber mit dem zweiten BSOD (IRQL_NOT_LESS_OR_EQUAL) hat der Firewire-Treiber offenbar nix zu tun. Daher tippe ich eher darauf, dass es nur zufällig in dem Treiber krachte und die wahre Ursache woanders liegt. Aber probieren kann man's mal.
Hier ist der IRQ-Level 2, welcher dem Dispatcher des Kernels zugeordnet sein soll. Und tatsächlich meldet WinDbg, dass der Befehlszeiger bei nt!KiInsertQueue gestanden haben soll, was dem Dispatcher zuzuordnen ist (und was der Name andeutet). Jedenfalls sagt das der Code von ReactOs, den ich per Google gefunden habe. Hier ist fast dasselbe wie in dem anderen Fall passiert, mit nur einem kleinen Offset bei der Speicheradresse. Das ganze soll angeblich unter dem Prozess von "firefox.exe" passiert sein, sagt WinDbg.
Die beiden Minidumps sind mit großer Wahrscheinlichkeit auf denselben Fehler zurückzuführen. Und gemeinsam ist auch, dass jeweils die Adresse, wo der Systembereich anfängt, nicht ermittelt werden kann (sagt WinDbg, habe das noch nicht konkret nachvollziehen können), wobei dem Namen der Funktion nach der Speichermanager involviert sein könnte.
Und dort könnte sich der Kreis schließen. Denn wenn die Festplatte muckt oder wenn die Partitionsgröße nachträglich verändert wurde, dann könnte vielleicht irgendein Zusammenhang mit der Auslagerungsdatei bestehen. Vielleicht ist etwas beim Zusammenschieben fehlgeschlagen (weil die Hardware vermutlich muckt), sodass die Auslagerungsgdatei beschädigt wurde. Oder der Speichermanager ist einfach nur irritiert worden und nun fehlkonfiguriert (Windows hat bekanntermaßen auch manchmal Bugs (die sich umso mehr zeigen, wenn etwas nicht erwartungsgemäß abläuft), vielleicht besteht da irgendeine Abhängigkeit, die es besser nicht geben sollte). Aber bei den Gründen wird es allmählich Kaffeesatzleserei.
Daher würde ich die Größe der Auslagerungsdatei mal auf Null setzen, Windows neustarten, die Datei löschen und die Größe dann wieder von Windows verwalten lassen und gucken, ob es hilft. Aber wenn unten drunter weiterhin etwas nicht stimmt, könnte das vertane Liebesmüh sein. Weil es jedoch mit ein paar Handgriffen erledigt wäre und mit sehr viel dummem Glück helfen könnte, habe ich das mal vorsichtshalber erwähnt.
Zitat von
Sentinel
Das Tool zum Auslesen für Win7, dessen Setup ich von
hier heruntergeladen habe, lässt sich irgendwie nicht installieren. Die Installation bricht jedes mal ab. Aber auslesen könntest du die Log-Datei ja zur Not, oder?
Falls der Web-Installer fehlschlägt, könntest du das ebenfalls von dort aus angebotene ISO-Image ausprobieren. Alternativ käme die aktuelle Version des SDKs infrage, denn das darüber erhältliche WinDbg soll bis Windows 7 (und Windows Server 2008 R2) abwärtskompatibel sein. Den anderen Kram kannst du ausschlagen. Infos und Links dazu gibt es hier. Manche Installer können eine Version des .NET-Frameworks benötigen, welche bei dir entweder aktiviert (per Windows-Funktionen in der Systemsteuerung, sollte aber eigentlich voraktiviert sein), aktualisiert (per Windows-Update) oder nachinstalliert (per separatem Paket) werden müsste. Zu beachten ist, dass es sich dabei um verschiedene Distributionsmethoden handelt, die man nicht in einen Topf werfen sollte (Windows ist umständlich). Was Windows von sich aus anbietet, sollte man nicht von außen aufdrängen (wird normalerweise unterbunden).