ja... der verursacher scheint ziemlich random zu sein, hab jetzt die beiden dumps davor auch analysiert da war skype nicht involviert:
1)
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [D:\030511-9297-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 7600 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7600.16695.amd64fre.win7_gdr.101026-1503
Machine Name:
Kernel base = 0xfffff800`03068000 PsLoadedModuleList = 0xfffff800`032a5e50
Debug session time: Sat Mar 5 20:33:40.591 2011 (UTC + 1:00)
System Uptime: 0 days 0:11:05.778
Loading Kernel Symbols
...............................................................
................................................................
...................................
Loading User Symbols
Loading unloaded module list
.....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 1000007E, {ffffffffc0000005, fffff88004341fe8, fffff88006ffe698, fffff88006ffdf00}
Probably caused by : dxgmms1.sys ( dxgmms1!VIDMM_GLOBAL::ReferenceAllocationForSubmission+98 )
Followup: MachineOwner
---------
6: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
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.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff88004341fe8, The address that the exception occurred at
Arg3: fffff88006ffe698, Exception Record Address
Arg4: fffff88006ffdf00, Context Record Address
Debugging Details:
------------------
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:
dxgmms1!VIDMM_GLOBAL::ReferenceAllocationForSubmission+98
fffff880`04341fe8 48035020 add rdx,qword ptr [rax+20h]
EXCEPTION_RECORD: fffff88006ffe698 -- (.exr 0xfffff88006ffe698)
ExceptionAddress: fffff88004341fe8 (dxgmms1!VIDMM_GLOBAL::ReferenceAllocationForSubmission+0x0000000000000098)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: ffffffffffffffff
Attempt to read from address ffffffffffffffff
CONTEXT: fffff88006ffdf00 -- (.cxr 0xfffff88006ffdf00)
rax=ffbff8a010d53350 rbx=fffff8a013615480 rcx=fffffa8003ac23f0
rdx=0000000000000000 rsi=fffffa80054af900 rdi=fffffa8005b01000
rip=fffff88004341fe8 rsp=fffff88006ffe8d0 rbp=0000000000000000
r8=fffffa80054af950 r9=fffff88006ffe901 r10=0000000000000000
r11=fffffa8005980410 r12=0000000000000063 r13=0000000000000000
r14=fffffa8003aa7010 r15=00000000000000d1
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010246
dxgmms1!VIDMM_GLOBAL::ReferenceAllocationForSubmission+0x98:
fffff880`04341fe8 48035020 add rdx,qword ptr [rax+20h] ds:002b:ffbff8a0`10d53370=????????????????
Resetting default scope
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: 0
ERROR_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.
EXCEPTION_PARAMETER1: 0000000000000000
EXCEPTION_PARAMETER2: ffffffffffffffff
READ_ADDRESS: GetPointerFromAddress: unable to read from fffff800033100e0
ffffffffffffffff
FOLLOWUP_IP:
dxgmms1!VIDMM_GLOBAL::ReferenceAllocationForSubmission+98
fffff880`04341fe8 48035020 add rdx,qword ptr [rax+20h]
BUGCHECK_STR: 0x7E
LAST_CONTROL_TRANSFER: from fffff8800433f8af to fffff88004341fe8
STACK_TEXT:
fffff880`06ffe8d0 fffff880`0433f8af : 00000000`00000000 fffffa80`0390f318 00000000`000000d1 fffffa80`03ae2950 : dxgmms1!VIDMM_GLOBAL::ReferenceAllocationForSubmission+0x98
fffff880`06ffe910 fffff880`0435965d : 00000000`00000000 fffff8a0`10d53350 fffffa80`00000000 fffffa80`03aa7010 : dxgmms1!VIDMM_GLOBAL:
repareDmaBuffer+0xe1b
fffff880`06ffeae0 fffff880`04359398 : fffff800`04659080 fffff880`04358d00 fffffa80`00000000 fffffa80`00000000 : dxgmms1!VidSchiSubmitRenderCommand+0x241
fffff880`06ffecd0 fffff880`04358e96 : 00000000`00000000 fffffa80`04508c50 00000000`00000080 fffffa80`05980410 : dxgmms1!VidSchiSubmitQueueCommand+0x50
fffff880`06ffed00 fffff800`0337b7c6 : 00000000`018e3ebf fffffa80`05907b60 fffffa80`036cfae0 fffffa80`05907b60 : dxgmms1!VidSchiWorkerThread+0xd6
fffff880`06ffed40 fffff800`030b6c26 : fffff800`03252e80 fffffa80`05907b60 fffff800`03260c40 fffff880`01247534 : nt!PspSystemThreadStartup+0x5a
fffff880`06ffed80 00000000`00000000 : fffff880`06fff000 fffff880`06ff9000 fffff880`06ffe690 00000000`00000000 : nt!KxStartSystemThread+0x16
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: dxgmms1!VIDMM_GLOBAL::ReferenceAllocationForSubmission+98
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: dxgmms1
IMAGE_NAME: dxgmms1.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4d3fa174
STACK_COMMAND: .cxr 0xfffff88006ffdf00 ; kb
FAILURE_BUCKET_ID: X64_0x7E_dxgmms1!VIDMM_GLOBAL::ReferenceAllocationForSubmission+98
BUCKET_ID: X64_0x7E_dxgmms1!VIDMM_GLOBAL::ReferenceAllocationForSubmission+98
Followup: MachineOwner
---------
2)
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [D:\022711-9906-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 7600 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7600.16695.amd64fre.win7_gdr.101026-1503
Machine Name:
Kernel base = 0xfffff800`03005000 PsLoadedModuleList = 0xfffff800`03242e50
Debug session time: Sun Feb 27 20:47:33.722 2011 (UTC + 1:00)
System Uptime: 0 days 8:39:55.969
Loading Kernel Symbols
...............................................................
................................................................
.................................
Loading User Symbols
Loading unloaded module list
........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 7F, {8, 80050031, 6f8, fffff9600016ba3c}
Probably caused by : win32k.sys ( win32k!AllocQEntry+38 )
Followup: MachineOwner
---------
3: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: 0000000080050031
Arg3: 00000000000006f8
Arg4: fffff9600016ba3c
Debugging Details:
------------------
BUGCHECK_STR: 0x7f_8
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: mswinext.exe
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from fffff80003074ca9 to fffff80003075740
STACK_TEXT:
fffff880`031d9de8 fffff800`03074ca9 : 00000000`0000007f 00000000`00000008 00000000`80050031 00000000`000006f8 : nt!KeBugCheckEx
fffff880`031d9df0 fffff800`03073172 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`031d9f30 fffff960`0016ba3c : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb2
00000000`0d23fa88 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : win32k!AllocQEntry+0x38
STACK_COMMAND: kb
FOLLOWUP_IP:
win32k!AllocQEntry+38
fffff960`0016ba3c ff15d6581d00 call qword ptr [win32k!_imp_ExpInterlockedPopEntrySList (fffff960`00341318)]
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: win32k!AllocQEntry+38
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: win32k
IMAGE_NAME: win32k.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4d23ecb0
FAILURE_BUCKET_ID: X64_0x7f_8_win32k!AllocQEntry+38
BUCKET_ID: X64_0x7f_8_win32k!AllocQEntry+38
Followup: MachineOwner
---------
