I'm afraid we may very well be dealing with CPU failure here. A good majority of your crashdumps report very unusual behavior from the CPU, and one especially is evident of CPU problems when the crash is caused by a bad memory reference despite the fact that the instruction opcode that triggered it doesn't even attempt to touch memory!
Just to be sure, if you have your system overclocked in any way at all, please reset
all of it to factory defaults. Uninstall
all software that came with your motherboard, including any monitoring or overclocking software. Update the
drivers for your video card, your motherboard and all its components and your BIOS, since everything I've found is well over a year old.
If none of that resolves your issue, then it's definitely time to start looking for a replacement CPU. The only other hardware I could see that might even
remotely have a chance of causing this is the motherboard, but it's very seldom. Understand also that if you've inadvertently had your CPU running hot over extended periods of time, it will cause permanent damage that would simply slay any chance of using it reliably.
Analysts:
Pretty much all of them are odd in that the bugcheck claims one memory address is addressed wrong yet another completely different one is referred too by the faulting IP. However a couple, like this one (2nd to oldest) is a good example of some serious CPU problems:
Code:
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff8000316335f, Address of the instruction which caused the bugcheck
Arg3: fffff8800a5f3f50, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.
Debugging Details:
------------------
TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\triage\modclass.ini, error 2
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.
FAULTING_IP:
nt!SeDeleteAccessState+3b
fffff800`0316335f 4885db test rbx,rbx
CONTEXT: fffff8800a5f3f50 -- (.cxr 0xfffff8800a5f3f50)
rax=fffff8800a5f49d0 rbx=fffff8800a5f4a70 rcx=0000000000000000
rdx=0000000000000001 rsi=fffffa8006e9d570 rdi=fffff8800a5f49d0
rip=fffff8000316335f rsp=fffff8800a5f4930 rbp=00000000c0000024
r8=0000000000000000 r9=0000000000000030 r10=fffffa8006ea51c0
r11=fffffa800a274900 r12=0000000000000001 r13=0000000000000000
r14=00000000006bf170 r15=fffffa8008819b90
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010246
nt!SeDeleteAccessState+0x3b:
fffff800`0316335f 4885db test rbx,rbx
Resetting default scope
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
BUGCHECK_STR: 0x3B
PROCESS_NAME: SteamService.e
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff8000316335f
STACK_TEXT:
fffff880`0a5f4930 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!SeDeleteAccessState+0x3b
FOLLOWUP_IP:
nt!SeDeleteAccessState+3b
fffff800`0316335f 4885db test rbx,rbx
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: nt!SeDeleteAccessState+3b
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc600
STACK_COMMAND: .cxr 0xfffff8800a5f3f50 ; kb
FAILURE_BUCKET_ID: X64_0x3B_nt!SeDeleteAccessState+3b
BUCKET_ID: X64_0x3B_nt!SeDeleteAccessState+3b
Followup: MachineOwner
---------
When looking up the TEST opcode in the AMD Developer Manual, Volume 3, it describes that the TEST opcode will accept either a memory address reference or a register and simply perform a bitwise logical AND operation on it with the other operand. We can evidently see here that neither the first nor second operand for this is using a memory address, but rather the register
rbx. If it were a memory address,
rbx would be in brackets signifying that the value in
rbx is a memory address that it should reference. There is no memory reference here, yet this is what caused the fault by accessing bad memory. I've only seen this so far in cases regarding motherboard of CPU problems, with CPU most frequent.