The first dump (the 'what happened' dump) is a 0xD1, DRIVER_IRQL_NOT_LESS_OR_EQUAL bugcheck, and appears to point at the graphics driver amdkmdag.sys...
Code:
0: kd> knL
# Child-SP RetAddr Call Site
00 fffff803`77c83b08 fffff803`7501ee29 nt!KeBugCheckEx
01 fffff803`77c83b10 fffff803`7501a9e3 nt!KiBugCheckDispatch+0x69
02 fffff803`77c83c50 fffff80f`4b82a570 nt!KiPageFault+0x463
03 fffff803`77c83de8 fffff80f`4b81a4fc amdkmdag+0x1fba570
04 fffff803`77c83df0 ffffdf8f`e3510000 amdkmdag+0x1faa4fc
05 fffff803`77c83df8 000002db`6da82794 0xffffdf8f`e3510000
06 fffff803`77c83e00 ffffdf8f`e3510a08 0x000002db`6da82794
07 fffff803`77c83e08 fffff80f`4f49b3b8 0xffffdf8f`e3510a08
08 fffff803`77c83e10 fffff803`77c84601 amdkmdag+0x5c2b3b8
09 fffff803`77c83e18 ffffdf8f`d9d02fa0 0xfffff803`77c84601
0a fffff803`77c83e20 00000000`00000000 0xffffdf8f`d9d02fa0
In the stack trace above (which you read from the bottom up), you can see amdkmdag.sys called several times. It's also the final driver called prior to the page fault and bugcheck.
However, there are several apparent function calls in that stack for which we don't have symbols, and one of them (the 0x000002db`6da82794 function call) is a call to a user-mode address (it begins with 0x0000, whilst kernel-mode code addresses begin with 0-xFFFF). This is something that would never happen normally, the kernel never calls user-mode code directly, so something is seriously amiss with this call stack.
The second dump file (the 'as I was about to get off' dump) contains the clue that we need to see what's most likely going wrong here. The dump is a 0x1A, a MEMORY_MANAGEMENT bugcheck. The argument 1 value of 0x4179 indicates that a corrupt PTE (Page Table Entry) was encountered. A PTE is part of the page table structure that is used in translating virtual addresses into real RAM page addresses.
If we display the PTE in question we can see that it's clearly incomplete...
Code:
2: kd> !pte ffffc6bfff90ee18
VA 00007fff21dc3000
PXE at FFFFC6E371B8D7F8 PPE at FFFFC6E371AFFFE0 PDE at FFFFC6E35FFFC870 PTE at FFFFC6BFFF90EE18
Unable to get PXE FFFFC6E371AFFFE0
We see no details of what values the data areas contain, which we would expect to see in a valid PTE. We can see that the PTE is for a user-mode virtual address; 0x00007fff21dc3000, which is useful information. If we look at what was going on at the time via the call stack...
Code:
2: kd> knL
# Child-SP RetAddr Call Site
00 ffff9988`4f9feeb8 fffff806`7948124a nt!KeBugCheckEx
01 ffff9988`4f9feec0 fffff806`7942f7b6 nt!MiDeleteVa+0x153a
02 ffff9988`4f9fefc0 fffff806`7942f8cb nt!MiWalkPageTablesRecursively+0x776
03 ffff9988`4f9ff060 fffff806`7942f8cb nt!MiWalkPageTablesRecursively+0x88b
04 ffff9988`4f9ff100 fffff806`7942f8cb nt!MiWalkPageTablesRecursively+0x88b
05 ffff9988`4f9ff1a0 fffff806`7942c8cb nt!MiWalkPageTablesRecursively+0x88b
06 ffff9988`4f9ff240 fffff806`7947fae1 nt!MiWalkPageTables+0x36b
07 ffff9988`4f9ff340 fffff806`794407b0 nt!MiDeletePagablePteRange+0x4f1
08 ffff9988`4f9ff650 fffff806`798b07c9 nt!MiDeleteVad+0x360
09 ffff9988`4f9ff760 fffff806`7981f3c8 nt!MiUnmapVad+0x49
0a ffff9988`4f9ff790 fffff806`7981d83f nt!MiCleanVad+0x30
0b ffff9988`4f9ff7c0 fffff806`7989aa18 nt!MmCleanProcessAddressSpace+0x137
0c ffff9988`4f9ff840 fffff806`798aeb6e nt!PspRundownSingleProcess+0x20c
0d ffff9988`4f9ff8d0 fffff806`798817ee nt!PspExitThread+0x5f6
0e ffff9988`4f9ff9d0 fffff806`796105f5 nt!NtTerminateProcess+0xde
0f ffff9988`4f9ffa40 00007fff`2d64d3d4 nt!KiSystemServiceCopyEnd+0x25
10 0000001c`3e7ff618 00000000`00000000 0x00007fff`2d64d3d4
From the function calls we can see that a process had ended (nt!NtTerminateProcess) and we're cleaning up the memory and page tables that were used by that process. You can see the Vad (Virtual Address Space Descriptor) being deleted, and then the page tables are 'walked' clearing up all references to the now deleted address space. Finally there is an attempt to delete the address space itself (nt!MiDeleteVa) which causes the bugcheck - because of that corrupted PTE (which must be for the user-mode address space being deleted).
This is all pointing very strongly at a RAM problem, just as everything else suggests. I think we can be clear now and say with some certainty that there is a problem with your RAM, either in the RAM itself, in the RAM slots, in the motherboard memory controller, or even in the motherboard itself.
I can't remember the last time I saw a set of dumps that pointed more clearly at a RAM problem than these do.
Have you tried removing one RAM stick at a time as I suggested in
post#13?