Windows 7: BSOD after waking up from sleep new build 0x000000C4

gletob · 14 Jan 2013

I've just built my new computer, and since building it I've found it either awake in the morning after putting it to sleep and going to bed, or asleep but with nothing open that I had left open. Today, I came home, woke the computer up, and actually saw the BSOD this time. Trying to figure out what's causing this.

I've attached the ZIP file from the "SF Diag Tool".

Any help is much appreciated.

Dsprague · 14 Jan 2013

It looks like you have Driver Verifier enabled

Code:

*******************************************************************************
*                                                                             *
*                        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: fffffa800d253780
Arg4: 0000000000000000

Debugging Details:
------------------

Follow option two in this tutorial to disable it:

Driver Verifier - Enable and Disable

**x BlueRobot** · 14 Jan 2013

Code:

BugCheck C4, {91, 2, fffffa800d253780, 0}

*** WARNING: Unable to verify timestamp for nvlddmkm.sys
*** ERROR: Module load completed but symbols could not be loaded for nvlddmkm.sys
Probably caused by : nvlddmkm.sys ( nvlddmkm+1b7221 )

Update:

Code:

0: kd> lmvm nvlddmkm
start             end                 module name
fffff880`05a2e000 fffff880`064cc000   nvlddmkm T (no symbols)           
    Loaded symbol image file: nvlddmkm.sys
    Image path: \SystemRoot\system32\DRIVERS\nvlddmkm.sys
    Image name: nvlddmkm.sys
    Timestamp:        Sat Dec 29 06:47:52 2012 (50DE9218)
    CheckSum:         00A7F96C
    ImageSize:        00A9E000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

Download Driver
Start Type: Device Manager
Expand Display Adapters
Right-Click Driver Name, Uninstall
Reboot
Run Driver Sweeper
Reboot
Install Downloaded Driver

Driver Sweeper will scan for any left over files from the old driver, old driver files can cause conflicts with new driver installations. Create a System Restore point beforehand, in case any problems or issues arise.

Driver Sweeper:

Drivers - Clean Left over Files after Uninstalling

The latest driver is dated as the 5th January 2013:

Latest NVIDIA ForceWare Video Drivers Windows 7

Reduce the number of programs at startup, to avoid any driver or program conflicts:

Troubleshoot Application Conflicts by Performing a Clean Startup

Install and perform full scans with:

Remember to install the free version of Malwarebytes not the free trail; untick the free trial box during installation. MSE is the most lightweight and compatible with the Windows 7 operating system.

You can also view this thread for a complete free and lightweight security protection combination:

Good and Free system security combination.

Vir Gnarus · 14 Jan 2013

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:  WIN7_DRIVER_FAULT

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> !verifier

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

gletob · 14 Jan 2013

I've followed BlueRobot's suggestion and we will see If I have any more issues now. Hopefully that should clear it up. Thanks everyone!

Dsprague · 14 Jan 2013

Quote: Originally Posted by Vir Gnarus

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:  WIN7_DRIVER_FAULT

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> !verifier

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

Thank you for the Information

Windows 7: BSOD after waking up from sleep new build 0x000000C4

BSOD after waking up from sleep new build 0x000000C4 problems?