Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\K\Desktop\Windows_NT6_BSOD_jcgriff2\060611-19250-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;srv*e:\symbols
*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7600 MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.x86fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0x82803000 PsLoadedModuleList = 0x8294b810
Debug session time: Mon Jun 6 23:48:16.072 2011 (GMT-4)
System Uptime: 0 days 0:08:20.774
Loading Kernel Symbols
...............................................................
................................................................
...............
Loading User Symbols
Loading unloaded module list
....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 1000007E, {c0000005, 8d2ddebd, 8a82db64, 8a82d740}
Probably caused by : dxgmms1.sys ( dxgmms1!VIDMM_DEVICE::RemoveCommitment+27 )
Followup: MachineOwner
---------
1: 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: c0000005, The exception code that was not handled
Arg2: 8d2ddebd, The address that the exception occurred at
Arg3: 8a82db64, Exception Record Address
Arg4: 8a82d740, 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_DEVICE::RemoveCommitment+27
8d2ddebd ff0e dec dword ptr [esi]
EXCEPTION_RECORD: 8a82db64 -- (.exr 0xffffffff8a82db64)
ExceptionAddress: 8d2ddebd (dxgmms1!VIDMM_DEVICE::RemoveCommitment+0x00000027)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000001
Parameter[1]: 01d85b88
Attempt to write to address 01d85b88
CONTEXT: 8a82d740 -- (.cxr 0xffffffff8a82d740)
eax=867b0508 ebx=99504678 ecx=9cad0ee0 edx=8a82dcf8 esi=01d85b88 edi=9cad0c98
eip=8d2ddebd esp=8a82dc2c ebp=8a82dc3c iopl=0 nv up ei pl nz na pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010207
dxgmms1!VIDMM_DEVICE::RemoveCommitment+0x27:
8d2ddebd ff0e dec dword ptr [esi] ds:0023:01d85b88=????????
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: 00000001
EXCEPTION_PARAMETER2: 01d85b88
WRITE_ADDRESS: GetPointerFromAddress: unable to read from 8296b718
Unable to read MiSystemVaType memory at 8294b160
01d85b88
FOLLOWUP_IP:
dxgmms1!VIDMM_DEVICE::RemoveCommitment+27
8d2ddebd ff0e dec dword ptr [esi]
BUGCHECK_STR: 0x7E
LAST_CONTROL_TRANSFER: from 8d2d261e to 8d2ddebd
STACK_TEXT:
8a82dc3c 8d2d261e 9cad0ee0 867b0508 9cad0c98 dxgmms1!VIDMM_DEVICE::RemoveCommitment+0x27
8a82dc54 8d2d94c4 867b0508 00000000 00000000 dxgmms1!VIDMM_GLOBAL::NotifyAllocationEviction+0x1e
8a82dcc4 8d2d9e66 8a82dce0 00000000 8a82dcf8 dxgmms1!VIDMM_GLOBAL::ProcessDeferredCommand+0x406
8a82dcf0 8d2db4c8 00000000 8a82dd18 8d2ef2cd dxgmms1!VIDMM_GLOBAL::ProcessTerminationCommand+0x40
8a82dcfc 8d2ef2cd 86cd9898 86c4a008 86c4a008 dxgmms1!VidMmiProcessTerminationCommand+0x10
8a82dd18 8d2f027d 849ce560 8683dbe0 8a82dd3c dxgmms1!VidSchiSubmitDeviceCommand+0x33
8a82dd28 8d2f04cc 86c4a008 8283f3f1 862f3330 dxgmms1!VidSchiSubmitQueueCommand+0xaf
8a82dd3c 8d2f0573 862f3330 00000000 8633e510 dxgmms1!VidSchiRun_PriorityTable+0x24
8a82dd50 82a1166d 862f3330 aeadfd2c 00000000 dxgmms1!VidSchiWorkerThread+0x7f
8a82dd90 828c30d9 8d2f04f4 862f3330 00000000 nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: dxgmms1!VIDMM_DEVICE::RemoveCommitment+27
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: dxgmms1
IMAGE_NAME: dxgmms1.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc265
STACK_COMMAND: .cxr 0xffffffff8a82d740 ; kb
FAILURE_BUCKET_ID: 0x7E_dxgmms1!VIDMM_DEVICE::RemoveCommitment+27
BUCKET_ID: 0x7E_dxgmms1!VIDMM_DEVICE::RemoveCommitment+27
Followup: MachineOwner
---------
1: 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: c0000005, The exception code that was not handled
Arg2: 8d2ddebd, The address that the exception occurred at
Arg3: 8a82db64, Exception Record Address
Arg4: 8a82d740, 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_DEVICE::RemoveCommitment+27
8d2ddebd ff0e dec dword ptr [esi]
EXCEPTION_RECORD: 8a82db64 -- (.exr 0xffffffff8a82db64)
ExceptionAddress: 8d2ddebd (dxgmms1!VIDMM_DEVICE::RemoveCommitment+0x00000027)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000001
Parameter[1]: 01d85b88
Attempt to write to address 01d85b88
CONTEXT: 8a82d740 -- (.cxr 0xffffffff8a82d740)
eax=867b0508 ebx=99504678 ecx=9cad0ee0 edx=8a82dcf8 esi=01d85b88 edi=9cad0c98
eip=8d2ddebd esp=8a82dc2c ebp=8a82dc3c iopl=0 nv up ei pl nz na pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010207
dxgmms1!VIDMM_DEVICE::RemoveCommitment+0x27:
8d2ddebd ff0e dec dword ptr [esi] ds:0023:01d85b88=????????
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: 00000001
EXCEPTION_PARAMETER2: 01d85b88
WRITE_ADDRESS: GetPointerFromAddress: unable to read from 8296b718
Unable to read MiSystemVaType memory at 8294b160
01d85b88
FOLLOWUP_IP:
dxgmms1!VIDMM_DEVICE::RemoveCommitment+27
8d2ddebd ff0e dec dword ptr [esi]
BUGCHECK_STR: 0x7E
LAST_CONTROL_TRANSFER: from 8d2d261e to 8d2ddebd
STACK_TEXT:
8a82dc3c 8d2d261e 9cad0ee0 867b0508 9cad0c98 dxgmms1!VIDMM_DEVICE::RemoveCommitment+0x27
8a82dc54 8d2d94c4 867b0508 00000000 00000000 dxgmms1!VIDMM_GLOBAL::NotifyAllocationEviction+0x1e
8a82dcc4 8d2d9e66 8a82dce0 00000000 8a82dcf8 dxgmms1!VIDMM_GLOBAL::ProcessDeferredCommand+0x406
8a82dcf0 8d2db4c8 00000000 8a82dd18 8d2ef2cd dxgmms1!VIDMM_GLOBAL::ProcessTerminationCommand+0x40
8a82dcfc 8d2ef2cd 86cd9898 86c4a008 86c4a008 dxgmms1!VidMmiProcessTerminationCommand+0x10
8a82dd18 8d2f027d 849ce560 8683dbe0 8a82dd3c dxgmms1!VidSchiSubmitDeviceCommand+0x33
8a82dd28 8d2f04cc 86c4a008 8283f3f1 862f3330 dxgmms1!VidSchiSubmitQueueCommand+0xaf
8a82dd3c 8d2f0573 862f3330 00000000 8633e510 dxgmms1!VidSchiRun_PriorityTable+0x24
8a82dd50 82a1166d 862f3330 aeadfd2c 00000000 dxgmms1!VidSchiWorkerThread+0x7f
8a82dd90 828c30d9 8d2f04f4 862f3330 00000000 nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: dxgmms1!VIDMM_DEVICE::RemoveCommitment+27
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: dxgmms1
IMAGE_NAME: dxgmms1.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc265
STACK_COMMAND: .cxr 0xffffffff8a82d740 ; kb
FAILURE_BUCKET_ID: 0x7E_dxgmms1!VIDMM_DEVICE::RemoveCommitment+27
BUCKET_ID: 0x7E_dxgmms1!VIDMM_DEVICE::RemoveCommitment+27
Followup: MachineOwner
---------