Random BSOD in windows 7

[wmorri]

Hi all,

I just had a bsod out of the blue this evening. :huh:

I can give you a little bit about my system.
· OS - Windows 7
· x64 ?
· What was original installed OS on system? Window 7 x86
· Is the OS an OEM version (came pre-installed on system) or full retail version (YOU purchased it from retailer)? Full retail
· Age of system (hardware) give or take 3/4 years. Motherboard is less than 1 year old.
· Age of OS installation - have you re-installed the OS? 6 months or so

· CPU - Intel i5-2320 @ 3GHz
· Video Card - AMD Radeon HD 6670
· MotherBoard - ASRock Z75 Pro 3
· Power Supply - brand & wattage (if laptop, skip this one) 550 watt, brand name psu, I can look it up if you want.

· System Manufacturer - Made by me
· Exact model number (if laptop, check label on bottom)

· Laptop or Desktop? Desktop

I did a little looking into this problem first with Blue Screen View, and found that I had a bad driver in Virtualbox. I have updated that program to the latest version. I have a problem with the driver Wdf0100.sys,

I had a problem with atikmdag.sys. I followed the directions and unistalled the Catalyst Control Center.

I found a problem with ntoskrnl.exe. Not sure how to fix that one.

Lastly, I found a problem with dxgmms1.sys. A windows update problem.

Here are the files you asked for. View attachment Windows7_Vista_jcgriff2.zip View attachment prefmon.zip

Look forward to working with you all.

 

[Patrick]

Hi,

So we start off here -

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)

This indicates that a system thread generated an exception which the error handler did not catch.

BugCheck 1000007E, {[COLOR=#4b0082]ffffffff80000003[/COLOR], [COLOR=#ff0000]fffff8000308b9d0[/COLOR], fffff880009ed3f8, fffff880009ecc50}

The 1st argument exception that couldn't be handled by the handler was 80000003 (Break instruction exception). This indicates a hard-coded breakpoint or assertion was hit when no kernel debugger was connected and started with /nodebug. Very likely a driver bug and/or issue, which we can likely confirm by checking the beginning of the call stack:

3: kd> k
Child-SP          RetAddr           Call Site
fffff880`009ed638 fffff880`00f2d790 nt!DbgBreakPoint
fffff880`009ed640 fffff880`00f2b14d [COLOR=#ff0000]Wdf01000!_FX_DRIVER_GLOBALS::WaitForSignal+0x70[/COLOR] [COLOR=#4b0082]<- Here we can see we're waiting for a signal at the time of the bug check.[/COLOR]
fffff880`009ed680 fffff880`00f37a6c Wdf01000!FxIoQueue::StopProcessingForPower+0x1ed
fffff880`009ed6d0 fffff880`00f37f14 Wdf01000!FxPkgIo::StopProcessingForPower+0x22c
fffff880`009ed740 fffff880`00f37db5 Wdf01000!FxPkgPnp::PowerGotoDx+0x64
fffff880`009ed780 fffff880`00f2e0f8 Wdf01000!FxPkgPnp::PowerGotoDNotZero+0x9
fffff880`009ed7b0 fffff880`00f2dda6 Wdf01000!FxPkgPnp::PowerEnterNewState+0x1d8
fffff880`009ed910 fffff880`00f2e627 Wdf01000!FxPkgPnp::PowerProcessEventInner+0x13e
fffff880`009ed980 fffff880`00f38dd3 Wdf01000!FxPkgPnp::PowerProcessEvent+0x1b3
fffff880`009eda20 fffff880`00f1a6f2 Wdf01000!FxPkgFdo::DispatchDeviceSetPower+0x117
fffff880`009eda70 fffff880`00f1979a Wdf01000!FxPkgPnp::Dispatch+0x2aa
fffff880`009edad0 fffff880`00f19866 Wdf01000!FxDevice::Dispatch+0x19a
fffff880`009edb10 fffff800`031afeb5 Wdf01000!FxDevice::DispatchWithLock+0xa6 [COLOR=#4b0082]<- Dispatching IRP with a lock.[/COLOR]
fffff880`009edb50 fffff800`0332f73a nt!PopIrpWorker+0x3c5 [COLOR=#4b0082]<- The thread is specifically a Power Manager worker thread that will dispatch power IRP(s) to driver(s).[/COLOR]
fffff880`009edc00 fffff800`030848e6 nt!PspSystemThreadStartup+0x5a [COLOR=#4b0082]<- Starting the thread.[/COLOR]
fffff880`009edc40 00000000`00000000 nt!KxStartSystemThread+0x16 [COLOR=#4b0082]<- Beginning of a thread.[/COLOR]

Given the worker thread regarding IRPs, I suspect a deadlock. Thankfully however, you did all of the work and enabled DV:

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)

This is the general bug check code for fatal errors found by Driver Verifier.

BugCheck C4, {[COLOR=#ff0000]1003[/COLOR], fffff9803f658fc8, fffff98029016fc8, fffffa8013105cf0}

1st argument is 1003 which indicates two locks were released in reverse order of their acuqisition. This confirms my guess, we have a deadlock.

DRIVER_DEADLOCK: Deadlock detection not initialized

Although you didn't enable deadlock detection as a flag, we still have a helpful call stack in the end:

1: kd> k
Child-SP          RetAddr           Call Site
fffff880`08c623e8 fffff800`035064ec nt!KeBugCheckEx
fffff880`08c623f0 fffff800`035076d8 nt!VerifierBugCheckIfAppropriate+0x3c
fffff880`08c62430 fffff800`03513927 nt!ViDeadlockReportIssue+0x38
fffff880`08c62470 fffff800`03514a55 [COLOR=#006400]nt!VfDeadlockReleaseResource+0x257[/COLOR] [COLOR=#4b0082]<- Deadlock itself.[/COLOR]
fffff880`08c62530 fffff880`046e5a4f [COLOR=#0000cd]nt!VerifierExReleaseFastMutex+0x35[/COLOR] [COLOR=#4b0082]<- Address of the resource that is being released deadlocked.[/COLOR]
fffff880`08c62560 00000000`00000000 [COLOR=#ff0000]VBoxDrv+0x13a4f[/COLOR]

VirtualBox is our guilty driver that caused the deadlock.

Unsure if it's a bug within the driver, but that was the cause of the crash nonetheless.

Regards,

Patrick

 

[wmorri]

Hi Patrick,

So should I keep DV running in the background, and hopefully installing the new version of Virtualbox fixed it?

 

[Patrick]

Yeah, sure. Keep it running for 24 hrs or so and if you don't crash, disable it.

Regards,

Patrick