This is very interesting. In a good bit of your crashdumps, they involve a fault in the function
nt!MiReplenishPageSlist (which I believe is done when freeing memory as you can tell from the rest of the stack). Even more curious is the fact that in all these cases where this is involved, the
same memory address is addressed, which is
bffffa80`087bcf10. Immediately you should tell that this is a bad address as it has a
'b' at the end of it. However, the fact it's always the same exact address, being performed by the same function, is very bewildering.
I did a bit of disassembly, and now I'm even a bit more befuddled about it. Here's what I mean:
Code:
2: kd> .cxr 0xfffff8800c52aed0
rax=04000000002cfafb rbx=bffffa80086f0f10 rcx=0000058000000000
rdx=0000000000000050 rsi=000000000000000e rdi=0000000000000002
rip=fffff800032a2f00 rsp=fffff8800c52b8b0 rbp=fffffa80087be710
r8=fffff800034b24c0 r9=fffffa800cbfa000 r10=fffffa800cbfb358
r11=fffff88003565180 r12=fffff800034b24c0 r13=2aaaaaaaaaaaaaab
r14=fdffffffffffffff r15=0000058000000000
iopl=0 nv up ei pl nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010202
nt!MiReplenishPageSlist+0xc0:
fffff800`032a2f00 f00fba6b1000 lock bts dword ptr [rbx+10h],0 ds:002b:bffffa80`086f0f20=????????
So the instruction at fffff800`032a2f00 referenced the bad address by getting what's in the rbx register, adding 10h to it, and then using that as an address. As you can tell in the short list of general registers that rbx does in fact have that oddball address with the 'b' in it, but how did it get it? Time to disassemble starting from the bad instruction and working upwards (backwards):
Code:
fffff800`032a2ef6 48895c2420 mov qword ptr [rsp+20h],rbx < rbx moved into spot where rsp+20h directs too.
fffff800`032a2efb 33ed xor ebp,ebp
fffff800`032a2efd 4c8bf9 mov r15,rcx
fffff800`032a2f00 f00fba6b1000 lock bts dword ptr [rbx+10h],0 < bad instruction
Fortunately whatever was in the rbx register was slapped into the stack (hence using
rsp, or
stack pointer register), and since the minidumps retain the faulting stack, we should be able to get the value. So let's see what's stuffed there that rbx placed onto the stack:
Code:
2: kd> dq @rsp+20
fffff880`0c52b8d0 fffffa80`086f2710 00000000`00000000
fffff880`0c52b8e0 00000000`0000007b 00000000`002cfbfb
fffff880`0c52b8f0 fffff880`0c52b980 00000000`0000007f
fffff880`0c52b900 00000000`00000000 fffffa80`086f3f10
fffff880`0c52b910 fffffa80`0cbfb338 fffff800`032a16bf
fffff880`0c52b920 fffffa80`0cbfb338 00000000`0000007b
fffff880`0c52b930 fffffa80`086f3f10 00000000`0000007b
fffff880`0c52b940 fffffa80`0cbfb400 00000000`00000001
So this is the address that was grabbed from the rbx register. It looks similar, but not much the same, as the bad address. Let's compare the two bit-wise. Remember that the bad address wasn't originally made just straight from the rbx register. Rather, the instruction also added 10h to it and then used the result as the memory address. So to imitiate what
should have happened, let's add 10h to the address in the stack and then compare that to the bad address:
Code:
2: kd> .formats fffffa80`086f2710+10;.formats bffffa80`086f0f20
Evaluate expression:
Hex: fffffa80`086f2720
Decimal: -6047172450528
Octal: 1777777650001033623440
Binary: 11111111 11111111 11111010 10000000 00001000 01101111 00100111 00100000
Chars: .....o'
Time: ***** Invalid FILETIME
Float: low 7.19674e-034 high -1.#QNAN
Double: -1.#QNAN
Evaluate expression:
Hex: bffffa80`086f0f20
Decimal: -4611692065599844576
Octal: 1377777650001033607440
Binary: 10111111 11111111 11111010 10000000 00001000 01101111 00001111 00100000
Chars: .....o.
Time: ***** Invalid FILETIME
Float: low 7.19392e-034 high -1.99983
Double: -1.99866
As you can tell, from bits, they look reeeeeeally close to each other. However, aside from the
'b' at the end, the second octet in each number doesn't look close. I can't tell how from hardware how both a bit would be removed and then one set a couple digits away, almost as if it was shifted over a little. I
guess this could happen from hardware, but then why is it that this exact same address is referenced in multiple crashdumps using the same function? I'm puzzled. Maybe I'm missing something here based on my lack of knowledge.
Btw, just so you know, I went ahead and dumped the raw stacks for some of your crashdumps and noticed they involved your graphics drivers in an attempt to draw something. I found they're dated from Dec 2011 so you may wanna look at updating em. Go ahead and run Prime95 and Memtest as well, just to be safe.