BSOD - dxgmms1.sys (3 times)

Welcome to SF!

Yep, it does look as if your video card is the issue. Try installing some older drivers, and play around until you find some that work for you.

Code:

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


Loading Dump File [C:\Users\Jonathan\AppData\Local\Temp\Temp14_minidump.zip\042110-25630-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 (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.x86fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0x8281e000 PsLoadedModuleList = 0x82966810
Debug session time: Wed Apr 21 03:06:56.528 2010 (GMT-4)
System Uptime: 0 days 0:28:24.401
Loading Kernel Symbols
...............................................................
................................................................
...........
Loading User Symbols
Loading unloaded module list
.........
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1000008E, {c0000005, 90ba22c2, 96c3f6f0, 0}

Unable to load image \SystemRoot\System32\drivers\dxgkrnl.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for dxgkrnl.sys
*** ERROR: Module load completed but symbols could not be loaded for dxgkrnl.sys
Probably caused by : dxgmms1.sys ( dxgmms1!VidSchiSubmitCommandPacketToQueue+26 )

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

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

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
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: 90ba22c2, The address that the exception occurred at
Arg3: 96c3f6f0, Trap Frame
Arg4: 00000000

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!VidSchiSubmitCommandPacketToQueue+26
90ba22c2 3b432c          cmp     eax,dword ptr [ebx+2Ch]

TRAP_FRAME:  96c3f6f0 -- (.trap 0xffffffff96c3f6f0)
ErrCode = 00000000
eax=86f63d48 ebx=00000000 ecx=86f3f898 edx=00000000 esi=86f63d48 edi=8519b00c
eip=90ba22c2 esp=96c3f764 ebp=96c3f77c iopl=0         nv up ei ng nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010282
dxgmms1!VidSchiSubmitCommandPacketToQueue+0x26:
90ba22c2 3b432c          cmp     eax,dword ptr [ebx+2Ch] ds:0023:0000002c=????????
Resetting default scope

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x8E

PROCESS_NAME:  dwm.exe

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from 90b9d581 to 90ba22c2

STACK_TEXT:  
96c3f77c 90b9d581 8519b008 00000000 96f523a0 dxgmms1!VidSchiSubmitCommandPacketToQueue+0x26
96c3f7a0 8f90ad10 86f3f700 96c3f9f8 00003000 dxgmms1!VidSchSubmitCommand+0x38b
WARNING: Stack unwind information not available. Following frames may be wrong.
96c3fb44 8f90ca2b 8728b778 96c3fcb8 19537cdd dxgkrnl+0x1cd10
96c3fd28 8286142a 01b4f1f0 01b4f340 776c64f4 dxgkrnl+0x1ea2b
96c3fd28 776c64f4 01b4f1f0 01b4f340 776c64f4 nt!KiFastCallEntry+0x12a
01b4f340 00000000 00000000 00000000 00000000 0x776c64f4


STACK_COMMAND:  kb

FOLLOWUP_IP: 
dxgmms1!VidSchiSubmitCommandPacketToQueue+26
90ba22c2 3b432c          cmp     eax,dword ptr [ebx+2Ch]

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  dxgmms1!VidSchiSubmitCommandPacketToQueue+26

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: dxgmms1

IMAGE_NAME:  dxgmms1.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bc265

FAILURE_BUCKET_ID:  0x8E_dxgmms1!VidSchiSubmitCommandPacketToQueue+26

BUCKET_ID:  0x8E_dxgmms1!VidSchiSubmitCommandPacketToQueue+26

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