WCM Forum

WCM Forum (http://www.wcm.at/forum/index.php)
-   Hardware-Probleme (http://www.wcm.at/forum/forumdisplay.php?f=3)
-   -   Wieder mal: blue screen (http://www.wcm.at/forum/showthread.php?t=245202)

Quintus14 11.10.2012 09:01

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 ...

Quintus14 11.10.2012 09:28

Mist ... bei Crucial findet sich nur die aktuelle FW 010G, nicht aber die davor (000F).

---

Gefunden!

lalaker 11.10.2012 12:09

Ja, eine ältere Firmware wär mal ein erster Ansatz.

Quintus14 11.10.2012 14:13

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

Quintus14 11.10.2012 15:01

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...

ZombyKillah 11.10.2012 20:41

Gut dass ich das FW Update nicht gemacht hab ...

lalaker 11.10.2012 21:07

Wie schauts jetzt it dem anderen NT aus?

Quintus14 11.10.2012 21:30

Zitat:

Zitat von lalaker (Beitrag 2479327)
Wie schauts jetzt it dem anderen NT aus?

Ich hab' heut' ca. ein 1/2 Dutzend Kaltstarts gemacht - bislang keine Probleme. Es ist natürlich noch viel zu früh um zu jubeln bzw. um das NT als den Schuldigen abzustempeln. Wenn es so bleibt und kein BSOD mehr kommt, spiel' ich der M4 die aktuelle FW wieder drauf.

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

Quintus14 14.10.2012 07:19

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

lalaker 14.10.2012 10:50

Aha, interessant.

Quintus14 24.01.2013 19:13

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
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump\012413-21044-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17514.amd64fre.win7sp1_rtm.101119-1850
Machine Name:
Kernel base = 0xfffff800`02c5e000 PsLoadedModuleList = 0xfffff800`02ea3e90
Debug session time: Thu Jan 24 18:45:30.852 2013 (GMT+1)
System Uptime: 0 days 0:00:15.866
Loading Kernel Symbols
.................................................
Loading User Symbols
Mini Kernel Dump does not contain unloaded driver list
*******************************************************************************
*                                                                            *
*                        Bugcheck Analysis                                    *
*                                                                            *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 124, {0, fffffa800a8008f8, 0, 0}

Probably caused by : hardware

Followup: MachineOwner
---------

1: kd> !analyze -v
*******************************************************************************
*                                                                            *
*                        Bugcheck Analysis                                    *
*                                                                            *
*******************************************************************************

WHEA_UNCORRECTABLE_ERROR (124)
A fatal hardware error has occurred. Parameter 1 identifies the type of error
source that reported the error. Parameter 2 holds the address of the
WHEA_ERROR_RECORD structure that describes the error conditon.
Arguments:
Arg1: 0000000000000000, Machine Check Exception
Arg2: fffffa800a8008f8, Address of the WHEA_ERROR_RECORD structure.
Arg3: 0000000000000000, High order 32-bits of the MCi_STATUS value.
Arg4: 0000000000000000, Low order 32-bits of the MCi_STATUS value.

Debugging Details:
------------------


BUGCHECK_STR:  0x124_GenuineIntel

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  0

STACK_TEXT: 
fffff880`035626f0 fffff800`02f21d29 : fffffa80`0a8008d0 fffffa80`09dab680 fffff8a0`001c3a70 00000000`00000000 : nt!WheapCreateLiveTriageDump+0x6c
fffff880`03562c10 fffff800`02e01217 : fffffa80`0a8008d0 fffff800`02e7b658 fffffa80`09dab680 00000000`00000000 : nt!WheapCreateTriageDumpFromPreviousSession+0x49
fffff880`03562c40 fffff800`02d68865 : fffff800`02edd3a0 00000000`00000001 fffff8a0`001c39e8 fffffa80`09dab680 : nt!WheapProcessWorkQueueItem+0x57
fffff880`03562c80 fffff800`02ce8a21 : fffff800`03100100 fffff800`02d68840 fffffa80`09dab600 00000000`00000000 : nt!WheapWorkQueueWorkerRoutine+0x25
fffff880`03562cb0 fffff800`02f7bcce : 00000000`00000000 fffffa80`09dab680 00000000`00000080 fffffa80`09d79070 : nt!ExpWorkerThread+0x111
fffff880`03562d40 fffff800`02ccffe6 : fffff880`0336a180 fffffa80`09dab680 fffff880`033750c0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`03562d80 00000000`00000000 : fffff880`03563000 fffff880`0355d000 fffff880`030c2540 00000000`00000000 : nt!KxStartSystemThread+0x16


STACK_COMMAND:  kb

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: hardware

IMAGE_NAME:  hardware

DEBUG_FLR_IMAGE_TIMESTAMP:  0

FAILURE_BUCKET_ID:  X64_0x124_GenuineIntel_PROCESSOR_MAE_PRV

BUCKET_ID:  X64_0x124_GenuineIntel_PROCESSOR_MAE_PRV

Followup: MachineOwner
---------

1: kd> !analyze -v
*******************************************************************************
*                                                                            *
*                        Bugcheck Analysis                                    *
*                                                                            *
*******************************************************************************

WHEA_UNCORRECTABLE_ERROR (124)
A fatal hardware error has occurred. Parameter 1 identifies the type of error
source that reported the error. Parameter 2 holds the address of the
WHEA_ERROR_RECORD structure that describes the error conditon.
Arguments:
Arg1: 0000000000000000, Machine Check Exception
Arg2: fffffa800a8008f8, Address of the WHEA_ERROR_RECORD structure.
Arg3: 0000000000000000, High order 32-bits of the MCi_STATUS value.
Arg4: 0000000000000000, Low order 32-bits of the MCi_STATUS value.

Debugging Details:
------------------


BUGCHECK_STR:  0x124_GenuineIntel

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  0

STACK_TEXT: 
fffff880`035626f0 fffff800`02f21d29 : fffffa80`0a8008d0 fffffa80`09dab680 fffff8a0`001c3a70 00000000`00000000 : nt!WheapCreateLiveTriageDump+0x6c
fffff880`03562c10 fffff800`02e01217 : fffffa80`0a8008d0 fffff800`02e7b658 fffffa80`09dab680 00000000`00000000 : nt!WheapCreateTriageDumpFromPreviousSession+0x49
fffff880`03562c40 fffff800`02d68865 : fffff800`02edd3a0 00000000`00000001 fffff8a0`001c39e8 fffffa80`09dab680 : nt!WheapProcessWorkQueueItem+0x57
fffff880`03562c80 fffff800`02ce8a21 : fffff800`03100100 fffff800`02d68840 fffffa80`09dab600 00000000`00000000 : nt!WheapWorkQueueWorkerRoutine+0x25
fffff880`03562cb0 fffff800`02f7bcce : 00000000`00000000 fffffa80`09dab680 00000000`00000080 fffffa80`09d79070 : nt!ExpWorkerThread+0x111
fffff880`03562d40 fffff800`02ccffe6 : fffff880`0336a180 fffffa80`09dab680 fffff880`033750c0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`03562d80 00000000`00000000 : fffff880`03563000 fffff880`0355d000 fffff880`030c2540 00000000`00000000 : nt!KxStartSystemThread+0x16


STACK_COMMAND:  kb

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: hardware

IMAGE_NAME:  hardware

DEBUG_FLR_IMAGE_TIMESTAMP:  0

FAILURE_BUCKET_ID:  X64_0x124_GenuineIntel_PROCESSOR_MAE_PRV

BUCKET_ID:  X64_0x124_GenuineIntel_PROCESSOR_MAE_PRV

Followup: MachineOwner
---------

Worauf deutet das hin?

Thx für sachdienliche Hinweise.
Quintus14


System: ASUS P6T, i7/950, 12GB Corsair, System auf Crucial M4, mehrere WD-HDDs, Sapphire Radeon 4870 1GB,

Inzersdorfer 25.01.2013 15:16

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)

Quintus14 25.01.2013 15:49

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

zonediver 25.01.2013 16:20

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.

Quintus14 25.01.2013 16:30

Thx, zonediver, für die Info. Ob ich mir allerdings die Arbeit antu'...?

Zitat:

Zitat von Quintus14 (Beitrag 2483252)
... ebendort soll das Deaktivieren von CE1 im BIOS etwas gebracht haben ... das hab' ich jetzt auch mal deaktiviert ...

PCProbe-II zeigt mir aber Vcore im idle trotzdem nur mit 0,94V an. Hmmm ... reicht das Verdrehen von C1E als Versuch einmal(?) oder was müsste ich im BIOS verdrehen, damit ich im idle ein wenig mehr hab'?

Thx
Quintus

Inzersdorfer 25.01.2013 20:16

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)

Quintus14 25.01.2013 20:34

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

Quintus14 26.01.2013 17:30

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
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump\012613-21060-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17514.amd64fre.win7sp1_rtm.101119-1850
Machine Name:
Kernel base = 0xfffff800`02c58000 PsLoadedModuleList = 0xfffff800`02e9de90
Debug session time: Sat Jan 26 17:01:15.030 2013 (GMT+1)
System Uptime: 0 days 9:05:09.029
Loading Kernel Symbols
...............................................................
................................................................
................................
Loading User Symbols
Loading unloaded module list
.....
*******************************************************************************
*                                                                            *
*                        Bugcheck Analysis                                    *
*                                                                            *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 9C, {0, fffff88003090c70, 0, 0}

Unable to load image \SystemRoot\system32\DRIVERS\intelppm.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for intelppm.sys
*** ERROR: Module load completed but symbols could not be loaded for intelppm.sys
Probably caused by : intelppm.sys ( intelppm+39c2 )

Followup: MachineOwner
---------

5: kd> !analyze -v
*******************************************************************************
*                                                                            *
*                        Bugcheck Analysis                                    *
*                                                                            *
*******************************************************************************

MACHINE_CHECK_EXCEPTION (9c)
A fatal Machine Check Exception has occurred.
KeBugCheckEx parameters;
    x86 Processors
        If the processor has ONLY MCE feature available (For example Intel
        Pentium), the parameters are:
        1 - Low  32 bits of P5_MC_TYPE MSR
        2 - Address of MCA_EXCEPTION structure
        3 - High 32 bits of P5_MC_ADDR MSR
        4 - Low  32 bits of P5_MC_ADDR MSR
        If the processor also has MCA feature available (For example Intel
        Pentium Pro), the parameters are:
        1 - Bank number
        2 - Address of MCA_EXCEPTION structure
        3 - High 32 bits of MCi_STATUS MSR for the MCA bank that had the error
        4 - Low  32 bits of MCi_STATUS MSR for the MCA bank that had the error
    IA64 Processors
        1 - Bugcheck Type
            1 - MCA_ASSERT
            2 - MCA_GET_STATEINFO
                SAL returned an error for SAL_GET_STATEINFO while processing MCA.
            3 - MCA_CLEAR_STATEINFO
                SAL returned an error for SAL_CLEAR_STATEINFO while processing MCA.
            4 - MCA_FATAL
                FW reported a fatal MCA.
            5 - MCA_NONFATAL
                SAL reported a recoverable MCA and we don't support currently
                support recovery or SAL generated an MCA and then couldn't
                produce an error record.
            0xB - INIT_ASSERT
            0xC - INIT_GET_STATEINFO
                  SAL returned an error for SAL_GET_STATEINFO while processing INIT event.
            0xD - INIT_CLEAR_STATEINFO
                  SAL returned an error for SAL_CLEAR_STATEINFO while processing INIT event.
            0xE - INIT_FATAL
                  Not used.
        2 - Address of log
        3 - Size of log
        4 - Error code in the case of x_GET_STATEINFO or x_CLEAR_STATEINFO
    AMD64 Processors
        1 - Bank number
        2 - Address of MCA_EXCEPTION structure
        3 - High 32 bits of MCi_STATUS MSR for the MCA bank that had the error
        4 - Low  32 bits of MCi_STATUS MSR for the MCA bank that had the error
Arguments:
Arg1: 0000000000000000
Arg2: fffff88003090c70
Arg3: 0000000000000000
Arg4: 0000000000000000

Debugging Details:
------------------


BUGCHECK_STR:  0x9C_GenuineIntel

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  f

LAST_CONTROL_TRANSFER:  from fffff80002c21818 to fffff80002cd8640

STACK_TEXT: 
fffff880`03090c38 fffff800`02c21818 : 00000000`0000009c 00000000`00000000 fffff880`03090c70 00000000`00000000 : nt!KeBugCheckEx
fffff880`03090c40 fffff800`02c20f57 : 00000000`00000008 00000000`00000000 00000000`00000008 00000000`00000000 : hal!HalpMcaReportError+0x164
fffff880`03090d90 fffff800`02c14e88 : 00000000`00000000 fffff880`03088180 00000000`00000000 00000000`00000000 : hal!HalpMceHandlerWithRendezvous+0x9f
fffff880`03090dc0 fffff800`02cd6f2c : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : hal!HalHandleMcheck+0x40
fffff880`03090df0 fffff800`02cd6d93 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxMcheckAbort+0x6c
fffff880`03090f30 fffff880`03fa09c2 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiMcheckAbort+0x153
fffff880`030b0c98 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : intelppm+0x39c2


STACK_COMMAND:  kb

FOLLOWUP_IP:
intelppm+39c2
fffff880`03fa09c2 ??              ???

SYMBOL_STACK_INDEX:  6

SYMBOL_NAME:  intelppm+39c2

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: intelppm

IMAGE_NAME:  intelppm.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bc0fd

FAILURE_BUCKET_ID:  X64_0x9C_GenuineIntel_intelppm+39c2

BUCKET_ID:  X64_0x9C_GenuineIntel_intelppm+39c2

Followup: MachineOwner
---------

5: kd> !errec fffff88003090c70
No export errec found

Weist die Geschichte immer noch auf ein Spannungsproblem hin (der STOP-Code ist ja jetzt etwas anders)???

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

Mobiletester 26.01.2013 22:16

Zitat:

Zitat von zonediver (Beitrag 2483253)
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.

Wobei man das meist schon optisch beurteilen kann. Messen kann man es am Besten mit einem ESR Messgerät in der Schaltung.

Quintus14 26.01.2013 22:45

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).

Inzersdorfer 29.01.2013 18:35

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.

Quintus14 29.01.2013 20:14

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

Quintus14 15.02.2013 15:38

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
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump\021513-23306-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17514.amd64fre.win7sp1_rtm.101119-1850
Machine Name:
Kernel base = 0xfffff800`02c11000 PsLoadedModuleList = 0xfffff800`02e56e90
Debug session time: Fri Feb 15 15:16:31.817 2013 (GMT+1)
System Uptime: 0 days 7:44:48.832
Loading Kernel Symbols
...............................................................
................................................................
...............................
Loading User Symbols
Loading unloaded module list
....
*******************************************************************************
*                                                                            *
*                        Bugcheck Analysis                                    *
*                                                                            *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 124, {0, fffffa800b26e028, be000000, 800400}

Probably caused by : hardware

Followup: MachineOwner
---------

0: kd> !analyze -v
*******************************************************************************
*                                                                            *
*                        Bugcheck Analysis                                    *
*                                                                            *
*******************************************************************************

WHEA_UNCORRECTABLE_ERROR (124)
A fatal hardware error has occurred. Parameter 1 identifies the type of error
source that reported the error. Parameter 2 holds the address of the
WHEA_ERROR_RECORD structure that describes the error conditon.
Arguments:
Arg1: 0000000000000000, Machine Check Exception
Arg2: fffffa800b26e028, Address of the WHEA_ERROR_RECORD structure.
Arg3: 00000000be000000, High order 32-bits of the MCi_STATUS value.
Arg4: 0000000000800400, Low order 32-bits of the MCi_STATUS value.

Debugging Details:
------------------


BUGCHECK_STR:  0x124_GenuineIntel

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  EDIUS.exe

CURRENT_IRQL:  f

STACK_TEXT: 
fffff800`041c7a98 fffff800`0320da3b : 00000000`00000124 00000000`00000000 fffffa80`0b26e028 00000000`be000000 : nt!KeBugCheckEx
fffff800`041c7aa0 fffff800`02d9e7d3 : 00000000`00000001 fffffa80`0b0b3870 00000000`00000000 fffffa80`0b0b38c0 : hal!HalBugCheckSystem+0x1e3
fffff800`041c7ae0 fffff800`0320d700 : 00000000`00000728 fffffa80`0b0b3870 fffff800`041c7e70 fffff800`041c7e00 : nt!WheaReportHwError+0x263
fffff800`041c7b40 fffff800`0320d052 : fffffa80`0b0b3870 fffff800`041c7e70 fffffa80`0b0b3870 00000000`00000000 : hal!HalpMcaReportError+0x4c
fffff800`041c7c90 fffff800`0320cf0d : 00000000`00000008 00000000`00000001 fffff800`041c7ef0 00000000`00000000 : hal!HalpMceHandler+0x9e
fffff800`041c7cd0 fffff800`03200e88 : 00000000`62acbb9e 00000000`62770f00 00000000`00000000 00000000`00000000 : hal!HalpMceHandlerWithRendezvous+0x55
fffff800`041c7d00 fffff800`02c8ff2c : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : hal!HalHandleMcheck+0x40
fffff800`041c7d30 fffff800`02c8fd93 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxMcheckAbort+0x6c
fffff800`041c7e70 00000000`0edffba3 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiMcheckAbort+0x153
00000000`26d9ecfc 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0xedffba3


STACK_COMMAND:  kb

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: hardware

IMAGE_NAME:  hardware

DEBUG_FLR_IMAGE_TIMESTAMP:  0

FAILURE_BUCKET_ID:  X64_0x124_GenuineIntel_PROCESSOR_MAE

BUCKET_ID:  X64_0x124_GenuineIntel_PROCESSOR_MAE

Followup: MachineOwner
---------

0: kd> !analyze -v
*******************************************************************************
*                                                                            *
*                        Bugcheck Analysis                                    *
*                                                                            *
*******************************************************************************

WHEA_UNCORRECTABLE_ERROR (124)
A fatal hardware error has occurred. Parameter 1 identifies the type of error
source that reported the error. Parameter 2 holds the address of the
WHEA_ERROR_RECORD structure that describes the error conditon.
Arguments:
Arg1: 0000000000000000, Machine Check Exception
Arg2: fffffa800b26e028, Address of the WHEA_ERROR_RECORD structure.
Arg3: 00000000be000000, High order 32-bits of the MCi_STATUS value.
Arg4: 0000000000800400, Low order 32-bits of the MCi_STATUS value.

Debugging Details:
------------------


BUGCHECK_STR:  0x124_GenuineIntel

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  EDIUS.exe

CURRENT_IRQL:  f

STACK_TEXT: 
fffff800`041c7a98 fffff800`0320da3b : 00000000`00000124 00000000`00000000 fffffa80`0b26e028 00000000`be000000 : nt!KeBugCheckEx
fffff800`041c7aa0 fffff800`02d9e7d3 : 00000000`00000001 fffffa80`0b0b3870 00000000`00000000 fffffa80`0b0b38c0 : hal!HalBugCheckSystem+0x1e3
fffff800`041c7ae0 fffff800`0320d700 : 00000000`00000728 fffffa80`0b0b3870 fffff800`041c7e70 fffff800`041c7e00 : nt!WheaReportHwError+0x263
fffff800`041c7b40 fffff800`0320d052 : fffffa80`0b0b3870 fffff800`041c7e70 fffffa80`0b0b3870 00000000`00000000 : hal!HalpMcaReportError+0x4c
fffff800`041c7c90 fffff800`0320cf0d : 00000000`00000008 00000000`00000001 fffff800`041c7ef0 00000000`00000000 : hal!HalpMceHandler+0x9e
fffff800`041c7cd0 fffff800`03200e88 : 00000000`62acbb9e 00000000`62770f00 00000000`00000000 00000000`00000000 : hal!HalpMceHandlerWithRendezvous+0x55
fffff800`041c7d00 fffff800`02c8ff2c : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : hal!HalHandleMcheck+0x40
fffff800`041c7d30 fffff800`02c8fd93 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxMcheckAbort+0x6c
fffff800`041c7e70 00000000`0edffba3 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiMcheckAbort+0x153
00000000`26d9ecfc 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0xedffba3


STACK_COMMAND:  kb

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: hardware

IMAGE_NAME:  hardware

DEBUG_FLR_IMAGE_TIMESTAMP:  0

FAILURE_BUCKET_ID:  X64_0x124_GenuineIntel_PROCESSOR_MAE

BUCKET_ID:  X64_0x124_GenuineIntel_PROCESSOR_MAE

Followup: MachineOwner
---------

Thx & lG
Quintus14

ASUS P6T, 12 GB Corsair, Crucial M4 als System, einige WD-HDDs, Sapphire Radeon 4870, Grass Valley HD Storm

Quintus14 15.02.2013 15:51

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
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump\021513-111244-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17514.amd64fre.win7sp1_rtm.101119-1850
Machine Name:
Kernel base = 0xfffff800`02c51000 PsLoadedModuleList = 0xfffff800`02e96e90
Debug session time: Fri Feb 15 15:44:59.336 2013 (GMT+1)
System Uptime: 0 days 0:26:31.350
Loading Kernel Symbols
....................................................Unable to load image Unknown_Module_00000000`00000000, Win32 error 0n2
*** WARNING: Unable to verify timestamp for Unknown_Module_00000000`00000000
Unable to add module at 00000000`00000000

Loading User Symbols
*******************************************************************************
*                                                                            *
*                        Bugcheck Analysis                                    *
*                                                                            *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 101, {19, 0, fffff880009b2180, 4}

Unable to load image SCSIPORT.SYS, Win32 error 0n2
*** WARNING: Unable to verify timestamp for SCSIPORT.SYS
*** ERROR: Module load completed but symbols could not be loaded for SCSIPORT.SYS
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )

Followup: MachineOwner
---------

0: kd> !analyze -v
*******************************************************************************
*                                                                            *
*                        Bugcheck Analysis                                    *
*                                                                            *
*******************************************************************************

CLOCK_WATCHDOG_TIMEOUT (101)
An expected clock interrupt was not received on a secondary processor in an
MP system within the allocated interval. This indicates that the specified
processor is hung and not processing interrupts.
Arguments:
Arg1: 0000000000000019, Clock interrupt time out interval in nominal clock ticks.
Arg2: 0000000000000000, 0.
Arg3: fffff880009b2180, The PRCB address of the hung processor.
Arg4: 0000000000000004, 0.

Debugging Details:
------------------


BUGCHECK_STR:  CLOCK_WATCHDOG_TIMEOUT_8_PROC

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  d

STACK_TEXT: 
fffff800`041b95b8 fffff800`02d28a89 : 00000000`00000101 00000000`00000019 00000000`00000000 fffff880`009b2180 : nt!KeBugCheckEx
fffff800`041b95c0 fffff800`02cdbeb7 : fffff800`00000000 fffff800`00000004 00000000`00002710 fffff800`02dbf0e0 : nt! ?? ::FNODOBFM::`string'+0x4e2e
fffff800`041b9650 fffff800`02c12895 : fffff800`02c38460 fffff800`041b9800 fffff800`02c38460 fffff880`00000000 : nt!KeUpdateSystemTime+0x377
fffff800`041b9750 fffff800`02ccdb73 : 00000000`00000010 fffff880`04a2d1c8 00000000`00008000 fffff880`03e072b6 : hal!HalpHpetClockInterrupt+0x8d
fffff800`041b9780 fffff800`02cd7206 : fffff800`02e43e80 fffffa80`00000001 00000000`00000000 fffff800`041b9a38 : nt!KiInterruptDispatchNoLock+0x163
fffff800`041b9910 fffff800`02c6f869 : 00000000`00000014 fffff880`0b9c2000 00000000`00000000 00000000`000000fe : nt!KeFlushMultipleRangeTb+0x266
fffff800`041b99e0 fffff800`02d3ff23 : 00000000`00000001 fffff880`0b9c28c0 fffff6fc`4005ce10 fffff800`00000001 : nt!MiRemoveIoSpaceMap+0xe9
fffff800`041b9b10 fffff880`01059d3e : fffffa80`0b71d978 fffffa80`0a3abcc0 fffffa80`0a3ad760 fffff800`02d7b3d0 : nt! ?? ::FNODOBFM::`string'+0x3703d
fffff800`041b9b60 fffffa80`0b71d978 : fffffa80`0a3abcc0 fffffa80`0a3ad760 fffff800`02d7b3d0 fffffa80`0a3ad700 : SCSIPORT+0x7d3e
fffff800`041b9b68 fffffa80`0a3abcc0 : fffffa80`0a3ad760 fffff800`02d7b3d0 fffffa80`0a3ad700 00000000`00000000 : 0xfffffa80`0b71d978
fffff800`041b9b70 fffffa80`0a3ad760 : fffff800`02d7b3d0 fffffa80`0a3ad700 00000000`00000000 00000000`00000000 : 0xfffffa80`0a3abcc0
fffff800`041b9b78 fffff800`02d7b3d0 : fffffa80`0a3ad700 00000000`00000000 00000000`00000000 fffff800`02ccced6 : 0xfffffa80`0a3ad760
fffff800`041b9b80 fffffa80`0a3abcc0 : fffffa80`0a3ad610 00000000`00000000 00000000`00000000 fffffa80`0a3ad6d8 : nt!IopStartNextPacket+0x40
fffff800`041b9bb0 fffffa80`0a3ad610 : 00000000`00000000 00000000`00000000 fffffa80`0a3ad6d8 fffffa80`0a3ad600 : 0xfffffa80`0a3abcc0
fffff800`041b9bb8 00000000`00000000 : 00000000`00000000 fffffa80`0a3ad6d8 fffffa80`0a3ad600 fffff880`010578c7 : 0xfffffa80`0a3ad610


STACK_COMMAND:  kb

SYMBOL_NAME:  ANALYSIS_INCONCLUSIVE

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME:  Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP:  0

FAILURE_BUCKET_ID:  X64_CLOCK_WATCHDOG_TIMEOUT_8_PROC_ANALYSIS_INCONCLUSIVE

BUCKET_ID:  X64_CLOCK_WATCHDOG_TIMEOUT_8_PROC_ANALYSIS_INCONCLUSIVE

Followup: MachineOwner
---------


lalaker 15.02.2013 16:56

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.

Quintus14 15.02.2013 17:01

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?

Baron 15.02.2013 17:13

Dann solltest über eine neue Software nachdenken! Was sagt der Softwareproduzent dazu?

Quintus14 15.02.2013 17:45

Der meint RAM oder RAM/Treiber der GraKa.

Baron 15.02.2013 17:53

Da du den Ram eh schon getauscht hast -nimm lalakers Graka (Biete Forum) billiger wie ein komplettausch!

Quintus14 15.02.2013 18:10

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.

Inzersdorfer 15.02.2013 20:04

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..)

Quintus14 15.02.2013 21:43

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...
.

Mobiletester 15.02.2013 22:05

Probiers mal nur mit 2 RAM. Der defekte RAM Bereich wird offensichtlich zielsicher von Deiner Anwendung adressiert.

Quintus14 15.02.2013 22:36

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

Quintus14 15.02.2013 23:08

@ Inzersdorfer: danke!!!

Inzersdorfer 15.02.2013 23:48

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.

Quintus14 16.02.2013 07:46

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

Quintus14 16.02.2013 08:32

Zitat:

Zitat von Quintus14 (Beitrag 2484078)
Vcore hab' ich jetzt auf 1.05 gesetzt ... seit ich Vcore manuell eingestellt hab', bleibt's bei dem Wert, da ändert sich nix zwischen Volllast und idle.

Wie gesagt - im BIOS auf 1.05 gestellt. PCProbe-II zeigt mir 1,03 im idle und 1,04 unter Belastung. Nachdem die CPU-Temperatur auch bei moderaten 60 Grad bleibt - muss ich jetzt davon ausgehen, dass der i7 nun gar nicht zur vollen Performance aufläuft?

Thx

Lowrider20 16.02.2013 08:56

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.

Quintus14 17.02.2013 08:19

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