Unregelmäßiger Bluescreen im Betrieb - Bad Pool Caller – BC-Code 02 (Minidump+MSinfo inside)

Hmm, am Anfang kommt aber eine Fehlermeldung. Das ist eine Testpartition mit WIN7 ohne Pflege. Da schaue ich mir Unbekanntes vorher an, bevor es an passender Stelle installiert wird oder nicht.

Sieh es dir mal an, ob es funktioniert hat? Funktioniert hier der BBCode?

https://1drv.ms/t/s!AqKvTNI8CMs7fpi36tUaI4dg0bI?e=vKcADr

Edit: Die Prof8000.sys war immer noch im Treiberverzeichniss ... die habe ich jetzt mal manuell gelöscht.

Du öffnest die Crashdump-Datei im Debugger. Normalerweise wird dir der erste Befehl schon vorgeschlagen: !analyze -v

Damit findet erst einmal eine grundlegende Analyse statt und oft sieht man dann schon, was los ist oder in welche Richtung es geht. Ansonsten kann man sich die letzten Befehle des Threads vor dem Crash halt mit !thread anzeigen lassen.

Die notwendigen Symbolfiles lädt der Debugger automatisch herunter, so sie denn vorliegen (ist nur bei Windows selbst der Fall). Damit bekommt man zumindest einen groben Überblick, was passiert. Ansonsten sind meist die !sysinfo Befehle noch interessant, wenn man nicht eh vor dem problematischen Gerät sitzt.

Ansonsten kannst du hier weiter einsteigen:

Analyze crash dump files by using WinDbg - Windows drivers | Microsoft Docs

Im Windows Debugger mit dem Befehl !thread sieht man die letzten Befehle in umgekehrter Reihenfolge, die auf dem Stack ausgeführt wurden. Da ist dann immer ein Aufruf des Prof8000 Treibers zu sehen, bevor der BAD POOL CALLER Crash kommt.

Kannst du mir das mal kurz näher erklären, ich möchte mir das auch mal gern ansehen. Ich habe mir jetzt das Windows Debuggingtool erst mal auf einer anderen Partition installiert, um mir das anzuschauen. Wie genau geht es weiter? Ich hätte gedacht ohne jegliche Ahnung die Minidump öffnen und dann, wenn überhaupt ...?

Schutz vor Meltdown und Spectre. Was sonst? ;-)

Normalerweise sage ich dazu: Feigling :-)). Ich habe wirklich keine Angst, dass sich M & S für meinen Rechner interessieren. Aber ich weiß genau, dass dieser Patchwahnsinn damals viel Mist und zudem noch deutlich langsamere System hervorgebracht hat. Jeder wie er (nicht) will.

Es ist schwierig und zeitaufwändig, Probleme in so einem über lange Zeit gewachsenen System zu finden. Ich hab einfach mal abgewartet, ob sich neue Details ergeben. Bisher hab ich auch noch nicht rauslesen können, ob denn jetzt nach dem Entfernen der DVB-S Karte die Probleme noch da sind. Es lohnt ja keine weitere Suche, wenn es gar nicht mehr crasht.

Normalerweise geht man schrittweise vor. Man testet einen Schritt und schaut, ob es das Problem beeinflusst. Wenn nicht, geht man den nächsten Schritt. Ihr reißt da aber grad gemeinsam diverse Baustellen auf. Am Ende weiß dann niemand mehr, was jetzt funktioniert hat oder was nicht. Da warte ich dann lieber mal etwas ab. :-)

Ich warte ja auch ab, da es aber mehrere Sachen zu beheben gab, habe ich einige in einem Rutsch gemacht. Jetzt warte ich auf den (hoffentlich nicht) Bluescreen. Wenn doch, würde ich als nächstes die Netzwerktreiber und Kaspersky komplett "tiefenentfernen". Die Firewall wäre eigentlich noch die einzige Softwarewahrscheinlichkeit. Zur Not könnte ich auch mal per Backup auf etliche Wochen vor dem ersten Crash gehen. Wenn es ein Hardwareproblem wäre, müsste es es weiter crashen.

Das würde aber nicht dazu führen, dass zu drei Vierteln der exakt gleiche Bluescreen im selben Treiber auftaucht. Defekte Netzteile zeigen sich durch allgemeine Instabilitäten oder Probleme meist gerade beim Anschalten des Gerätes. Falls überhaupt Bluescreens im Zusammenhang mit der Stromversorgung auftauchen, sind das normalerweise immer völlig unterschiedliche Codes und nichts verweist mehrfach in die gleiche Ecke.

Ich nutze seit 1993 intensiv Computer + Internet und ich hatte auch nur 1 defektes Netzteil. Das war ein passives von Antec und die Kühlleistung hat einfach nicht ausgereicht. Und ja, der abgebrochene Bootvorgang war das Initialmerkmal. Ich halte viel von bequiet, aber auch da gibt es Ausnahmen und Defekte.

Was die Virtualisierung angeht: dein Virtualisierer setzt auf dem laufenden Betriebssystem auf. Der ist auch "nur" ein Programm, welches seinerseits auf die Ressourcen des Systems über das Host-Betriebssystem zugreift. Ein Crash des Hostsystems bei Nutzung einer VM sagt also erst einmal nicht so viel aus.

Okay. Aber wie willst du herausfinden oder woraus schließt du, ob wirklich das Host-Systen- WIN7 gecrasht ist? Ich habe einige Zeit mit dieser Bluescreenmeldung zugebracht und von RAM-Fehler über defekte CPU bis hin zum hängenden Gehäuselüfter, der dadurch zu viel Strom zog und somit den Crash verursachte, war alles dabei. Nur kein Treiberproblem.

Wer interessiert ist, kann sich ja trotzdem mal die ausführliche SystemInfo ansehen.

https://1drv.ms/u/s!AqKvTNI8CMs7fX9g6hAhgdhuyTo?e=55cJxf

Ein BIOS-Update inkl. der eventuellen Meltdown und Spectre-Verschlimmbesserungen mache ich nicht. Das kenne ich schon aus der Firma und von anderen und was dabei rauskam.

Schutz vor Meltdown und Spectre. Was sonst? ;-)

Grundsätzlich stimme ich dir ja zu: da das OS sich nicht verändert hat, gibt es ja erst einmal wenig Gründe, das BIOS zu verändern. Wenn es bisher lief, sollte es das auch weiter tun. Du hast jetzt allerdings einiges an Treibern etc. aktualisiert. Man müsste mal ins Changelog der BIOS-Versionen zwischen deiner und der aktuellsten Version reinschauen, ob es da noch weitere Fixes gab.

Am Ende seh ich das so: BIOS-Entwicklung kostet Geld und die Hersteller bringen keine Updates ohne Grund. Da ich meist nicht genau beurteilen kann, ob solche Updates notwendig sind oder nicht, spiele ich die Updates ein, wenn sie verfügbar sind.

Ingo hat sich ja leider aus der Diskussion verabschiedet; er meinte ja, vermutlich kein Hardwareproblem.

Es ist schwierig und zeitaufwändig, Probleme in so einem über lange Zeit gewachsenen System zu finden. Ich hab einfach mal abgewartet, ob sich neue Details ergeben. Bisher hab ich auch noch nicht rauslesen können, ob denn jetzt nach dem Entfernen der DVB-S Karte die Probleme noch da sind. Es lohnt ja keine weitere Suche, wenn es gar nicht mehr crasht.

Normalerweise geht man schrittweise vor. Man testet einen Schritt und schaut, ob es das Problem beeinflusst. Wenn nicht, geht man den nächsten Schritt. Ihr reißt da aber grad gemeinsam diverse Baustellen auf. Am Ende weiß dann niemand mehr, was jetzt funktioniert hat oder was nicht. Da warte ich dann lieber mal etwas ab. :-)

So ganz bin ich da nicht dieser Meinung. Nach wie vor würde ich meinen, dass das Netzteil im Fall des Falles der Favorit wäre

Das würde aber nicht dazu führen, dass zu drei Vierteln der exakt gleiche Bluescreen im selben Treiber auftaucht. Defekte Netzteile zeigen sich durch allgemeine Instabilitäten oder Probleme meist gerade beim Anschalten des Gerätes. Falls überhaupt Bluescreens im Zusammenhang mit der Stromversorgung auftauchen, sind das normalerweise immer völlig unterschiedliche Codes und nichts verweist mehrfach in die gleiche Ecke.

Was die Virtualisierung angeht: dein Virtualisierer setzt auf dem laufenden Betriebssystem auf. Der ist auch "nur" ein Programm, welches seinerseits auf die Ressourcen des Systems über das Host-Betriebssystem zugreift. Ein Crash des Hostsystems bei Nutzung einer VM sagt also erst einmal nicht so viel aus.