This case looks driver related rather than a failing GPU.
Code:
BugCheck 116, {fffffa80113914e0, fffff8800fa71e2c, ffffffffc000009a, 4}
You're having 0x116 bugchecks which indicate an attempt to reset the display driver within the allocated time interval failed.
This is mostly caused by either the display driver not responding or the graphics card is locking up as its failing.
This case looks more like a bad driver as the third parameter (ffffffffc000009a) indicates there were insufficient resources to complete the API, this is normally caused by display drivers causing memory leakage.
Code:
7: kd> lm vm nvlddmkm
start end module name
fffff880`0f0b6000 fffff880`0fd0e000 nvlddmkm T (no symbols)
Loaded symbol image file: nvlddmkm.sys
Image path: \SystemRoot\system32\DRIVERS\nvlddmkm.sys
Image name: nvlddmkm.sys
Timestamp: Tue Mar 04 11:07:52 2014 (5315B408)
CheckSum: 00C20523
ImageSize: 00C58000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
I would roll back your driver version, the most stable version is 314.22, can you acquire that driver?
If not then try 320.xx and work your way upwards seeing if driver changes increase/decreases the frequency of the bugchecks.
Here's my analysis on what the situation looks like.
Code:
7: kd> u fffff8800fa71e2c L20
nvlddmkm+0x9bbe2c:
fffff880`0fa71e2c 803db68aeeff00 cmp byte ptr [nvlddmkm+0x8a48e9 (fffff880`0f95a8e9)],0 <--
Looks like a compare instruction didn't meet the requirements.
fffff880`0fa71e33 741e je nvlddmkm+0x9bbe53 (fffff880`0fa71e53) <-- jump if equal
fffff880`0fa71e35 4885c9 test rcx,rcx
fffff880`0fa71e38 7412 je nvlddmkm+0x9bbe4c (fffff880`0fa71e4c)
fffff880`0fa71e3a 8179084144564e cmp dword ptr [rcx+8],4E564441h
fffff880`0fa71e41 7509 jne nvlddmkm+0x9bbe4c (fffff880`0fa71e4c)
fffff880`0fa71e43 81790c52564534 cmp dword ptr [rcx+0Ch],34455652h
fffff880`0fa71e4a 7407 je nvlddmkm+0x9bbe53 (fffff880`0fa71e53)
fffff880`0fa71e4c 48ff256d8eeeff jmp qword ptr [nvlddmkm+0x8a4cc0 (fffff880`0f95acc0)]
fffff880`0fa71e53 48ff259e8beeff jmp qword ptr [nvlddmkm+0x8a49f8 (fffff880`0f95a9f8)]
fffff880`0fa71e5a cc int 3
fffff880`0fa71e5b cc int 3
fffff880`0fa71e5c 803d868aeeff00 cmp byte ptr [nvlddmkm+0x8a48e9 (fffff880`0f95a8e9)],0
fffff880`0fa71e63 741e je nvlddmkm+0x9bbe83 (fffff880`0fa71e83)
fffff880`0fa71e65 4885c9 test rcx,rcx
fffff880`0fa71e68 7412 je nvlddmkm+0x9bbe7c (fffff880`0fa71e7c)
fffff880`0fa71e6a 8179084144564e cmp dword ptr [rcx+8],4E564441h
fffff880`0fa71e71 7509 jne nvlddmkm+0x9bbe7c (fffff880`0fa71e7c)
fffff880`0fa71e73 81790c52564534 cmp dword ptr [rcx+0Ch],34455652h
fffff880`0fa71e7a 7407 je nvlddmkm+0x9bbe83 (fffff880`0fa71e83)
fffff880`0fa71e7c 48ff251d8eeeff jmp qword ptr [nvlddmkm+0x8a4ca0 (fffff880`0f95aca0)]
fffff880`0fa71e83 48ff254e8beeff jmp qword ptr [nvlddmkm+0x8a49d8 (fffff880`0f95a9d8)]
fffff880`0fa71e8a cc int 3
fffff880`0fa71e8b cc int 3
fffff880`0fa71e8c 803d568aeeff00 cmp byte ptr [nvlddmkm+0x8a48e9 (fffff880`0f95a8e9)],0
fffff880`0fa71e93 741e je nvlddmkm+0x9bbeb3 (fffff880`0fa71eb3)
fffff880`0fa71e95 4885c9 test rcx,rcx
fffff880`0fa71e98 7412 je nvlddmkm+0x9bbeac (fffff880`0fa71eac)
fffff880`0fa71e9a 8179084144564e cmp dword ptr [rcx+8],4E564441h
fffff880`0fa71ea1 7509 jne nvlddmkm+0x9bbeac (fffff880`0fa71eac)
fffff880`0fa71ea3 81790c52564534 cmp dword ptr [rcx+0Ch],34455652h
fffff880`0fa71eaa 7407 je nvlddmkm+0x9bbeb3 (fffff880`0fa71eb3)
Code:
7: kd> dq nvlddmkm+0x8a48e9
fffff880`0f95a8e9 ????????`???????? ????????`????????
fffff880`0f95a8f9 ????????`???????? ????????`????????
fffff880`0f95a909 ????????`???????? ????????`????????
fffff880`0f95a919 ????????`???????? ????????`????????
fffff880`0f95a929 ????????`???????? ????????`????????
fffff880`0f95a939 ????????`???????? ????????`????????
fffff880`0f95a949 ????????`???????? ????????`????????
fffff880`0f95a959 ????????`???????? ????????`????????
We can't do much more given all this isn't available to minidumps so Kernel memory dumps are needed.
All the information is either saved in a context switch or not recorded in the minidumps, probably the second reason.