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?
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:
0: kd> x nt!MmBadPageListHead
fffff800`02df1c80 nt!MmBadPageListHead = <no type information>//should be struct _MMPFNLIST
0: kd> dt nt!_MMPFNLIST fffff800`02df1c80
+0x000 Total :0
+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.
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.
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.
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.
0: kd> !verifier
Verify Level 0 ... enabled options are:
Summary of All Verifier Statistics
Synch Executions 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.
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?