1. #1


    AMD 64 x2 5000+
    2gb RAM
    Windows Vista Service Pack 2
    Nvidia 9500GT 1gb
    ms-7253 motherboard

    I have been getting frequent BSOD for a little while now, mostly while running games or streaming. However sometimes after the BSOD, when I restart the computer it occasionally Blue Screens again. I always eventually can get back onto windows.

    I have just used Driver Verifier which forced a BSOD and then again, while trying to restart, I got a second BSOD.

    Here are the Minidumps in that order...
    Attached Files Attached Files

    • Ad Bot



  2. #2



    We have two bug checks:


    This indicates that Microsoft Windows or a kernel-mode driver accessed paged memory at DISPATCH_LEVEL or above.

    This bug check is issued if paged memory (or invalid memory) is accessed when the IRQL is too high. The error that generates this bug check usually occurs after the installation of a faulty device driver, system service, or BIOS.

    0: kd> .trap 82d0ca00
    ErrCode = 00000002
    eax=82d0ca88 ebx=000001ff ecx=0000a0cb edx=82d0ca88 esi=83d196e0 edi=83d196e0
    eip=82fd4fe9 esp=82d0ca74 ebp=82d0cab0 iopl=0         nv up ei pl zr na pe nc
    cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010246
    82fd4fe9 8711            xchg    edx,dword ptr [ecx]  ds:0023:0000a0cb=????????
    0: kd> knL
      *** Stack trace for last set context - .thread/.cxr resets it
     # ChildEBP RetAddr  
    00 82d0ca70 82d05683 hal!KeAcquireInStackQueuedSpinLockRaiseToSynch+0x19
    01 82d0cab0 82d04858 nt!ExDeferredFreePool+0x6c
    02 82d0cb18 8d17b480 nt!ExFreePoolWithTag+0x852
    03 82d0cb38 8d17b05a usbhub!UsbhReferenceListRemove+0xab
    04 82d0cb68 82cc11eb usbhub!UsbhDmTimerDpc+0x26
    05 82d0cc88 82cc0dab nt!KiTimerListExpire+0x367
    06 82d0cce8 82cc1515 nt!KiTimerExpiration+0x22a
    07 82d0cd50 82cbf77d nt!KiRetireDpcList+0xba
    08 82d0cd54 00000000 nt!KiIdleLoop+0x49
    0: kd> u @eip
    82fd4fe9 8711            xchg    edx,dword ptr [ecx]
    82fd4feb 83fa00          cmp     edx,0
    82fd4fee 7505            jne     hal!KeAcquireInStackQueuedSpinLockRaiseToSynch+0x25 (82fd4ff5)
    82fd4ff0 83480402        or      dword ptr [eax+4],2
    82fd4ff4 c3              ret
    82fd4ff5 83480401        or      dword ptr [eax+4],1
    82fd4ff9 8902            mov     dword ptr [edx],eax
    82fd4ffb 33c9            xor     ecx,ecx
    ^^ Very interesting, we have a Hardware Abstraction Layer routine having to do with a spinlock. There's mention of the usbhub in the call stack, however that may be an incorrect blame on Windows as to what the fault was.


    This indicates that an expected clock interrupt on a secondary processor, in a multi-processor system, was not received within the allocated interval.

    First off, I noticed DV was enabled:

    0: kd> !verifier
    Verify Level 92b ... enabled options are:
        Special pool
        Special irql
        All pool allocations checked on unload
        Deadlock detection enabled
        Security checks enabled
        Miscellaneous checks enabled
    However, no 3rd party driver was found making invalid function calls, and instead a 0x101 bugcheck is called.

    Also -- FAILURE_BUCKET_ID: 0x101_AMD_SP1_VRF

    ^^ The error was noted by the processor as opposed to Windows, this is very interesting.

    Overall, we may have a processor issue, or another underlying hardware issue. Let's do some detective work first.

    1. Remove and replace AVG with Microsoft Security Essentials for temporary troubleshooting purposes:

    AVG removal - http://www.avg.com/us-en/utilities

    MSE - Microsoft Security Essentials - Microsoft Windows

    2. If you're still crashing after the above, we're going to a Kernel-Dump to debug the 0x101 bugchecks:

    Please view this to set up generation of Kernel-Dumps - Creating a Kernel-Mode Dump File (Windows Debuggers)

    Kernels are located in C:\Windows and are labeled MEMORY.DMP.



  3. #3


    Hi Patrick,

    Thanks for looking into the minidumps for me.
    Just recently had another BSOD . I have a MEMORY.dmp for it however, even though i have zipped the file, when I try to upload it , it takes a while then stops and the upload fails

  4. #4


    My apologies, I should have mentioned that MEMORY.DMP's are too large to attach locally here on Sysnative, so you'll need to use a 3rd party site such as Onedrive, Dropbox, etc... whatever works best for you.



  5. #5


    Here is the link to my MEMORY.DMP.


  6. #6


    Thanks very much!

    As I hoped, it's of the 0x101 bug check I discussed above. Let's get into it!


    This indicates that an expected clock interrupt on a secondary processor, in a multi-processor system, was not received within the allocated interval.

    BugCheck 101, {61, 0, 803d1120, 1}

    ^^ 61 clock ticks in regards to the timeout.

    803d1120 is the PRCB address of the hung processor, let's keep this address in mind.

    0: kd> !prcb 1
    PRCB for Processor 1 at 803d1120:
    Current IRQL -- 0
    Threads--  Current 803d51e0 Next 00000000 Idle 803d51e0
    Number 1 SetMember 2
    Interrupt Count -- c08b4267
    Times -- Dpc    00000b48 Interrupt 00000aad 
             Kernel 0007e984 User      0000edbf
    Here's our problematic processor (#1).

    Hint: At times, the 4th parameter of the bug check will show you the responsible processor. For example, in your *101 here, it was correct as the 4th parameter was 1.

    In most cases, you can also generally tell the amount of cores on the box by checking the bugcheck_string within WinDbg. However, in your case, very different - BUGCHECK_STR: 0x101_AMD_SP1. As we discussed above, this likely indicates your processor itself had an issue and called a bugcheck as opposed to Windows seeing there's a problem, telling the processor, and calling the bugcheck.

    As this matches the 3rd parameter of the bug check, processor #1 is the responsible processor. Now with the information we have here thus far, we know that processor #1 reached 61 clock ticks without responding, therefore the system crashed. Before we go further, what is a clock tick? A clock interrupt is a form of interrupt which involves counting the the cycles of the processor core, which is running a clock on the processors to keep them all in sync. A clock interrupt is handed out to all processors and then they must report in, and when one doesn't report in, you then crash.

    Let's now look at the stacks of the different processors to see what the threads were involved in:

    We can use knL and go through a grueling method of obtaining the trap frame, but we don't like having to put in more work, so let's use kv instead on Processor 0. Thankfully you only have a dual core system (thank you.... really...):

    0: kd> kv
    ChildEBP RetAddr  Args to Child              
    82d0cc30 82cc27ad 00000101 00000061 00000000 nt!KeBugCheckEx+0x1e
    82d0cc64 82cc454d ffffff02 000000d1 82d0ccf8 nt!KeUpdateRunTime+0xd5
    82d0cc64 88717a9c ffffff02 000000d1 82d0ccf8 nt!KeUpdateSystemTime+0xed (FPO: [0,2] TrapFrame @ 82d0cc74)
    82d0cce4 88718c0b 82cc7c56 86a9a9f0 82d11790 amdk8!C1Halt+0x4 (FPO: [0,0,0])
    82d0cce8 82cc7c56 86a9a9f0 82d11790 82d0cd50 amdk8!C1Idle+0x5 (FPO: [0,0,0])
    82d0ccf8 82cc7ba4 868b68c0 00000000 86faad78 nt!PpmCallIdleHandler+0x2e
    82d0cd50 82cbf741 00000000 0000000e 00000000 nt!PoIdle+0x2d1
    82d0cd54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0xd (FPO: [0,0,0])
    There it is! Let's move forward:

    0: kd> .trap 82d0cc74
    ErrCode = 00000000
    eax=86a9a9f0 ebx=00028775 ecx=86af7c40 edx=00000000 esi=868b68c0 edi=86a9aa0c
    eip=88717a9c esp=82d0cce8 ebp=82d0ccf8 iopl=0         nv up ei ng nz ac po cy
    cs=0008  ss=0010  ds=0003  es=0000  fs=0588  gs=1300             efl=00000293
    88717a9c c3              ret
    Let's dump the stack:

    0: kd> knL
      *** Stack trace for last set context - .thread/.cxr resets it
     # ChildEBP RetAddr  g
    00 82d0cce4 88718c0b amdk8!C1Halt+0x4
    01 82d0cce8 82cc7c56 amdk8!C1Idle+0x5
    02 82d0ccf8 82cc7ba4 nt!PpmCallIdleHandler+0x2e
    03 82d0cd50 82cbf741 nt!PoIdle+0x2d1
    04 82d0cd54 00000000 nt!KiIdleLoop+0xd
    ^^ What's happening here in this stack is your C1 state kicks in by idling the processor, and then halting it. All x86 processors (32-bit) have an instruction known as HLT which is is 'Halt' in what we see in the stack here - amdk8!C1Halt. This does exactly what the word 'halt' would describe, which is to idle the CPU and halt it from doing anything until it receives an interrupt. An interrupt is a signal sent by the hardware to the CPU that basically says "Hey, I need this done right now, so stop what you're doing and take care of it".

    Why is this done? Well, in simplest terms, to limit power cunsumption. It's a power management feature.

    Let's take a look into Processor #1's call stack like we did Processor #0:

    1: kd> kv
    ChildEBP RetAddr  Args to Child              
    803ecce4 88718c0b 82cc7c56 86af5578 803d2f90 amdk8!C1Halt+0x4 (FPO: [0,0,0])
    803ecce8 82cc7c56 86af5578 803d2f90 803ecd50 amdk8!C1Idle+0x5 (FPO: [0,0,0])
    803eccf8 82cc7ba4 86af4ab0 00000000 87549d78 nt!PpmCallIdleHandler+0x2e
    803ecd50 82cbf741 00000000 0000000e 00000000 nt!PoIdle+0x2d1
    803ecd54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0xd (FPO: [0,0,0])
    ^^ Same as above, but we can see that this specific processor wakes up from its halt to respond to this hardware signal as I discussed earlier.

    So, what's the summary? Well, it appears that your CPU is reporting a CLOCK_WATCHDOG_TIMEOUT during a C1 Halt on your CPU, which is never supposed to happen during normal operation. Both cores of your processor were asleep, but then #0 came out of its halt state to reply to a hardware signal, and said to #1 "Hey, wake up, I need you to do this".... but #1 kept snoozing.

    1: kd> lmvm amdk8
    start    end        module name
    88716000 88726000   amdk8      (pdb symbols)          c:\localsymbols\amdk8.pdb\05084BEF43034D28A25660D0222439C01\amdk8.pdb
        Loaded symbol image file: amdk8.sys
        Image path: \SystemRoot\system32\DRIVERS\amdk8.sys
        Image name: amdk8.sys
        Timestamp:        Sat Jan 19 00:27:20 2008
    ^^ Your chipset is dated circa 2008, which appears to be the latest according to MSI's website.

    What does this mean? Likely very strong indication of a faulty CPU. Given the age of this machine just by taking a look at its hardware, it unfortunately doesn't surpise me at all. We can try the following first, though:

    1. Ensure your temperatures are within standard and nothing's overheating. You can use a program such as Speccy if you'd like to monitor temps - Speccy - System Information - Free Download

    2. Clear your CMOS (or load optimized BIOS defaults) to ensure there's no improper BIOS setting - How To Clear CMOS (Reset BIOS)

    3. Ensure your BIOS is up to date via MSI's website.

    4. Disable C1 states in the BIOS.

    5. If all of the above fail, the only left to do is replace your processor as it is faulty. Given the age of the system, it may be worth it more not only cost-wise, but in general just to go ahead and if possible build a new system entirely.



  7. #7


    Hi Patrick.
    Many thanks again for looking into this for me.
    I followed your steps as listed above and still getting the BSOD especially while computer is under high load.
    I had originally thought that the cpu could possibly be at fault but your help has pretty much confirmed this for me.
    Just wanted to rule other possible software related issues out.
    Now starts my arduous search to create a new half decent spec but cost effective system

  8. #8


    Thanks for the update.

    Indeed, unfortunately seems like the CPU is on its way out.



Similar Threads

  1. Frequent BSOD Win7 Pro x64
    By Smuckerz in forum BSOD, Crashes, Kernel Debugging
    Replies: 24
    Last Post: 05-07-2014, 01:45 AM
  2. Frequent BSOD Problems.
    By JohnAbyss in forum BSOD, Crashes, Kernel Debugging
    Replies: 5
    Last Post: 01-27-2014, 06:24 AM
  3. Dell XPS fairly frequent BSOD
    By pannonia909 in forum BSOD, Crashes, Kernel Debugging
    Replies: 24
    Last Post: 11-28-2013, 02:00 PM
  4. Frequent (but not constant) BSOD upon awaking from sleep/hibernate
    By Tarp in forum BSOD, Crashes, Kernel Debugging
    Replies: 1
    Last Post: 11-09-2013, 07:36 AM
  5. Frequent BSOD in Windows 7 SP-1
    By tharrat in forum BSOD, Crashes, Kernel Debugging
    Replies: 1
    Last Post: 05-28-2013, 10:42 AM

Log in

Log in