Need help disecting this bsod report

[Geowil]

ran the windows debugger and would like some help decrypting what it means.

Use !analyze -v to get detailed debugging information.

BugCheck 100000EA, {c4434488, 0, 0, 0}

Unable to load image \SystemRoot\system32\DRIVERS\atikmdag.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for atikmdag.sys
*** ERROR: Module load completed but symbols could not be loaded for atikmdag.sys
Probably caused by : dxgkrnl.sys ( dxgkrnl!TdrTimedOperationBugcheckOnTimeout+2c )

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

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

THREAD_STUCK_IN_DEVICE_DRIVER_M (100000ea)
The device driver is spinning in an infinite loop, most likely waiting for
hardware to become idle. This usually indicates problem with the hardware
itself or with the device driver programming the hardware incorrectly.
If the kernel debugger is connected and running when watchdog detects a
timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()
and detailed message including bugcheck arguments will be printed to the
debugger. This way we can identify an offending thread, set breakpoints in it,
and hit go to return to the spinning code to debug it further. Because
KeBugCheckEx() is not called the .bugcheck directive will not return bugcheck
information in this case. The arguments are already printed out to the kernel
debugger. You can also retrieve them from a global variable via
"dd watchdog!g_WdBugCheckData l5" (use dq on NT64).
On MP machines it is possible to hit a timeout when the spinning thread is
interrupted by hardware interrupt and ISR or DPC routine is running at the time
of the bugcheck (this is because the timeout's work item can be delivered and
handled on the second CPU and the same time). If this is the case you will have
to look deeper at the offending thread's stack (e.g. using dds) to determine
spinning code which caused the timeout to occur.
Arguments:
Arg1: c4434488, Pointer to a stuck thread object. Do .thread then kb on it to find
the hung location.
Arg2: 00000000, Pointer to a DEFERRED_WATCHDOG object.
Arg3: 00000000, Pointer to offending driver name.
Arg4: 00000000, Number of times "intercepted" bugcheck 0xEA was hit (see notes).

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


FAULTING_THREAD: c4434488

DEFAULT_BUCKET_ID: GRAPHICS_DRIVER_FAULT

CUSTOMER_CRASH_COUNT: 1

BUGCHECK_STR: 0xEA

PROCESS_NAME: System

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from cd281b60 to e1ccf0e3

STACK_TEXT:
d897d9ac cd281b60 000000ea c4434488 00000000 nt!KeBugCheckEx+0x1e
d897d9f0 cd2796cf d897da3c 00000000 cd27c70c dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x2c
d897da18 cce33118 d897da3c 00000000 00000000 dxgkrnl!TdrTimedOperationDelay+0xc9
WARNING: Stack unwind information not available. Following frames may be wrong.
d897da68 cce30ae8 ccf396aa d897dafc 00000bb8 atikmdag+0x24118
d897da84 ccf42c53 c4467000 d897da9c c613c3b0 atikmdag+0x21ae8
d897dadc ccf3997c c613c298 ccf396aa d897dafc atikmdag+0x133c53
d897db0c ccf4a032 c613c298 00000000 00000300 atikmdag+0x12a97c
d897db3c ccf4b110 00000000 c613c298 c613c3b0 atikmdag+0x13b032
d897db54 ccf42152 20000000 00000000 c7adc010 atikmdag+0x13c110
d897db70 ccf372f3 c613c298 cce131df c613c298 atikmdag+0x133152
d897db8c cce1dc8a 00000000 c0000001 c4863c48 atikmdag+0x1282f3
d897dbbc cce1ea7d c6103260 c6103420 00000000 atikmdag+0xec8a
d897dbd0 cd2e100d 00000000 c3dae008 c6103260 atikmdag+0xfa7d
d897dbf0 cd2e2097 c61128b8 c3dae008 00000000 dxgkrnl!DXGADAPTER:diResetFromTimeout+0x38
d897dc18 cd2e7ae7 c3dae008 c3dae008 00000081 dxgkrnl!DXGADAPTER:repareToReset+0xc1
d897dc30 cd284ed1 00000000 00000002 c61128b8 dxgkrnl!TdrIsRecoveryRequired+0x11f
d897dc98 cd295ef4 c61128b8 00008bd7 00000000 dxgkrnl!VidSchiReportHwHang+0x2f5
d897dcc4 cd272b06 c61128b8 c2b81578 c76777d8 dxgkrnl!VidSchiCheckHwProgress+0x69
d897dd54 cd295f9b 00000003 e1c53645 c61128b8 dxgkrnl!VidSchiScheduleCommandToRun+0x167
d897dd68 cd2d3053 c61128b8 00000000 c4434488 dxgkrnl!VidSchiRun_PriorityTable+0xf
d897dd7c e1dd7b18 c61128b8 da4d1923 00000000 dxgkrnl!VidSchiWorkerThread+0x62
d897ddc0 e1c30a2e cd2d2ff1 c61128b8 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


STACK_COMMAND: .thread 0xffffffffc4434488 ; kb

FOLLOWUP_IP:
dxgkrnl!TdrTimedOperationBugcheckOnTimeout+2c
cd281b60 cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: dxgkrnl!TdrTimedOperationBugcheckOnTimeout+2c

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: dxgkrnl

IMAGE_NAME: dxgkrnl.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4893b1df

FAILURE_BUCKET_ID: 0xEA_IMAGE_dxgkrnl.sys

BUCKET_ID: 0xEA_IMAGE_dxgkrnl.sys

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

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

THREAD_STUCK_IN_DEVICE_DRIVER_M (100000ea)
The device driver is spinning in an infinite loop, most likely waiting for
hardware to become idle. This usually indicates problem with the hardware
itself or with the device driver programming the hardware incorrectly.
If the kernel debugger is connected and running when watchdog detects a
timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()
and detailed message including bugcheck arguments will be printed to the
debugger. This way we can identify an offending thread, set breakpoints in it,
and hit go to return to the spinning code to debug it further. Because
KeBugCheckEx() is not called the .bugcheck directive will not return bugcheck
information in this case. The arguments are already printed out to the kernel
debugger. You can also retrieve them from a global variable via
"dd watchdog!g_WdBugCheckData l5" (use dq on NT64).
On MP machines it is possible to hit a timeout when the spinning thread is
interrupted by hardware interrupt and ISR or DPC routine is running at the time
of the bugcheck (this is because the timeout's work item can be delivered and
handled on the second CPU and the same time). If this is the case you will have
to look deeper at the offending thread's stack (e.g. using dds) to determine
spinning code which caused the timeout to occur.
Arguments:
Arg1: c4434488, Pointer to a stuck thread object. Do .thread then kb on it to find
the hung location.
Arg2: 00000000, Pointer to a DEFERRED_WATCHDOG object.
Arg3: 00000000, Pointer to offending driver name.
Arg4: 00000000, Number of times "intercepted" bugcheck 0xEA was hit (see notes).

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


FAULTING_THREAD: c4434488

DEFAULT_BUCKET_ID: GRAPHICS_DRIVER_FAULT

CUSTOMER_CRASH_COUNT: 1

BUGCHECK_STR: 0xEA

PROCESS_NAME: System

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from cd281b60 to e1ccf0e3

STACK_TEXT:
d897d9ac cd281b60 000000ea c4434488 00000000 nt!KeBugCheckEx+0x1e
d897d9f0 cd2796cf d897da3c 00000000 cd27c70c dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x2c
d897da18 cce33118 d897da3c 00000000 00000000 dxgkrnl!TdrTimedOperationDelay+0xc9
WARNING: Stack unwind information not available. Following frames may be wrong.
d897da68 cce30ae8 ccf396aa d897dafc 00000bb8 atikmdag+0x24118
d897da84 ccf42c53 c4467000 d897da9c c613c3b0 atikmdag+0x21ae8
d897dadc ccf3997c c613c298 ccf396aa d897dafc atikmdag+0x133c53
d897db0c ccf4a032 c613c298 00000000 00000300 atikmdag+0x12a97c
d897db3c ccf4b110 00000000 c613c298 c613c3b0 atikmdag+0x13b032
d897db54 ccf42152 20000000 00000000 c7adc010 atikmdag+0x13c110
d897db70 ccf372f3 c613c298 cce131df c613c298 atikmdag+0x133152
d897db8c cce1dc8a 00000000 c0000001 c4863c48 atikmdag+0x1282f3
d897dbbc cce1ea7d c6103260 c6103420 00000000 atikmdag+0xec8a
d897dbd0 cd2e100d 00000000 c3dae008 c6103260 atikmdag+0xfa7d
d897dbf0 cd2e2097 c61128b8 c3dae008 00000000 dxgkrnl!DXGADAPTER:diResetFromTimeout+0x38
d897dc18 cd2e7ae7 c3dae008 c3dae008 00000081 dxgkrnl!DXGADAPTER:repareToReset+0xc1
d897dc30 cd284ed1 00000000 00000002 c61128b8 dxgkrnl!TdrIsRecoveryRequired+0x11f
d897dc98 cd295ef4 c61128b8 00008bd7 00000000 dxgkrnl!VidSchiReportHwHang+0x2f5
d897dcc4 cd272b06 c61128b8 c2b81578 c76777d8 dxgkrnl!VidSchiCheckHwProgress+0x69
d897dd54 cd295f9b 00000003 e1c53645 c61128b8 dxgkrnl!VidSchiScheduleCommandToRun+0x167
d897dd68 cd2d3053 c61128b8 00000000 c4434488 dxgkrnl!VidSchiRun_PriorityTable+0xf
d897dd7c e1dd7b18 c61128b8 da4d1923 00000000 dxgkrnl!VidSchiWorkerThread+0x62
d897ddc0 e1c30a2e cd2d2ff1 c61128b8 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


STACK_COMMAND: .thread 0xffffffffc4434488 ; kb

FOLLOWUP_IP:
dxgkrnl!TdrTimedOperationBugcheckOnTimeout+2c
cd281b60 cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: dxgkrnl!TdrTimedOperationBugcheckOnTimeout+2c

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: dxgkrnl

IMAGE_NAME: dxgkrnl.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4893b1df

FAILURE_BUCKET_ID: 0xEA_IMAGE_dxgkrnl.sys

BUCKET_ID: 0xEA_IMAGE_dxgkrnl.sys

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

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

THREAD_STUCK_IN_DEVICE_DRIVER_M (100000ea)
The device driver is spinning in an infinite loop, most likely waiting for
hardware to become idle. This usually indicates problem with the hardware
itself or with the device driver programming the hardware incorrectly.
If the kernel debugger is connected and running when watchdog detects a
timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()
and detailed message including bugcheck arguments will be printed to the
debugger. This way we can identify an offending thread, set breakpoints in it,
and hit go to return to the spinning code to debug it further. Because
KeBugCheckEx() is not called the .bugcheck directive will not return bugcheck
information in this case. The arguments are already printed out to the kernel
debugger. You can also retrieve them from a global variable via
"dd watchdog!g_WdBugCheckData l5" (use dq on NT64).
On MP machines it is possible to hit a timeout when the spinning thread is
interrupted by hardware interrupt and ISR or DPC routine is running at the time
of the bugcheck (this is because the timeout's work item can be delivered and
handled on the second CPU and the same time). If this is the case you will have
to look deeper at the offending thread's stack (e.g. using dds) to determine
spinning code which caused the timeout to occur.
Arguments:
Arg1: c4434488, Pointer to a stuck thread object. Do .thread then kb on it to find
the hung location.
Arg2: 00000000, Pointer to a DEFERRED_WATCHDOG object.
Arg3: 00000000, Pointer to offending driver name.
Arg4: 00000000, Number of times "intercepted" bugcheck 0xEA was hit (see notes).

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


FAULTING_THREAD: c4434488

DEFAULT_BUCKET_ID: GRAPHICS_DRIVER_FAULT

CUSTOMER_CRASH_COUNT: 1

BUGCHECK_STR: 0xEA

PROCESS_NAME: System

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from cd281b60 to e1ccf0e3

STACK_TEXT:
d897d9ac cd281b60 000000ea c4434488 00000000 nt!KeBugCheckEx+0x1e
d897d9f0 cd2796cf d897da3c 00000000 cd27c70c dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x2c
d897da18 cce33118 d897da3c 00000000 00000000 dxgkrnl!TdrTimedOperationDelay+0xc9
WARNING: Stack unwind information not available. Following frames may be wrong.
d897da68 cce30ae8 ccf396aa d897dafc 00000bb8 atikmdag+0x24118
d897da84 ccf42c53 c4467000 d897da9c c613c3b0 atikmdag+0x21ae8
d897dadc ccf3997c c613c298 ccf396aa d897dafc atikmdag+0x133c53
d897db0c ccf4a032 c613c298 00000000 00000300 atikmdag+0x12a97c
d897db3c ccf4b110 00000000 c613c298 c613c3b0 atikmdag+0x13b032
d897db54 ccf42152 20000000 00000000 c7adc010 atikmdag+0x13c110
d897db70 ccf372f3 c613c298 cce131df c613c298 atikmdag+0x133152
d897db8c cce1dc8a 00000000 c0000001 c4863c48 atikmdag+0x1282f3
d897dbbc cce1ea7d c6103260 c6103420 00000000 atikmdag+0xec8a
d897dbd0 cd2e100d 00000000 c3dae008 c6103260 atikmdag+0xfa7d
d897dbf0 cd2e2097 c61128b8 c3dae008 00000000 dxgkrnl!DXGADAPTER:diResetFromTimeout+0x38
d897dc18 cd2e7ae7 c3dae008 c3dae008 00000081 dxgkrnl!DXGADAPTER:repareToReset+0xc1
d897dc30 cd284ed1 00000000 00000002 c61128b8 dxgkrnl!TdrIsRecoveryRequired+0x11f
d897dc98 cd295ef4 c61128b8 00008bd7 00000000 dxgkrnl!VidSchiReportHwHang+0x2f5
d897dcc4 cd272b06 c61128b8 c2b81578 c76777d8 dxgkrnl!VidSchiCheckHwProgress+0x69
d897dd54 cd295f9b 00000003 e1c53645 c61128b8 dxgkrnl!VidSchiScheduleCommandToRun+0x167
d897dd68 cd2d3053 c61128b8 00000000 c4434488 dxgkrnl!VidSchiRun_PriorityTable+0xf
d897dd7c e1dd7b18 c61128b8 da4d1923 00000000 dxgkrnl!VidSchiWorkerThread+0x62
d897ddc0 e1c30a2e cd2d2ff1 c61128b8 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16


STACK_COMMAND: .thread 0xffffffffc4434488 ; kb

FOLLOWUP_IP:
dxgkrnl!TdrTimedOperationBugcheckOnTimeout+2c
cd281b60 cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: dxgkrnl!TdrTimedOperationBugcheckOnTimeout+2c

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: dxgkrnl

IMAGE_NAME: dxgkrnl.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4893b1df

FAILURE_BUCKET_ID: 0xEA_IMAGE_dxgkrnl.sys

BUCKET_ID: 0xEA_IMAGE_dxgkrnl.sys

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

I get this when trying to run graphics intensive games like COD4 and Crysis, but not on games like COD1 or starcraft.

 

[shortstuff_mt]

It looks like a problem with your graphics driver. What are your system specs? Have you recently upgraded the GPU?

 

[aevm]

Did you have an nVidia card before? Sometimes switching from nVidia to ATI or from ATI to nVidia leaves drivers in a messy state.

Are you using the latest drivers?

 

[Geowil]

this is from a brand new computer (so no switching occured) but some nvidia drivers were installed with 3dmark for some reason.

gfx info:

Radeon HD 4870 x2
catalyst and display driver version: 9.1

sys specs:
mb: Asus maximus II
cpu: Q6600 @ stock settings
ram: 4 gb (4 x 1 gb) ocz platinum pc2-8500, timings default (5-5-5-15) voltage 2.19
sound blaster X-Fi extreme gamer fatal1ty pro edition
OS: Vista ult. 32-bit

Apevia BEast 680w psu (this is getting replaced by an Ultra X3 800w psu this evening)

 

[shortstuff_mt]

I would use some software like Driver Cleaner to completely uninstall all traces of any drivers and install a fresh version of the Catalyst 9.1 drivers.

 

[aevm]

Try this:
http://downloads.guru3d.com/download.php?det=1655
That is, uninstall both sets of drivers, run Driver Sweeper, install Catalyst again.

Edit: LOL, shortstuff_mt types faster than me

 

[Geowil]

hmm, should I use the drivers from the cd or from ati's site?

on the site they are labeled as Radeon 4800 Series (I noticed that the 4580 x2, i think it was, has its own driver).

 

[aevm]

The ones on ATI's site should be newer. I'd try them first.

 

[shortstuff_mt]

The ones on ATI's site should be newer. I'd try them first.

+1

I very rarely even bother taking the CD's out of the box. I always just download the most current drivers.

 

[Ares_]

My Radeon 4870 has given me that message before; however, it gave it to me because i left the fan at 20% for an essay and forgot to bring it back up when i fired up the games.

 

[Geowil]

ok, Im still getting bsoded x.x

one of my firends suggested that maybe when the psu went it damaged the card. should that be the next step, or is there something else to try first?

 

[Geowil]

ok I got the issue resolved.

Not sure why, it may be that the card is still damaged in some way, but the Catalyst AI was causing my bsod's.

Steam support suggested to turn it off to fix a vertex memory pool lock issue with their source games and it also fixed my issues with cod4 and crysis

I am still going to replace the card, as I said, i dont think a driver feature that works for others should cause a correctly functioning card to bsod.

 

[aevm]

I agree 100%, good move. Let us know how the new card does.

 

[Geowil]

alright I just replaced the card and loaded up hl2. No vertex lock error but there was still white hollow boxes with x's int them where ever there was a sprite, did not test in crysis or cod4 as i doubt it would get any real performance gains considering how well it runs on max settings in those games with it off.

looks like there are still some bugs with CAI.