You're using Nvidia drivers dated back to June 2012. See what you can do about updating those.
As for the crashes themselves, from the crashdumps I've looked at so far they all are rather identical except for one, which involved memory corruption during what appears to be an attempt to access a network-mounted directory/drive or some other network-shared resource. Make sure your network drivers are updated.
The rest of the crashes involve video-related operations in which your graphics driver was unable to continue performing the requested work because it lacked sufficient resources to do so. One can't dive more into this because minidumps don't harbor such information. For more data, you can turn on
Driver Verifier and let your system crash a couple more times after that and provide us the crashdumps, and you can also go ahead and upload
MEMORY.DMP from your Windows directory to a 3rd-party filesharing site for us to look at (they compress very well when archived). The kernel dump (
MEMORY.DMP file) only is from your latest crash, so keep that in mind (it's overwritten after every crash).
Analysts:
Code:
2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
VIDEO_TDR_FAILURE (116)
Attempt to reset the display driver and recover from timeout failed.
Arguments:
Arg1: 86574158, Optional pointer to internal TDR recovery context (TDR_RECOVERY_CONTEXT).
Arg2: 94cac27c, The pointer into responsible device driver module (e.g. owner tag).
Arg3: c000009a, Optional error code (NTSTATUS) of the last failed operation.
Arg4: 00000004, Optional internal context dependent data.
Debugging Details:
------------------
TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\triage\modclass.ini, error 2
FAULTING_IP:
nvlddmkm+8a127c
94cac27c 55 push ebp
DEFAULT_BUCKET_ID: GRAPHICS_DRIVER_TDR_FAULT
CUSTOMER_CRASH_COUNT: 1
BUGCHECK_STR: 0x116
PROCESS_NAME: System
CURRENT_IRQL: 0
STACK_TEXT:
97ccccb0 94f0107b 00000116 86574158 94cac27c nt!KeBugCheckEx+0x1e
97ccccd4 94ef9cf8 94cac27c c000009a 00000004 dxgkrnl!TdrBugcheckOnTimeout+0x8d
97cccd18 94efa15c 86574158 87e99008 97cccd3c dxgkrnl!DXGADAPTER::Reset+0xee
97cccd28 94f5a20b 86574158 87e99008 00000000 dxgkrnl!TdrResetFromTimeout+0x12
97cccd3c 94f5d485 87e99008 00000000 87ecfd48 dxgmms1!VidSchiRecoverFromTDR+0x15
97cccd50 839f64e6 87e99008 bc6843c1 00000000 dxgmms1!VidSchiWorkerThread+0x7f
97cccd90 83897989 94f5d406 87e99008 00000000 nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19
STACK_COMMAND: .bugcheck ; kb
FOLLOWUP_IP:
nvlddmkm+8a127c
94cac27c 55 push ebp
SYMBOL_NAME: nvlddmkm+8a127c
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nvlddmkm
IMAGE_NAME: nvlddmkm.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4fece158
FAILURE_BUCKET_ID: 0x116_IMAGE_nvlddmkm.sys
BUCKET_ID: 0x116_IMAGE_nvlddmkm.sys
Followup: MachineOwner
---------
2: kd> !error c000009a
Error code: (NTSTATUS) 0xc000009a (3221225626) - Insufficient system resources exist to complete the API.
I often see this from issues dealing with people running out of RAM entirely, or driver pool memory got filled up by a misbehaving driver. One can't check memory allocations using commands like
!memusage without at least a kernel dump.