0x101 "A clock interrupt was not received on a secondary processor..."

Yes, you'll need to install the ATI APP SDK as ATI drivers do not come with OpenCL, unlike Nvidia. You'll have to get it through installing the SDK.

Anyways, how many passes did you run of Memtest86+? I ask because I looked back on the kernel dump you provided and noticed this:

Code: 
0: kd> !memusage 0x8
 loading PFN database
loading (100% complete)
Compiling memory usage data (99% Complete).
             Zeroed:   1777 (  7108 kb)
               Free:      5 (    20 kb)
            Standby: 580316 (2321264 kb)
           Modified:  15540 ( 62160 kb)
    ModifiedNoWrite:      0 (     0 kb)
       Active/Valid: 442508 (1770032 kb)
         Transition:      2 (     8 kb)
[COLOR=#ff0000]                Bad:     13 (    52 kb)[/COLOR]
            Unknown:      0 (     0 kb)
              TOTAL: 1040148 (4160592 kb)

That shouldn't happen. It means Windows detected failed RAM when attempting to allocate, and therefore marked them as bad, much like CHKDSK when it marks hard drive sectors as bad to prevent further attempts at using them. I'd personally like to see one more kernel dump from you to correlate this discovery, but for now it looks like we're dealing with memory issues. However, this can also be attributed to motherboard problems or PSU issues. Windows cannot discern the cause for why the RAM failed during allocation attempt, only that it did.

There is a very slim chance that a program called MmMarkPhysicalMemoryAsBad in order to restrain other threads from looking at the allocations while it fiddles with em, but I doubt it, especially given that I looked through all running processes (using !stacks 0 MmMarkPhysicalMemoryAsBad) and no threads came up showing that they have that function in their callstack, so nothing appears to have called it on purpose. I am most certain we're dealing with hardware malfunctioning now.
 
I only ran one run of Memtest86+ but in a single test I recall it giving a number of passes. Seemingly I misunderstood what you meant. I will run Memtest86+ several more times and let you know what happens. Kernel dump from 8.46pm yesterday is more recent than the last one I uploaded, so I uploaded it here. For future reference, are .CSV files acceptable uploads for my HWInfo logging runs?
 
Last edited:
When I first built my computer I had faulty ram which lead to all sorts of problems...

first pass of memtest passed with flying colors...

It wasn't until the 7th pass that they exploded in errors. After being RMA'ed and replaced it was confirmed they were the source of the issue...

Moral of the story, test each stick individually with multiple passes :thumbsup2:
Sidenote, I will chat with the admin team so we can get .CSV's added to our upload list.
 
I only have one stick so that should cut down my work heh. I can just zip up the .CSV so i should be able to upload it, I was wondering if people were happy with me uploading .CSV files.
 
Not yet James, like I said I don't know what I'm doing in setup. I will try setting everything to optimised again (I'm sure I did this in the first place), with a particular attention to setting the ram frequency to 1300MHz. Then I'll do these many runs of memtest (when I find my pendrive).
 
Memtest runs (or should run) indefinitely. It has multiple tests that it will conduct in sequence, then when all of them are done, it will start over with the first test (therefore making one full pass). You want at least 7 full passes.

Anyways, I may be running off course here. I checked the actual data structure that lists the pages marked bad as explained in a comment here:

Code: 
0: kd> x nt!MmBadPageListHead
fffff800`02df1c80 nt!MmBadPageListHead = [COLOR=#ff8c00]<no type information>[/COLOR]     [COLOR=#008000]//should be struct _MMPFNLIST[/COLOR]
0: kd> dt nt!_MMPFNLIST fffff800`02df1c80
   +0x000 Total            :[COLOR=#0000cd] [B]0[/B][/COLOR]
   +0x008 ListName         : 5 ( BadPageList )
   +0x010 Flink            : 0xffffffff`ffffffff
   +0x018 Blink            : 0xffffffff`ffffffff
   +0x020 Lock             : 0


Doesn't look like they retained their status as bad. It may have been from a driver intentionally marking them bad after all. I still recommend doing the full Memtest86+ anyways if you haven't already, but I reckon that would explain the 0x101 bugchecks, because I personally can't see how bad RAM would cause 0x101 bugchecks but no other bugcheck.
 
Vir Gnarus said:
I personally can't see how bad RAM would cause 0x101 bugchecks but no other bugcheck.
Click to expand...

+1, usually a couple of x1A, x50, x0A, and maybe x109 also.

I still like the VCore as low. Could just be my persistent nature. :D

oatcoat', any way you can upload the main screen of CPUz idle and also running P95?
 
I can give you a whole bonanza of screens now, turns out the latest BIOS lets me screenshot setup screens to a flash drive (pretty sure I couldn't do that before). Some of the screens are duplicates because you can scroll up and down in some of the tabs. These are the optimised settings as I point out in "optimised.jpg". I will upload them to this post, along with the CPUz screens which James requested.
 
Last edited by a moderator:
FYI - I've run MemTest86+ over the weekend and picked up a couple of errors on a system at work. It had something like 168 passes total.

Also, sometimes Prime95's Blend test will spit out errors even if MemTest86+ has passed the RAM.
 
I have some HWinfo logs to post, I figured I would keep logging in half hour intervals while p95 is running. After this p95 stint, I will probably run the driver verifier to see if another tasty kernel dump will pop out for you.

Vic Gnarus, just to clarify. The kernel dump which you analysed before WAS from a driver verifier induced BSOD.
 
Last edited by a moderator:
Another update: I ran Prime95 for 19 hours, got no errors. Have been running the driver verifier for almost 2 days now, it hasn't picked up anything. So without having had a BSOD for a while now, I am feeling optimistic that you guys have helped me eliminate them for good. The only change I have made between my last BSOD and now is removing the drivers usasma listed in post #32.

I can't thank you all enough for the patient advice you have given me, I know I have been a bit slow on the uptake at times. I could well be premature in saying the problem is fixed (I have gone for around a week without a BSOD in the past) but regardless, I have learned a great deal from everyone who has posted.

Fingers crossed and goodbye.
 
Thank you for posting back - much appreciated.

Marking this SOLVED for now. If you encounter additional problems, we'll be here!

Regards. . .

jcgriff2
 
oatcoatedstoat said:
Vic Gnarus, just to clarify. The kernel dump which you analysed before WAS from a driver verifier induced BSOD.
Click to expand...

Wouldn't be too sure about that:

Code: 
0: kd> !verifier

Verify Level 0 ... enabled options are:

Summary of All Verifier Statistics

RaiseIrqls                             0x0
AcquireSpinLocks                       0x0
Synch Executions                       0x0
Trims                                  0x0

Pool Allocations Attempted             0x0
Pool Allocations Succeeded             0x0
Pool Allocations Succeeded SpecialPool 0x0
Pool Allocations With NO TAG           0x0
Pool Allocations Failed                0x0
Resource Allocations Failed Deliberately   0x0

Current paged pool allocations         0x0 for 00000000 bytes
Peak paged pool allocations            0x0 for 00000000 bytes
Current nonpaged pool allocations      0x0 for 00000000 bytes
Peak nonpaged pool allocations         0x0 for 00000000 bytes

Anyways, it sounds like everything may have been taken care of. Despicable motherboard software like what you had always has a tendency to create ugly and difficult to analyze symptoms like this (often time they'll even create hardware BSODs).

I'll keep this kernel dump on hold until I manage to figure out how to reconstruct thread stacks, where I can then properly and sufficiently analyze this crash and figure out just what bugged out. Thanks for bringing this to our attention, and I hope it ends up working out for ya.
 
Just had another BSOD, while running a game. How disappointing. The kernel dump is uploaded here, the minidump is attached to this post for completeness.

@Vir Gnarus: OK sorry, I thought that kernel dump was from Driver Verifier. Quite annoyed with myself that I don't have a dump from the driver verifier now.
 
Last edited by a moderator:
All right, I'll see what I can do with it. Remember to turn DV back on with the recommended settings (no Force Pending I/O Requests, IRP Logging, and Low Resource Sim). Also, I did notice that your network drivers are still as dated as they were when you came to us (June 2011). No updates for em?
 
I've no idea where to get them, I thought they might be available from the motherboard manufacturer but no luck there. Do I have to figure out what network hardware my motherboard uses or something?
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top