The latest dump (1st Nov) also points very strongly at a RAM problem. The bugcheck code is 0xA, IRQL_NOT_LESS_OR_EQUAL, and that simply means that a page fault occurred whilst running at an elevated IRQL (when page faults are not allowed). The reason for the page fault is because the referenced memory page was not allocated, was paged out, or the RAM was bad. Commonly this BSOD is caused by a third-party driver fouling up a memory pointer and trying to read memory that it hasn't allocated or doesn't own. In this case however, there are no third-party drivers on the call stack leading to the bugcheck. In addition, the bugcheck occurred during idle processing.
Here's the call stack (you read it from the bottom up)...
Code:
1: kd> knL
# Child-SP RetAddr Call Site
00 ffff9400`f023e8e8 fffff807`5ec2bfa9 nt!KeBugCheckEx
01 ffff9400`f023e8f0 fffff807`5ec27634 nt!KiBugCheckDispatch+0x69
02 ffff9400`f023ea30 fffff807`5ea3d0bc nt!KiPageFault+0x474
03 ffff9400`f023ebc0 fffff807`5ec20509 nt!KiBeginThreadAccountingPeriod+0x16c
04 ffff9400`f023ec00 fffff807`5ec1b846 nt!SwapContext+0x629
05 ffff9400`f023ec40 00000000`00000000 nt!KiIdleLoop+0x176
You can see that the page fault occurred in a Windows function - nt!KiBeginThreadAccountingPeriod - and Windows code is error free, so this is not a bug in Windows. If we look at the details of that frame...
Code:
1: kd> .frame /r 3
03 ffff9400`f023ebc0 fffff807`5ec20509 nt!KiBeginThreadAccountingPeriod+0x16c
rax=0000000001000001 rbx=ffff800e11a9a080 rcx=0000000003001052
rdx=ffffa88113e62410 rsi=ffffa880fbe5a180 rdi=00000000000000a0
rip=fffff8075ea3d0bc rsp=ffff9400f023ebc0 rbp=0000000000000001
r8=0000000000000000 r9=0000000000000000 r10=ffff800e041ae6c4
r11=ffff9400f023eb68 r12=0000000001000000 r13=ffff800e12e55080
r14=00000000000000ae r15=ffffa880fbe69000
iopl=0 nv up di ng nz na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00040086
nt!KiBeginThreadAccountingPeriod+0x16c:
fffff807`5ea3d0bc 488b0cce mov rcx,qword ptr [rsi+rcx*8] ds:002b:ffffa881`13e62410=????????????????
BAD_STACK_POINTER: ffff9400f023e8e8
Here you can see that the failing instruction was a MOV instruction using the RSI and RCX registers are pointers. Those two registers seem to have values stored in them (ie. they're not zeroed and thus possibly flaky) and yet the resulting memory location, which seems to be a reasonable address (it's in the kernel space), is invalid - note the ???????????????? - and that's what caused the page fault.
In addition, at the bottom there we have a flag for a bad stack pointer, this indicates that there has been a foul-up in incrementing (or decrementing) a stack pointer and that's not the fault of the Windows function of course. Thus we have a Windows function executing what looks likes a good instruction and yet the target memory location is invalid. In addition the stack pointer (which likely depends on the result of this instruction) is invalid. It's hard to imagine any other cause for this other than the RAM at that target memory location is bad.
My advice would be to remove one RAM stick and run on just one for a few days, or until you get a BSOD. Then swap sticks and run on just the other for a few days, or until you get a BSOD. That's the very best RAM test you can do.
