Windows 7 Random BSOD's - Please Help!

[dieniewienie143]

I've been experiencing multiple BSOD's lately and cant pinpoint the exact cause of the issue. Would someone please take a look and let me know whats happening here? I would greatly appreciate it.


Link Removed

 

[Trouble]

Update the Driver for your Video Card (ATI Radeon HD 4870 X2) from here Link Removed

BugCheck 100000EA, {fffffa80087a7a00, 0, 0, 0}
Unable to load image \SystemRoot\system32\DRIVERS\  [B]atikmdag.sys[/B]  , Win32 error 0n2  
*** WARNING: Unable to verify timestamp for [U][B]atikmdag.sys[/B][/U]
*** ERROR: Module load completed but symbols could not be loaded for [U][B]atikmdag.sys[/B][/U]
*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
Probably caused by : dxgkrnl.sys ( dxgkrnl!TdrTimedOperationBugcheckOnTimeout+37 )
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: fffffa80087a7a00, Pointer to a stuck thread object.  Do .thread then kb on it to find
    the hung location.
Arg2: 0000000000000000, Pointer to a DEFERRED_WATCHDOG object.
Arg3: 0000000000000000, Pointer to offending driver name.
Arg4: 0000000000000000, Number of times "intercepted" bugcheck 0xEA was hit (see notes).
FAULTING_THREAD:  fffffa80087a7a00
DEFAULT_BUCKET_ID:  GRAPHICS_DRIVER_FAULT
CUSTOMER_CRASH_COUNT:  1
BUGCHECK_STR:  0xEA
PROCESS_NAME:  System
CURRENT_IRQL:  0
LAST_CONTROL_TRANSFER:  from fffff88006234f63 to fffff80002cdb1c0
STACK_TEXT:  
fffff880`07d0a608 fffff880`06234f63 : 00000000`000000ea fffffa80`087a7a00 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
fffff880`07d0a610 fffff880`06235112 : fffff880`07d0a6e0 fffff880`06a24a2b fffff880`07d0a6e0 00000000`00003f00 : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x37
fffff880`07d0a680 fffff880`0683bf72 : 00000000`00000000 fffff880`06a24a10 fffff880`07d0a800 00000000`01c9c380 : dxgkrnl!TdrTimedOperationDelay+0xbe
fffff880`07d0a6c0 00000000`00000000 : fffff880`06a24a10 fffff880`07d0a800 00000000`01c9c380 fffff800`02ce0028 : [U][B]atikmdag[/B][/U]+0x2bf72
STACK_COMMAND:  .thread 0xfffffa80087a7a00 ; kb
FOLLOWUP_IP: 
dxgkrnl!TdrTimedOperationBugcheckOnTimeout+37
fffff880`06234f63 cc              int     3
SYMBOL_STACK_INDEX:  1
SYMBOL_NAME:  dxgkrnl!TdrTimedOperationBugcheckOnTimeout+37
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: dxgkrnl
IMAGE_NAME:  dxgkrnl.sys
DEBUG_FLR_IMAGE_TIMESTAMP:  4ce799fa
FAILURE_BUCKET_ID:  X64_0xEA_IMAGE_dxgkrnl.sys
BUCKET_ID:  X64_0xEA_IMAGE_dxgkrnl.sys

 

[dieniewienie143]

Update the Driver for your Video Card (ATI Radeon HD 4870 X2) from here Link Removed

BugCheck 100000EA, {fffffa80087a7a00, 0, 0, 0}
Unable to load image \SystemRoot\system32\DRIVERS\  [B]atikmdag.sys[/B]  , Win32 error 0n2  
*** WARNING: Unable to verify timestamp for [U][B]atikmdag.sys[/B][/U]
*** ERROR: Module load completed but symbols could not be loaded for [U][B]atikmdag.sys[/B][/U]
*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
Probably caused by : dxgkrnl.sys ( dxgkrnl!TdrTimedOperationBugcheckOnTimeout+37 )
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: fffffa80087a7a00, Pointer to a stuck thread object.  Do .thread then kb on it to find
    the hung location.
Arg2: 0000000000000000, Pointer to a DEFERRED_WATCHDOG object.
Arg3: 0000000000000000, Pointer to offending driver name.
Arg4: 0000000000000000, Number of times "intercepted" bugcheck 0xEA was hit (see notes).
FAULTING_THREAD:  fffffa80087a7a00
DEFAULT_BUCKET_ID:  GRAPHICS_DRIVER_FAULT
CUSTOMER_CRASH_COUNT:  1
BUGCHECK_STR:  0xEA
PROCESS_NAME:  System
CURRENT_IRQL:  0
LAST_CONTROL_TRANSFER:  from fffff88006234f63 to fffff80002cdb1c0
STACK_TEXT:  
fffff880`07d0a608 fffff880`06234f63 : 00000000`000000ea fffffa80`087a7a00 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
fffff880`07d0a610 fffff880`06235112 : fffff880`07d0a6e0 fffff880`06a24a2b fffff880`07d0a6e0 00000000`00003f00 : dxgkrnl!TdrTimedOperationBugcheckOnTimeout+0x37
fffff880`07d0a680 fffff880`0683bf72 : 00000000`00000000 fffff880`06a24a10 fffff880`07d0a800 00000000`01c9c380 : dxgkrnl!TdrTimedOperationDelay+0xbe
fffff880`07d0a6c0 00000000`00000000 : fffff880`06a24a10 fffff880`07d0a800 00000000`01c9c380 fffff800`02ce0028 : [U][B]atikmdag[/B][/U]+0x2bf72
STACK_COMMAND:  .thread 0xfffffa80087a7a00 ; kb
FOLLOWUP_IP: 
dxgkrnl!TdrTimedOperationBugcheckOnTimeout+37
fffff880`06234f63 cc              int     3
SYMBOL_STACK_INDEX:  1
SYMBOL_NAME:  dxgkrnl!TdrTimedOperationBugcheckOnTimeout+37
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: dxgkrnl
IMAGE_NAME:  dxgkrnl.sys
DEBUG_FLR_IMAGE_TIMESTAMP:  4ce799fa
FAILURE_BUCKET_ID:  X64_0xEA_IMAGE_dxgkrnl.sys
BUCKET_ID:  X64_0xEA_IMAGE_dxgkrnl.sys

Thats what i had done the first time around, however, it didnt fix anything and the BSOD's were still happening.

I've tried doing the following but nothing has worked:

Updating the driver through Windows 7 update
Downloading and installing the latest ccc w/ driver for AMD (v12.6)
uninstalled and reinstalled older version of the ccc (v12.4)
trouble shoot through windows action center
uninstalled, ran drive sweeper, reinstalled driver (v11.4)

Is there anything i could do that i havent listed yet? im about ready to give up on it. -___-'

 

[dieniewienie143]

Forgot to add: I brought this card to have it checked and the FSE's who ran a stress test on it said that this card was working fine. This just left me even more confused..

 

[Trouble]

The one and only dump file that you have provided 080512-19234-01.dmp 8/5/2012 10:39:37 AM
reports
atikmdag.sys 4/24/2009
That date is Pre-Windows 8 RTM. Do you have a dump file that was produced when you updated the driver? If so did it blame the same file?
I can only go buy the information I have at hand.
You have an old version of
AsIO.sys 4/6/2009 it's likewise Pre-Windows 8 RTM, I would suggested first uninstalling it, check and confirm that it is no longer present in C:\Windows\System32\Drivers and then if you really need it or something like it check here Link Removed and see if there is an updated version or replacement. I'm not particularly fond of motherboard software as they seem to all be a bit buggy.
Additionally you have
sptd.sys 10/11/2009 which has been often identified as a BSOD problem. Normally associated with Daemon Tools or one of the Alcohol products, I would recommend uninstalling the software and then grab this program from here Link Removed get the correct version for your architecture, run it and click the UNINSTALL button.

 

[Trouble]

You may also want to consider catching up your system BIOS from here ASUS - Motherboards- ASUS SABERTOOTH X58
Looks like you are running an earlier version than is presently available

BiosVendor = American Megatrends Inc.
BiosVersion = 0402   
BiosReleaseDate = 07/30/2010

There has been approximately 7 since then and a couple address system stability.

 

[Trouble]

Sorry for the disjointed replies but also consider updating the drivers for your Marvell disc controller from here Link Removed due to 404 Error scroll down to Marvell MV-91xx (88SE91xx/92xx) Ahci/Raid Controller and grab this one Drivers Version 1.2.0.1027 Xp/Vista/7 New