wmorri Visiting Expert, Sysnative Administrator Emeritus Joined Apr 2, 2012 Posts 183 Aug 28, 2014 #1 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.
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.
P Patrick Sysnative Staff Joined Jun 7, 2012 Posts 4,618 Aug 28, 2014 #2 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 Last edited: 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 Visiting Expert, Sysnative Administrator Emeritus Joined Apr 2, 2012 Posts 183 Aug 29, 2014 #3 Hi Patrick, So should I keep DV running in the background, and hopefully installing the new version of Virtualbox fixed it?
Hi Patrick, So should I keep DV running in the background, and hopefully installing the new version of Virtualbox fixed it?
P Patrick Sysnative Staff Joined Jun 7, 2012 Posts 4,618 Aug 29, 2014 #4 Yeah, sure. Keep it running for 24 hrs or so and if you don't crash, disable it. Regards, Patrick