![]() |
Wieder mal: blue screen
Hi,
nachdem wir ja die BSOD meines Videoschnittrechners (hier) erfolgreich beseitigt haben (das ASUS P6T war defekt), macht nun mein zweiter Rechner Probleme. Vor 3 Tagen BSOD mit 0X0000009C beim Kaltstart. Kein Minidump auf der SSD. Memtest 86+ gefahren - 3x ohne Befund. Dann 2 Tage kein BSOD, problemlos gelaufen. Heute Früh wieder: die beim Booten herein fliegenden Windows-Fenster frieren ein -> BSOD. Und das 2 x hintereinander. Beim 3. Versuch kam der PC endlich in die Höhe. Keine Minidumps vorhanden. Was wurde in letzter Zeit gemacht? Die Crucial M4 bekam am 30.9. ein FW-Update. Ist jetzt die M4 der Hauptverdächige wegen dem FW-Update und dem Fehlen der Minidumps? Ist die am Eingehen oder ist die neue FW Schrott? FW zurück ändern? Oder doch mit dem NT anfangen (tauschen)? Oder ist es wieder das MoBo (wäre auch ein ASUS, ähnlich alt wie das P6T)? Ich mach' inzwischen mal ein Systembackup ... Thx, Quintus P7P55D, i5/750, 8 GB Corsair XMS, Sapphire Radeon, Crucial M4 (System), WD Caviar Black, LG DVD NACHTRAG: >hier< scheinen auch andere mit der neuesten Crucial M4 Firmware & ASUS-MoBo Probleme zu haben ... |
Mist ... bei Crucial findet sich nur die aktuelle FW 010G, nicht aber die davor (000F).
--- Gefunden! |
Ja, eine ältere Firmware wär mal ein erster Ansatz.
|
Nach der Mittagspause (nachdem der PC längere Zeit abgeschaltet war) - nächster BSOD beim Kaltstart! Was noch auffällt: bevor der BSOD kommt, brummt es so komisch aus den Lautsprechern...
Ich tausch' mal das NT. Wenn es das auch nicht ist - wovon ich fast ausgehe - halte ich das MoBo für den Übeltäter. Das zweite ASUS-MoBo von 2 (fast) derselben Generation innerhalb kurzer Zeit... Ich berichte weiter... Quintus |
So - NT ist drin. Wir werden sehen.
Was ich noch ergänzen muss: ich hab' bei der M4 die vorletzte FW (000F) drauf getan. Vor meinem Update auf die aktuelle 010G hatte ich diese Version ausgelassen, also 0309 drauf. Ich könnt' somit natürlich noch eine FW weiter zurück steigen (so ich sie finde). Aber das wär' schon blöd... |
Gut dass ich das FW Update nicht gemacht hab ...
|
Wie schauts jetzt it dem anderen NT aus?
|
Zitat:
Hinweis: ich kann das jetzt nur bis Sonntag beobachten - dann bin ich für ein paar Wochen ortsabwesend. Das Zurückflashen wird somit in jedem Fall dauern. Ich berichte... LG Quintus14 |
FYI: seit dem NT-Tausch kein BSOD mehr. Ich bin ab jetzt 3,5 Wo ortsabwesend, danach kommt die aktuelle FW der M4 wieder drauf.
LG |
Aha, interessant.
|
Ich muss - aus gegebenem Anlass - meinen Thread wieder hervor holen :(. Frage: was sagt uns dies:
Code:
Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64 Thx für sachdienliche Hinweise. Quintus14 System: ASUS P6T, i7/950, 12GB Corsair, System auf Crucial M4, mehrere WD-HDDs, Sapphire Radeon 4870 1GB, |
Liegt meist an einem Spannungsproblem des Prozessors. (Debuggen ist bei 0x124 wenig sinnvoll, der Error Record wird übrigens mittels !errrec und Adresse aus Parameter2 erreicht, außer in den wenigen Fällen, in denen ein Treiberentwickler durch seinen Treiber einen Processorlock hervorruft)
|
Danke, Inzersdorfer. !errrec bringt leider nur 'No export errec found' - vermutlich weil ich die Auslagerungsdatei abgedreht hatte (hab' sie wieder aktiviert fürn nächsten BSOD).
Ich hab' ja inzwischen quer gegoogelt mit den spärlichen Anhaltspunkten, die ich hatte - an einer Stelle fand ich auch etwas von Spannungsproblemen: ASUS soll damals die Stromsparmechanismen am Limit ausgelegt haben und die CPU u.U. beim Stromsparen zu wenig Spannung bekommen - ebendort soll das Deaktivieren von CE1 im BIOS etwas gebracht haben (das hab' ich jetzt auch mal deaktiviert und warte, ob/wann sich wieder ein BSOD ereignet). Es ist ja schon eigenartig: nach dem Urlaub im August 2012 hat es mit BSODs angefangen (obwohl nichts am PC geändert wurde), nach Tausch aller möglichen Komponenten war das MoBo als Übeltäter eingegrenzt - getauscht Anfang September. Ein halbes Jahr war jetzt Ruhe (OK, ich brauch' den PC nicht oft) - und jetzt fängt's wieder von vorne an. Wenn das mit der Spannung der CPU zusammen hängt, kann ich nur vermuten, dass irgendwelche Bauteile am MoBo - das Ersatzboard ist ja vermutlich auch schon vor 2 Jahren produziert worden - altern und dann irgendeine Spannungsversorgung geringfügig aus dem Ruder läuft. Woanders stand, man solle im BIOS von 'auto' weg gehen und die Spannungen manuell vergeben - das wäre der nächste Schritt. Aber vielleicht habe ich beim nächsten BSOD mehr Infos. LG |
Nur so als Tipp: Meist sind die Kondensatoren die Übeltäter, da die über die Jahre stark altern und dann einfach nicht mehr das tun, wofür sie auf's Board gelötet wurden. Die kann man aber (fast) alle selbst tauschen - das nötige Werkzeug und Geschick vorrausgesetzt.
|
Thx, zonediver, für die Info. Ob ich mir allerdings die Arbeit antu'...?
Zitat:
Thx Quintus |
Liste der Anhänge anzeigen (Anzahl: 1)
Wie du schon erkannt hast, im BIOS manuell einstellen.
increase/decrease QPI/VTT first, if not: increase/decrease vcore...have to test to see which one it is Auch eine Auswertung des Error Record bringt dir nichts Angehängt hab ich Einen als Beispiel, typisch nichtssagend, es zeigt nur, das im Ersten Kern der CPU ein Fehler im Cache auftrat. GCACHEL2_ERR_ERR (Proc 0 Bank 5): Generischer Fehler im L2 Cache_Fehler_Generisch (1.Prozessorkern, Speicherbank 6) |
Danke für die Info. Habe heute ca. 7 Stunden intensiv Videobearbeitung gemacht - kein Problem bis jetzt. Morgen und übermorgen geht's weiter - ich warte auf den nächsten BSOD, dann poste ich den neuen dump (in der Hoffnung, da steht Genaueres drin) und fang' an, an den Spannungen zu schrauben.
Thx |
So - nach 1,5 Tagen intensivem Videoschnitt ist der nächste BSOD da: er ereignete sich, als der PC grad mal nix zu tun hatte ...:
Code:
Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64 Ich hab' jetzt C1E wieder aktiviert (wie es sich standardmäßig gehört) und die CPU-Voltage im BIOS von 'Auto' (= 0,85 lt CPU) auf 1,000 gestellt: PCProbe-II zeigt nun VCore im idle mit 0,98V statt 0,94V an. Mal schauen, ob/wann sich der nächste BSOD zeigt. Thx |
Zitat:
|
Ich kann ja morgen mal drauf schauen - aber das P6T soll 5000 hrs all solid capacitors haben. Und dieses Board ist ja erst seit Sept. 2012 in Betrieb (hergestellt vermutlich 2010).
|
Mit etwas Verspätung: der 0x9C wurde ab Vista durch den 0x124 ersetzt, das bedeutet, das kein Prozessor einen Fehler im Register aufweist. Ansonsten scheint die Erhöhung der Vcore ja Wirkung zu zeigen.
|
Hallo Inzersdorfer,
ich hab' ja auf Deinen Tipp in Posting #12 noch intensiver gegoogelt - auch an anderen (englischen) Stellen taucht 'QPI/VTT' bzw. 'Vcore zu niedrig' im Zusammenhang mit diesem Fehlerereignis auf. Irgendwo bin ich auch über die Bemerkung gestolpert, dass ASUS es zu dieser Generation MoBos etwas zu ehrgeizig mit dem Energiesparen genommen haben soll (und 'auto' ggf. zu wenig sein könnte). Mich wundert nur, dass andere Videoschnitt-Kollegen mit demselben Board noch nicht über Probleme berichtet haben (und bei mir ist es jetzt schon das zweite P6T). Jedenfalls läuft der Rechner seit der Erhöhung von Vcore vor 3 Tagen problemlos, ich hab' ihn auch gestern neu aufgesetzt, dutzende male gebootet, die Nacht ist er durchgelaufen (3TB HDD formatiert) ... vielleicht war das Neuaufsetzen nach dem MoBo-Tausch im September (obwohl P6T -> P6T) nun doch notwendig. Momentan läuft er wie ein 'Glöckerl' ... ich bin vorsichtig optimistisch und hoffe, das bleibt so (*klopfholz*). Thx Quintus14 |
Hi,
so - vor 2,5 Wochen hab' ich Vcore erhöht, weil ja die letzten dumps darauf hingewiesen haben, und die Kiste neu aufgesetzt - sie lief bis vor 15 Minuten klaglos ... nun wieder ein BSOD! :( Bitte um Info, worauf folgender Dump nun hin deutet: Code:
Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64 Quintus14 ASUS P6T, 12 GB Corsair, Crucial M4 als System, einige WD-HDDs, Sapphire Radeon 4870, Grass Valley HD Storm |
Nachtrag: und hier der nächste (screenshot), unten der minidump
Ich hab' im letzten halben Jahr nun schon das Netzteil, das Board und den RAM ausgetauscht - mittlerweile bin ich ziemlich angesäuert. Kann eine CPU einen Pascher haben? Oder die M4? Oder die ATI? ---- Code:
Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64 |
CPUs sterben sehr selten, vor allem, wenn sie nicht übertaktet werden.
Die Graka kannst ja durch ein paar Benchmarks quälen, vlt. hast einen mit Dauerlauf-Option. SSD ist halt schwierig. Vlt. solltest wirklich über einen neuen PC nachdenken, anstatt dich immer wieder zu ärgern ohne klaren Hinweis auf den Fehler. |
Noch was: es ist mir aufgefallen, dass der BSOD bei einem ganz bestimmten Übergangseffekt kommt - nachvollziehbar und mehrmals hintereinander. Andere Effekte aus derselben Lade macht er anstandslos.
Über einen neuen PC denk' ich eh nach - aber was, wenn es ein SW-Fehler ist? |
Dann solltest über eine neue Software nachdenken! Was sagt der Softwareproduzent dazu?
|
Der meint RAM oder RAM/Treiber der GraKa.
|
Da du den Ram eh schon getauscht hast -nimm lalakers Graka (Biete Forum) billiger wie ein komplettausch!
|
Hmmm ... testen könnte man es mit der Karte, wenn ich aber die GraKa tauschen muss, würd' ich aber gerne auf eine deutlich potentere Karte umsteigen wollen (wenn's leicht geht). Ich frag' ihn aber mal, ob er sie mir kurzfristig (gegen einen Obolus) leiht.
|
Sowohl der neuerliche 0x124 als auch der 0x101 Clock Watchdog Timeout weisen auf eine zu geringe VCore hin, prüfe nach, ob deine Einstellungen zurückgesetzt wurden. Falls nicht, benutzt du eines der tollen ASUS Tools? (a´la AiCharger, TurboV..)
|
Naja - vielleicht hab' ich die falsche Spannungseinstellung im BIOS erwischt ... sind ja deren mehrere da. Ich hab' CPU-Voltage von 'auto' (=0.85) auf 1.000 getan, alles andere auf 'auto' gelassen (screenshot). Was sollte ich noch verdrehen?
Eigenartig ist's ja schon - da läuft die Kiste seit 2,5 Wochen (nach dem Neuaufsetzen) wie ein Glöckerl, dann stoße ich auf einen Videoschnitt-Übergang, der zielsicher 5x hintereinander zum BSOD führt. Ich hab' in der Zwischenzeit die GraKa getauscht, also mit jener eines anderen Rechners vertauscht - der BSOD kam erst nach dem 5. mal (damit liegt es nicht an der GraKa). Dann hab' ich die GraKas wieder zurück getauscht - danach hab' ich den speziellen Übergang 20x abspielen müssen, bis es gekracht hat - zusätzlich ein thermisches Problem? AiCharger, TurboV hab' ich nicht installiert, nur PC-Probe (ist aber z.Z. nicht automatisch gestartet). Eigenartig ist noch was: wenn der PC nach dem BSOD wieder (von selbst) bootet, liest er die SATA und IDE so komisch langsam ein, bevor Win startet. Thx ---- P.S.: ich seh' grad: von den 3 RAM-Riegeln melden sich nur mehr 2 - der RAM wurde Anfang Jänner von Corsair getauscht... . |
Probiers mal nur mit 2 RAM. Der defekte RAM Bereich wird offensichtlich zielsicher von Deiner Anwendung adressiert.
|
Ich hab' den RAM-Riegel noch drin ... aber auf Inzersdorfers Rat gehört und Vcore (zumindest die 'CPU Voltage') noch weiter rauf auf 1,2V gedreht - jetzt spielt er den Übergangseffekt problemlos im loop schon seit 20 Minuten ab...
Auf 'auto' hat das BIOS gemeint bei der 'CPU Voltage' 0,85V anlegen zu müssen, ich hatte es auf 1,000 gedreht und einige Wochen eine Ruhe. Und genau bei dem einen Effekt scheint auch das zu wenig zu sein. Ich versteh's nicht. Und warum ist schon wieder ein RAM-Riegel kaputt? Ist der Vengeance so ein Mist? Die MoBo-Temperatur liegt bei mir üblicherweise um die 38-40 Grad - also Überhitzung kann's nicht sein. Thx |
@ Inzersdorfer: danke!!!
|
Du könntest noch ein bischen Feintuning bei der Spannung betreiben, bleibts z.Bsp. bei 1,15/1,10/1,05 stabil, dann lieber die Niedrigere nehmen, einen zuverläßigen Stabilitätstest hast du ja ;). Ah ja, zum Ram, wohl ein besonderes Pech, Corsair ist ja nicht OZC.
|
Ich hab' heut' früh versucht zu eruieren, welcher der RAM-Riegel sich nicht meldet ... hab' 2 Riegel umgesteckt ... jetzt melden sich wieder alle 12 GB ... :conf2: ... ???
Ich hab' nächtlicherweise überlegt - vielleicht ist es doch Zeit für ein neues Innenleben meines Videoschnitt-PCs. Nach Abschluss des laufenden Projekts - also in ein paar Wochen - dürfte es so weit sein. Vcore hab' ich jetzt auf 1.05 gesetzt - der 'Belastungstest' läuft z.Z. auch damit problemlos. Was ich aber nicht verstehe: als die Vcore noch auf 'auto' stand, hat mir PCProbe-II gezeigt, dass im Leerlauf Vcore bei 0,85 liegt und bei Belastung auf ca. 1,2V rauf geht. Seit ich Vcore manuell eingestellt hab', bleibt's bei dem Wert, da ändert sich nix zwischen Volllast und idle. Thx |
Zitat:
Thx |
Wichtig wäre die Taktung und Last. Denn deswegen wird ja bei Automatik die Spannung angehoben. Dies kann an einem betriebssicheren Rahmen liegen ("lieber bisserl mehr, dafür stabil" = Thema undervolting). Solltest du die Maximaltaktung bei deinen 1,05V stabil halten können, paßt es.
|
Ich kann weiter berichten: nachdem sich vorgestern Abend nur 8 von 12 GB meldeten, wollte ich gestern Früh heraus finden, welcher der 3 Riegel defekt ist ... nach dem Vertauschen von 2 Riegeln waren alle 12 GB wieder da :conf2: .
Ich hab' dann alle 3 Riegel nochmal raus, Kontakte gereinigt, wieder rein und auch Vcore wieder auf 'auto' zurück - und den ganzen Tag gearbeitet, als ob nix wär'! Auch der 'Belastungstest' von vor 2 Tagen, der innerhalb von Sekunden zielsicher zum BSOD führte, läuft derzeit im loop stundenlang! Ich versteh's nicht ... dass die Kontakte des neuen RAMs, den ich vor 3 Wochen rein gesteckt hab', verschmutzt gewesen sein sollen, glaub' ich nicht - ich greif' die prinzipiell nicht an. Da läuft mein erstes P6T 1,5 Jahre problemlos - dann aus heiterem Himmel BSODs. Dann das zweite P6T von September 2012 bis Dezember problemlos - dann aus heiterem Himmel BSODs. Dann mit dem neuen RAM 3 Wochen lang problemlos - dann aus heiterem Himmel BSODs :confused:. Zwischendurch hatte ich schon die GraKa und das Netzteil getauscht (und nach einem BSOD wieder zurück getauscht), der RAM ist auch neu ... was noch nicht getauscht wurde, ist die CPU. Ich hab' meinem PC nun die Rute ins Fenster gestellt: eine neue Rechner-Konfig ist geistig schon zusammengestellt - beim nächsten Anlassfall wird er verschrottet. Thx |
Alle Zeitangaben in WEZ +2. Es ist jetzt 21:30 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag