Random BSOD's - Please Help!

Discussion in 'Windows 7 Help and Support' started by dieniewienie143, Aug 5, 2012.

  1. dieniewienie143

    dieniewienie143 New Member

    Joined:
    Aug 5, 2012
    Messages:
    6
    Likes Received:
    0
    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.


    View attachment Seven Forums - Dieniewienie143.zip
     
  2. Trouble

    Trouble Noob Whisperer

    Joined:
    Nov 30, 2009
    Messages:
    13,845
    Likes Received:
    833
    Update the Driver for your Video Card (ATI Radeon HD 4870 X2) from here AMD Support & Drivers
    Code:
    BugCheck 100000EA, {fffffa80087a7a00, 0, 0, 0}
    Unable to load image \SystemRoot\system32\DRIVERS\  [COLOR=#ff0000][B]atikmdag.sys[/B][/COLOR]  , Win32 error 0n2  
    *** WARNING: Unable to verify timestamp for [COLOR=#ff0000][U][B]atikmdag.sys[/B][/U][/COLOR]
    *** ERROR: Module load completed but symbols could not be loaded for [COLOR=#ff0000][U][B]atikmdag.sys[/B][/U][/COLOR]
    *** 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 : [COLOR=#ff0000][U][B]atikmdag[/B][/U][/COLOR]+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
     
  3. dieniewienie143

    dieniewienie143 New Member

    Joined:
    Aug 5, 2012
    Messages:
    6
    Likes Received:
    0

    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. -___-'
     
  4. dieniewienie143

    dieniewienie143 New Member

    Joined:
    Aug 5, 2012
    Messages:
    6
    Likes Received:
    0
    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..
     
  5. Trouble

    Trouble Noob Whisperer

    Joined:
    Nov 30, 2009
    Messages:
    13,845
    Likes Received:
    833
    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 ASUS 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 DuplexSecure - Downloads get the correct version for your architecture, run it and click the UNINSTALL button.
     
  6. Trouble

    Trouble Noob Whisperer

    Joined:
    Nov 30, 2009
    Messages:
    13,845
    Likes Received:
    833
    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
    Code:
    BiosVendor = American Megatrends Inc.
    BiosVersion = 0402   
    BiosReleaseDate = 07/30/2010
    There has been approximately 7 since then and a couple address system stability.
     
  7. Trouble

    Trouble Noob Whisperer

    Joined:
    Nov 30, 2009
    Messages:
    13,845
    Likes Received:
    833
    Sorry for the disjointed replies but also consider updating the drivers for your Marvell disc controller from here Marvell drivers 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
     

Share This Page

Loading...