Firstly, did you update the BIOS to the latest version (including the AGESA update)?
Secondly, and just for your education, a very large number of BSODs reference ntoskrnl.exe (the Windows kernel) or, as in this dump, ntkrnlmp.exe (the Windows multiprocessor kernel). That's because most drivers run in kernel mode and if a driver fouls up (or the hardware fouls up a driver) the problem is not often detected until the driver retruns control to the kernel and the kernel validates what the driver is asking for. If at that point the kernel finds that the driver has fouled up it will BSOD (because the kernel has no way of knowing whether the foul up will corrupt user data - BSODs occur to protect user data) and the failing module in the dump will then of course be the kernel. That's why you need people with experience in analysing dumps, because it's necessary to be able to interpret what the kernel was doing, which drivers were involved, and where the problem occured.
I've looked at that 0xA mindump you uploaded and whilst it's dangerous making a diagnosis based on only one dump, my belief is that this is most likely a RAM problem.
Here's the key part of the call stack from your recent minidump. This logs all the function calls that led up to the bugcheck and you read it from the bottom up...
Code:
9: kd> knL
# Child-SP RetAddr Call Site
00 ffffdb08`cb8e6108 fffff800`76227da9 nt!KeBugCheckEx
01 ffffdb08`cb8e6110 fffff800`76223434 nt!KiBugCheckDispatch+0x69
02 ffffdb08`cb8e6250 fffff800`76023ffb nt!KiPageFault+0x474
03 ffffdb08`cb8e63e0 fffff800`76027d23 nt!KiSetClockTimer+0x73
04 ffffdb08`cb8e6530 fffff800`7602748a nt!KeResumeClockTimerFromIdle+0x1b3
05 ffffdb08`cb8e6610 fffff800`760268b1 nt!PpmIdleExecuteTransition+0x9aa
06 ffffdb08`cb8e6a50 fffff800`762174f4 nt!PoIdle+0x361
07 ffffdb08`cb8e6c40 00000000`00000000 nt!KiIdleLoop+0x54
The processor is running the idle loop here, there is no real work for it to do so this is all housekeeping. You can see that wer're getting and resetting a clock timer, and then we get a page fault. This indicates that an invalid memory location was referenced - it was either paged out, not allocated, or the RAM page is bad.
We can see exactly where the page fault occurred in the dump as well, and why...
Code:
TRAP_FRAME: ffffdb08cb8e6250 -- (.trap 0xffffdb08cb8e6250)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000022b213a676e rbx=0000000000000000 rcx=0000022b213a676e
rdx=00000000000001d8 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80076023ffb rsp=ffffdb08cb8e63e0 rbp=ffffdb08cb8e64e0
r8=0000000000000000 r9=fffff78000000294 r10=0000fffff800761c
r11=ffff91fcd8200000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up di pl nz na pe nc
nt!KiSetClockTimer+0x73:
fffff800`76023ffb 4c89b4f7188e0000 mov qword ptr [rdi+rsi*8+8E18h],r14 ds:00000000`00008e18=????????????????
Resetting default scope
Here you can see that the nt!KiSetClockTimer function is executing the mov instruction using the RDI and RSI registers as pointers to a memory location, but the resulting location is invalid (indicated by the ????????????????). It's not credible that these Windows functions calculated the address location wrongly, so bad RAM is the most likely cause.
Note: It is also remotely possible that the processor (CPU) is the cause. Note that the RSI register is all zeros and that's what has caused the invalid address pointer. Whilst bad RAM is the most likely cause and must be tested, this could be a flaky processor in your CPU. We can test that once you've tested your RAM.
I do note that earlier you said this...
I haven't ran memtest86, yet, because I don't have the time to do so, yet.
Do you see how that might be insulting to those of us who give up our free time to help you fix whatever problem you're having? What if we said that we don't have the time to help you? I have plenty of other things I could be doing on this sunny and warm Sunday.
Please test your RAM. We really can't move on until we are confident that RAM is not the problem...
If you have more than one stick of RAM then remove one stick and run on just one for a couple of days - or until you get another BSOD. Then swap RAM sticks and run on just the other RAM stick for a couple of days. This will clearly show whether one stick is flaky.
-or-
Download Memtest86 (free), use the imageUSB.exe tool extracted from the download to make a bootable USB drive containing Memtest86 (1GB is plenty big enough).
Do this on a different PC if you can, because you can't fully trust yours at the moment. Then boot that USB drive on your PC, Memtest86 will start running as soon as it boots. If no errors have been found after the four iterations of the 13 different tests then restart Memtest86, and do another four iterations. Even a single error is a failure.
Facebook
Twitter
Instagram