Code:
-
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [D:\Kingston\BSODDmpFiles\BinaryZael\Windows_NT6_BSOD_jcgriff2\030912-19874-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 (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`03016000 PsLoadedModuleList = 0xfffff800`0325b670
Debug session time: Thu Mar 8 23:41:56.577 2012 (UTC - 6:00)
System Uptime: 0 days 13:34:25.200
Loading Kernel Symbols
...............................................................
................................................................
...................
Loading User Symbols
Loading unloaded module list
.....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 50, {fffff88008e19c78, 1, fffff80003050ab4, 1}
Could not read faulting driver name
Probably caused by : ntkrnlmp.exe ( nt!KeEnumerateKernelStackSegments+28 )
Followup: MachineOwner
---------
3: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: fffff88008e19c78, memory referenced.
Arg2: 0000000000000001, value 0 = read operation, 1 = write operation.
Arg3: fffff80003050ab4, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 0000000000000001, (reserved)
Debugging Details:
------------------
Could not read faulting driver name
WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff800032c5100
fffff88008e19c78
FAULTING_IP:
nt!KeEnumerateKernelStackSegments+28
fffff800`03050ab4 48894508 mov qword ptr [rbp+8],rax
MM_INTERNAL_CODE: 1
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0x50
PROCESS_NAME: System
CURRENT_IRQL: 0
TRAP_FRAME: fffff8800331d850 -- (.trap 0xfffff8800331d850)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff88008e12000 rbx=0000000000000000 rcx=fffffa80075278e0
rdx=fffff80003050458 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80003050ab4 rsp=fffff8800331d9e0 rbp=fffff88008e19c70
r8=fffff8800331da90 r9=0000000000000001 r10=0000000000000000
r11=fffff800030a24c0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na pe nc
nt!KeEnumerateKernelStackSegments+0x28:
fffff800`03050ab4 48894508 mov qword ptr [rbp+8],rax ss:0018:fffff880`08e19c78=fffff88008e12000
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff80003025b24 to fffff80003092c40
STACK_TEXT:
fffff880`0331d6e8 fffff800`03025b24 : 00000000`00000050 fffff880`08e19c78 00000000`00000001 fffff880`0331d850 : nt!KeBugCheckEx
fffff880`0331d6f0 fffff800`03090d6e : 00000000`00000001 fffff880`08e19c78 fffff880`0331d800 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x461e2
fffff880`0331d850 fffff800`03050ab4 : fffff880`0331da98 00000001`00000001 fffff880`0331da90 fffff880`03782000 : nt!KiPageFault+0x16e
fffff880`0331d9e0 fffff800`03050a5c : 00000000`00000000 00000000`00000001 fffff880`0331db78 fffffa80`075278e0 : nt!KeEnumerateKernelStackSegments+0x28
fffff880`0331da70 fffff800`03050a00 : 00000000`00000000 00000000`000000c8 00000000`00000000 fffff800`030363c3 : nt!MmOutPageKernelStack+0x34
fffff880`0331db50 fffff800`030c72f8 : 00000000`00000000 00000000`00000080 fffffa80`0697b890 fffffa80`0697b800 : nt!KiOutSwapKernelStacks+0x11c
fffff880`0331dbc0 fffff800`0332dfee : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeSwapProcessOrStack+0x48
fffff880`0331dc00 fffff800`030845e6 : fffff880`02f65180 fffffa80`06a99040 fffff880`02f6ffc0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`0331dc40 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxStartSystemThread+0x16
STACK_COMMAND: kb
FOLLOWUP_IP:
nt!KeEnumerateKernelStackSegments+28
fffff800`03050ab4 48894508 mov qword ptr [rbp+8],rax
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: nt!KeEnumerateKernelStackSegments+28
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 4e02aaa3
FAILURE_BUCKET_ID: X64_0x50_nt!KeEnumerateKernelStackSegments+28
BUCKET_ID: X64_0x50_nt!KeEnumerateKernelStackSegments+28
Followup: MachineOwner
---------
-
Loading Dump File [D:\Kingston\BSODDmpFiles\BinaryZael\Windows_NT6_BSOD_jcgriff2\030712-17908-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 (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`0300b000 PsLoadedModuleList = 0xfffff800`03250670
Debug session time: Wed Mar 7 10:59:03.680 2012 (UTC - 6:00)
System Uptime: 0 days 0:56:05.288
Loading Kernel Symbols
...............................................................
................................................................
...................
Loading User Symbols
Loading unloaded module list
.....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 109, {a3a039d8993ef7d0, 0, ea40e4e7deafb4bb, 101}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
Followup: MachineOwner
---------
2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger that was not attached when the system was booted. Normal breakpoints,
"bp", can only be set if the debugger is attached at boot time. Hardware
breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a039d8993ef7d0, Reserved
Arg2: 0000000000000000, Reserved
Arg3: ea40e4e7deafb4bb, Failure type dependent information
Arg4: 0000000000000101, Type of corrupted region, can be
0 : A generic data region
1 : Modification of a function or .pdata
2 : A processor IDT
3 : A processor GDT
4 : Type 1 process list corruption
5 : Type 2 process list corruption
6 : Debug routine modification
7 : Critical MSR modification
Debugging Details:
------------------
BUGCHECK_STR: 0x109
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff80003087c40
STACK_TEXT:
fffff880`031b6498 00000000`00000000 : 00000000`00000109 a3a039d8`993ef7d0 00000000`00000000 ea40e4e7`deafb4bb : nt!KeBugCheckEx
STACK_COMMAND: kb
SYMBOL_NAME: ANALYSIS_INCONCLUSIVE
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Unknown_Module
IMAGE_NAME: Unknown_Image
DEBUG_FLR_IMAGE_TIMESTAMP: 0
BUCKET_ID: BAD_STACK
Followup: MachineOwner
---------
-
Loading Dump File [D:\Kingston\BSODDmpFiles\BinaryZael\Windows_NT6_BSOD_jcgriff2\030312-24819-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 (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`02e63000 PsLoadedModuleList = 0xfffff800`030a8670
Debug session time: Sat Mar 3 11:44:21.480 2012 (UTC - 6:00)
System Uptime: 0 days 13:20:02.713
Loading Kernel Symbols
...............................................................
................................................................
..................
Loading User Symbols
Loading unloaded module list
....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 1000007E, {ffffffffc0000005, fffff88013dd1cee, fffff8800389e568, fffff8800389ddc0}
Probably caused by : dxgmms1.sys ( dxgmms1!VIDMM_GLOBAL::ReferenceAllocationForPreparation+22 )
Followup: MachineOwner
---------
2: 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: fffff88013dd1cee, The address that the exception occurred at
Arg3: fffff8800389e568, Exception Record Address
Arg4: fffff8800389ddc0, Context Record Address
Debugging Details:
------------------
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.
FAULTING_IP:
dxgmms1!VIDMM_GLOBAL::ReferenceAllocationForPreparation+22
fffff880`13dd1cee 488b18 mov rbx,qword ptr [rax]
EXCEPTION_RECORD: fffff8800389e568 -- (.exr 0xfffff8800389e568)
ExceptionAddress: fffff88013dd1cee (dxgmms1!VIDMM_GLOBAL::ReferenceAllocationForPreparation+0x0000000000000022)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: ffffffffffffffff
Attempt to read from address ffffffffffffffff
CONTEXT: fffff8800389ddc0 -- (.cxr 0xfffff8800389ddc0)
rax=0f809e3e350e33b7 rbx=0000000000000000 rcx=fffffa8009b51000
rdx=fffffa8007eadd20 rsi=fffffa80080ee7d8 rdi=fffffa8009b51000
rip=fffff88013dd1cee rsp=fffff8800389e7a0 rbp=fffffa800b747790
r8=fffffa8007afc401 r9=0000000000000000 r10=0000000000000000
r11=00000000000001cd r12=00000000000000d2 r13=0000000000000001
r14=0000000000000000 r15=0000000000000001
iopl=0 nv up ei ng nz na po nc
cs=0010 ss=0000 ds=002b es=002b fs=0053 gs=002b efl=00010286
dxgmms1!VIDMM_GLOBAL::ReferenceAllocationForPreparation+0x22:
fffff880`13dd1cee 488b18 mov rbx,qword ptr [rax] ds:002b:0f809e3e`350e33b7=????????????????
Resetting default scope
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: 0
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.
EXCEPTION_PARAMETER1: 0000000000000000
EXCEPTION_PARAMETER2: ffffffffffffffff
READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80003112100
ffffffffffffffff
FOLLOWUP_IP:
dxgmms1!VIDMM_GLOBAL::ReferenceAllocationForPreparation+22
fffff880`13dd1cee 488b18 mov rbx,qword ptr [rax]
BUGCHECK_STR: 0x7E
LAST_CONTROL_TRANSFER: from fffff88013dceed3 to fffff88013dd1cee
STACK_TEXT:
fffff880`0389e7a0 fffff880`13dceed3 : 00000000`00000000 fffffa80`080ee7d8 00000000`000000d2 00000000`00000000 : dxgmms1!VIDMM_GLOBAL::ReferenceAllocationForPreparation+0x22
fffff880`0389e7d0 fffff880`13de965d : 00000000`00000000 fffff8a0`0d526c30 fffffa80`00000000 fffffa80`07afc4e0 : dxgmms1!VIDMM_GLOBAL::PrepareDmaBuffer+0x43f
fffff880`0389e9a0 fffff880`13de9398 : fffff800`043a3080 fffff880`13de8d00 fffffa80`00000000 fffffa80`00000000 : dxgmms1!VidSchiSubmitRenderCommand+0x241
fffff880`0389eb90 fffff880`13de8e96 : 00000000`00000000 fffffa80`076b7410 00000000`00000080 fffffa80`09abd010 : dxgmms1!VidSchiSubmitQueueCommand+0x50
fffff880`0389ebc0 fffff800`0317afee : 00000000`04ca85d7 fffffa80`09b508c0 fffffa80`0697b890 fffffa80`09b508c0 : dxgmms1!VidSchiWorkerThread+0xd6
fffff880`0389ec00 fffff800`02ed15e6 : fffff800`03055e80 fffffa80`09b508c0 fffff800`03063cc0 fffff880`01228384 : nt!PspSystemThreadStartup+0x5a
fffff880`0389ec40 00000000`00000000 : fffff880`0389f000 fffff880`03899000 fffff880`0389e540 00000000`00000000 : nt!KxStartSystemThread+0x16
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: dxgmms1!VIDMM_GLOBAL::ReferenceAllocationForPreparation+22
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: dxgmms1
IMAGE_NAME: dxgmms1.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4ce799c1
STACK_COMMAND: .cxr 0xfffff8800389ddc0 ; kb
FAILURE_BUCKET_ID: X64_0x7E_dxgmms1!VIDMM_GLOBAL::ReferenceAllocationForPreparation+22
BUCKET_ID: X64_0x7E_dxgmms1!VIDMM_GLOBAL::ReferenceAllocationForPreparation+22
Followup: MachineOwner
---------