Random BSOD in windows 7

wmorri · Aug 28, 2014

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 · Aug 28, 2014

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.

Code:

BugCheck 1000007E, {ffffffff80000003, fffff8000308b9d0, 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:

Code:

3: kd> k
Child-SP          RetAddr           Call Site
fffff880`009ed638 fffff880`00f2d790 nt!DbgBreakPoint
fffff880`009ed640 fffff880`00f2b14d Wdf01000!_FX_DRIVER_GLOBALS::WaitForSignal+0x70 <- Here we can see we're waiting for a signal at the time of the bug check.
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 <- Dispatching IRP with a lock.
fffff880`009edb50 fffff800`0332f73a nt!PopIrpWorker+0x3c5 <- The thread is specifically a Power Manager worker thread that will dispatch power IRP(s) to driver(s).
fffff880`009edc00 fffff800`030848e6 nt!PspSystemThreadStartup+0x5a <- Starting the thread.
fffff880`009edc40 00000000`00000000 nt!KxStartSystemThread+0x16 <- Beginning of a thread.

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.

Code:

BugCheck C4, {1003, 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.

Code:

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:

Code:

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 nt!VfDeadlockReleaseResource+0x257 <- Deadlock itself.
fffff880`08c62530 fffff880`046e5a4f nt!VerifierExReleaseFastMutex+0x35 <- Address of the resource that is being released deadlocked.
fffff880`08c62560 00000000`00000000 VBoxDrv+0x13a4f

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 · Aug 29, 2014

Hi Patrick,

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

Patrick · Aug 29, 2014

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

Regards,

Patrick

Search

Search

Random BSOD in windows 7

wmorri

Visiting Expert, Sysnative Administrator Emeritus

Patrick

Sysnative Staff

wmorri

Visiting Expert, Sysnative Administrator Emeritus

Patrick

Sysnative Staff