WIN7 64 BIT BSOD debugging help

mrbudgie said:

Lo All

any one here any good at debugging as lately been getting some BSOD's but not sure what they are from even using windows debugger. i have zipped up and attached a mini dump

so any help would be great
thanks all

Ian

Hi and welcome

As usual this 64bit dmp was probably cased by the video driver.

I would update the video driver
and just for giggles I would run a system file check to verify and repair your system files
type cmd in search>right click and run as admin>sfc /scannow

If you are overclocking STOP
if you have a raid update its driver

Hope this helps

Kenn J+



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


Loading Dump File [C:\Users\K\Desktop\112909-17721-02.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*d:\symbols*Symbol information
Executable search path is:
Windows 7 Kernel Version 7600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff800`02e05000 PsLoadedModuleList = 0xfffff800`03042e50
Debug session time: Sun Nov 29 13:19:39.406 2009 (GMT-5)
System Uptime: 0 days 1:18:26.326
Loading Kernel Symbols
...............................................................
................................................................
............................
Loading User Symbols
Loading unloaded module list
.....................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {fffffa3205acfc98, 2, 0, fffff80002e7af9f}

*** 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+1d8 )

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

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

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: fffffa3205acfc98, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80002e7af9f, address which referenced memory

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


READ_ADDRESS: GetPointerFromAddress: unable to read from fffff800030ad0e0
fffffa3205acfc98

CURRENT_IRQL: 2

FAULTING_IP:
nt!KeSetEvent+10f
fffff800`02e7af9f 488b09 mov rcx,qword ptr [rcx]

CUSTOMER_CRASH_COUNT: 2

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: csrss.exe

TRAP_FRAME: fffff88009dc8ce0 -- (.trap 0xfffff88009dc8ce0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffa8005a41580 rbx=0000000000000000 rcx=fffffa3205acfc98
rdx=fffffa3205acfc98 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002e7af9f rsp=fffff88009dc8e70 rbp=0000000000000000
r8=0000000000000000 r9=0000000000000000 r10=fffffa8004e42580
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po cy
nt!KeSetEvent+0x10f:
fffff800`02e7af9f 488b09 mov rcx,qword ptr [rcx] ds:1010:fffffa32`05acfc98=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80002e76469 to fffff80002e76f00

STACK_TEXT:
fffff880`09dc8b98 fffff800`02e76469 : 00000000`0000000a fffffa32`05acfc98 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`09dc8ba0 fffff800`02e750e0 : 00000000`00000000 fffffa80`05a41578 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`09dc8ce0 fffff800`02e7af9f : 00000000`0000000f 00000000`0000000f fffffa80`04e42501 fffffa80`04e42580 : nt!KiPageFault+0x260
fffff880`09dc8e70 fffff880`04f6d9a0 : fffffa80`00000000 fffffa80`00000000 fffffa80`03b80900 fffffa80`05a41010 : nt!KeSetEvent+0x10f
fffff880`09dc8ee0 fffff880`04f706fd : 00000000`00000001 fffffa80`04e42768 fffff880`09dc9140 00000000`00000000 : dxgmms1!VidSchiSubmitCommandPacketToQueue+0x1d8
fffff880`09dc8f50 fffff880`04eaf520 : 00000000`00000000 00000000`00000200 fffff880`09dc97b0 00000000`00000000 : dxgmms1!VidSchSubmitCommand+0x3ad
fffff880`09dc8fb0 00000000`00000000 : 00000000`00000200 fffff880`09dc97b0 00000000`00000000 00000000`00000001 : dxgkrnl+0x70520


STACK_COMMAND: kb

FOLLOWUP_IP:
dxgmms1!VidSchiSubmitCommandPacketToQueue+1d8
fffff880`04f6d9a0 4c8d5c2440 lea r11,[rsp+40h]

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: dxgmms1!VidSchiSubmitCommandPacketToQueue+1d8

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: dxgmms1

IMAGE_NAME: dxgmms1.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc578

FAILURE_BUCKET_ID: X64_0xA_dxgmms1!VidSchiSubmitCommandPacketToQueue+1d8

BUCKET_ID: X64_0xA_dxgmms1!VidSchiSubmitCommandPacketToQueue+1d8

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