Bluescreen - Fehler finden

Sephirio

Lt. Commander
Registriert
Sep. 2011
Beiträge
1.080
Hatte grad nen Bluescreen. Es KÖNNTE am OC liegen (zu wenig VCORE) wobei Prime läuft und der Bluescreen einfach so beim surfen kam....hier der Minidump. Kann ihn nicht interpretieren und finde den STOP CODE nicht. :(



Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


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

Symbol search path is: SRV*C:\Windows\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: C:\Windows\System32
Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`0325f000 PsLoadedModuleList = 0xfffff800`034a4670
Debug session time: Sat Nov 19 23:04:03.990 2011 (UTC + 1:00)
System Uptime: 0 days 4:12:46.208
Loading Kernel Symbols
...............................................................
................................................................
...................
Loading User Symbols
Loading unloaded module list
............
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1E, {0, 0, 0, 0}

Probably caused by : ntkrnlmp.exe ( nt!KiKernelCalloutExceptionHandler+e )

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

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

KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: 0000000000000000, The exception code that was not handled
Arg2: 0000000000000000, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: 0000000000000000, Parameter 1 of the exception

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


EXCEPTION_CODE: (Win32) 0 (0) - Der Vorgang wurde erfolgreich beendet.

FAULTING_IP:
+6262613530613233
00000000`00000000 ?? ???

EXCEPTION_PARAMETER1: 0000000000000000

EXCEPTION_PARAMETER2: 0000000000000000

ERROR_CODE: (NTSTATUS) 0 - STATUS_WAIT_0

BUGCHECK_STR: 0x1E_0

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 2

EXCEPTION_RECORD: fffff88002fff268 -- (.exr 0xfffff88002fff268)
ExceptionAddress: fffff800032e741a (nt!KiProcessExpiredTimerList+0x000000000000004a)
ExceptionCode: c000001d (Illegal instruction)
ExceptionFlags: 00000000
NumberParameters: 0

TRAP_FRAME: fffff88002fff310 -- (.trap 0xfffff88002fff310)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000002 rbx=0000000000000000 rcx=fffffa8006f8e700
rdx=0000000000000102 rsi=0000000000000000 rdi=0000000000000000
rip=fffff800032e741a rsp=fffff88002fff4a0 rbp=00000000000ed59a
r8=fffff88002fd9301 r9=0000000000000005 r10=000000000000009a
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na pe nc
nt!KiProcessExpiredTimerList+0x4a:
fffff800`032e741a f00fba2b07 lock bts dword ptr [rbx],7 ds:f400:00000000`00000000=????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff800032d35fe to fffff800032dbc10

STACK_TEXT:
fffff880`02ffe348 fffff800`032d35fe : 00000000`00000000 fffff880`0f069002 fffff880`02ffeac0 fffff800`03307830 : nt!KeBugCheck
fffff880`02ffe350 fffff800`033074fd : fffff800`034e571c fffff800`03422c30 fffff800`0325f000 fffff880`02fff268 : nt!KiKernelCalloutExceptionHandler+0xe
fffff880`02ffe380 fffff800`033062d5 : fffff800`034260fc fffff880`02ffe3f8 fffff880`02fff268 fffff800`0325f000 : nt!RtlpExecuteHandlerForException+0xd
fffff880`02ffe3b0 fffff800`03317361 : fffff880`02fff268 fffff880`02ffeac0 fffff880`00000000 fffff880`02fff4c8 : nt!RtlDispatchException+0x415
fffff880`02ffea90 fffff800`032db2c2 : fffff880`02fff268 fffffa80`070c4c20 fffff880`02fff310 00000000`00000003 : nt!KiDispatchException+0x135
fffff880`02fff130 fffff800`032d941f : fffff880`02fff310 00000000`00172502 00000000`00000000 fffff880`00000000 : nt!KiExceptionDispatch+0xc2
fffff880`02fff310 fffff800`032e741a : fffffa80`06f8e720 fffffa80`070c4c68 fffffa80`070c4c68 00000000`00000102 : nt!KiInvalidOpcodeFault+0x11f
fffff880`02fff4a0 fffff800`032e737e : 00000023`4fc3bc9f fffff880`02fffb18 00000000`000ed59a fffff880`02fda8c8 : nt!KiProcessExpiredTimerList+0x4a
fffff880`02fffaf0 fffff800`032e7167 : 0000000b`5ab203c4 0000000b`000ed59a 0000000b`5ab2039d 00000000`0000009a : nt!KiTimerExpiration+0x1be
fffff880`02fffb90 fffff800`032d396a : fffff880`02fd7180 fffff880`02fe1fc0 00000000`00000001 fffff800`00000000 : nt!KiRetireDpcList+0x277
fffff880`02fffc40 00000000`00000000 : fffff880`03000000 fffff880`02ffa000 fffff880`02fffc00 00000000`00000000 : nt!KiIdleLoop+0x5a


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KiKernelCalloutExceptionHandler+e
fffff800`032d35fe 90 nop

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt!KiKernelCalloutExceptionHandler+e

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4e02aaa3

FAILURE_BUCKET_ID: X64_0x1E_0_nt!KiKernelCalloutExceptionHandler+e

BUCKET_ID: X64_0x1E_0_nt!KiKernelCalloutExceptionHandler+e

Followup: MachineOwner
---------
 
Daß mit den increase Vcore kennst du ja.
Interessant ist hier der Exception Code: c000001d (Illegal instruction), im Stack nt!KiInvalidOpcodeFault bezeichnet.
Zitat MS: "If you plan to debug this problem, you may find it difficult to obtain a stack trace. Parameter 2 (the exception address) should pinpoint the driver or function that caused this problem."
Hier gibt es garkeine Parameter (Arg1-4), daß läßt mehrere Schlüße zu:
a) Hardwarefehler (am wahrscheinlichsten)
b) Treiberproblem (hier scheinbar ohne Spuren davon)
c) der .dmp ist unvollständig

Wenn du möchtest, packe die .dmp mit 7zip od. Winrar und lade sie hier als Anhang hoch, dann könnt ich testen, ob doch etwas Erhellenderes herauszuholen ist, allerdings glaub ich nicht daran.
 
Zuletzt bearbeitet:
Prime ist nicht alles. Selbst wenn die Kiste Primestable ist, können Probleme durch das OC -z.B. in "idle" Situationen (bei Lastwechsel) auftreten.

In der obigen Auswertung ist kein Treiber für den Absturz verantwortlich. Naheliegend, dass das Problem durch die Übertaktung hervorgerufen wurde.
 
Danke Leute. Habe Offset um +.010v hochgestellt, seitdem keine Probleme mehr...schauen wir mal.
Ergänzung ()

Und jetzt hat es doch wieder geknallt...hier die Meldung:


Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


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

Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path. *
* Use .symfix to have the debugger choose a symbol path. *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************
Unable to load image \SystemRoot\system32\ntoskrnl.exe, Win32 error 0n2
*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe
Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`0320b000 PsLoadedModuleList = 0xfffff800`03450670
Debug session time: Mon Nov 21 23:03:11.747 2011 (UTC + 1:00)
System Uptime: 0 days 2:31:58.591
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* *
* The Symbol Path can be set by: *
* using the _NT_SYMBOL_PATH environment variable. *
* using the -y <symbol_path> argument when starting the debugger. *
* using .sympath and .sympath+ *
*********************************************************************
Unable to load image \SystemRoot\system32\ntoskrnl.exe, Win32 error 0n2
*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe
Loading Kernel Symbols
...............................................................
................................................................
.....................
Loading User Symbols
Loading unloaded module list
........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 3B, {c0000005, fffff8000328d050, fffff8800c231f60, 0}

*** WARNING: Unable to verify timestamp for mssmbios.sys
*** ERROR: Module load completed but symbols could not be loaded for mssmbios.sys
***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
Probably caused by : ntoskrnl.exe ( nt+82050 )

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

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

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff8000328d050, Address of the instruction which caused the bugcheck
Arg3: fffff8800c231f60, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.

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

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************

ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.

MODULE_NAME: nt

FAULTING_MODULE: fffff8000320b000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 4e02aaa3

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.

FAULTING_IP:
nt+82050
fffff800`0328d050 f04c2123 lock and qword ptr [rbx],r12

CONTEXT: fffff8800c231f60 -- (.cxr 0xfffff8800c231f60)
rax=fffffa800963a080 rbx=ffbdf88002f68280 rcx=fffff88002f68288
rdx=0000000000000000 rsi=fffffa8007e6ec20 rdi=0000000000000100
rip=fffff8000328d050 rsp=fffff8800c232940 rbp=0000000000000001
r8=fffff8000320b000 r9=0000000000000000 r10=fffffffffffffffb
r11=fffff88002f65100 r12=0000000000000000 r13=0000000000000000
r14=fffff88002f67380 r15=0000000000000068
iopl=0 nv up ei pl nz ac pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010212
nt+0x82050:
fffff800`0328d050 f04c2123 lock and qword ptr [rbx],r12 ds:002b:ffbdf880`02f68280=????????????????
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x3B

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff8000328d050

STACK_TEXT:
fffff880`0c232940 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt+0x82050


FOLLOWUP_IP:
nt+82050
fffff800`0328d050 f04c2123 lock and qword ptr [rbx],r12

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt+82050

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: ntoskrnl.exe

STACK_COMMAND: .cxr 0xfffff8800c231f60 ; kb

BUCKET_ID: WRONG_SYMBOLS

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

Habe Offset noch ein wenig angehoben jetzt, mehr Spannung. Hoffentlich hilft das. Oder wonach sieht es aus?
 
Mal abgesehen, dass der Symbolpfad (im Debugger) nicht korrekt hinterlegt ist, ist in der geposteten Auswertung eine Speicherzugriffsverletzung verzeichnet. (peicher i.d.S. kann neben RAM auch der CPU-Cache sein, der durch die Übertaktung / zu wenig Spannung nicht korrekt arbeiten konnte.

Schau ma mal, ob die Erhöhung nun ausgereicht hat.
 
Zurück
Oben