BlueRobot is right on the money. All crashdumps consistently mention the Nvidia driver, in that it attempted to perform an illegal operation. Given that the version of the Nvidia driver on the system is from Dec 28, 2012, and the newest version of the driver is from Jan 5, 2013, it is not like Nvidia to release an update so fast unless it was done to fix a critical bug, which this would certainly constitute as being one. Follow Bluerobot's instructions on uninstalling the driver completely and installing the latest version. That most likely will fix the problem.
@Dsprague:
For future reference, a crash can occur with a 0xC4 bugcheck even when Driver Verifier checks have not been manually set by the user. There are some DV checks implemented into Windows default environment that will trigger when a driver makes a boo-boo, like this one. It can be very disorienting but that's just how it is. A better method of determining if DV was actually active or not is to check the default bucket id:
Code:
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
Arguments:
Arg1: 0000000000000091, A driver switched stacks using a method that is not supported by
the operating system. The only supported way to extend a kernel
mode stack is by using KeExpandKernelStackAndCallout.
Arg2: 0000000000000002
Arg3: fffffa800c7d2850
Arg4: 0000000000000000
Debugging Details:
------------------
TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\triage\modclass.ini, error 2
BUGCHECK_STR: 0xc4_91
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: [COLOR=Green]WIN7_DRIVER_FAULT[/COLOR]
PROCESS_NAME: System
CURRENT_IRQL: 2
LAST_CONTROL_TRANSFER: from fffff80002ce380a to fffff80002c8cfc0
If DV checks were present, the bucket id would have "VERIFIER_ENABLED" in its name, otherwise, it will use the highlighted one or another generic ID. Another way to check is to type
!verifier in Windbg to see if DV was on and what checks were selected, however results will definitely vary on a minidump - it may or may not retain this data, so take it with a dash of salt. In this crashdump though we see that it did retain the data, but evidently the data shows - of course - that DV was not on:
Code:
0: kd> [COLOR=Blue]!verifier[/COLOR]
Verify Level 0 ... enabled options are:
Summary of All Verifier Statistics
RaiseIrqls 0x0
AcquireSpinLocks 0x0
Synch Executions 0x0
Trims 0x0
Pool Allocations Attempted 0x0
Pool Allocations Succeeded 0x0
Pool Allocations Succeeded SpecialPool 0x0
Pool Allocations With NO TAG 0x0
Pool Allocations Failed 0x0
Resource Allocations Failed Deliberately 0x0
Current paged pool allocations 0x0 for 00000000 bytes
Peak paged pool allocations 0x0 for 00000000 bytes
Current nonpaged pool allocations 0x0 for 00000000 bytes
Peak nonpaged pool allocations 0x0 for 00000000 bytes
rb: Type: Device Manager
