How Do I Stop DPC Watchdog Violation Blue Screen?

I hope so too, for your sake! Please keep me updated.

Regards,

Patrick

Thank you very much kind sir for sticking through this and helping me out. I will get these drivers changed out sometime tomorrow after my classes are done. Hopefully that is the end of my DPC problems. If it is, it's just in time for the semi-finals and finals of an online tourney I'm in. =D

Thanks!

Alright, so we're going to go a bit deep here. I will do my best to explain everything as easy as I can without taking valuable information away.

-------------------

The Kernel is of the DPC_WATCHDOG_VIOLATION (133) bug check as we've seen.

This bug check indicates that the DPC watchdog executed, either because it detected a single long-running deferred procedure call (DPC), or because the system spent a prolonged time at an interrupt request level (IRQL) of DISPATCH_LEVEL or above.

First off, the DPC_WATCHDOG_VIOLATION bug check can be triggered in two ways. First, if a single DPC exceeds a specified number of ticks, the system will stop with 0x133 with parameter 1 of the bug check set to 0.  In this case, the system's time limit for single DPC will be in parameter 3, with the number of ticks taken by this DPC in parameter 2.

BugCheck 133, {0, 501, 500, 0}

^^ In this case, the 1st parameter = 0!

0: kd> .bugcheckBugcheck code 00000133Arguments 0000000000000000 0000000000000501 0000000000000500 0000000000000000

This specific DPC has run for 0x501 ticks, when the limit was 0x500.

In the case of a stop 0x133 with the first parameter set to 0, the call stack should contain the offending driver. Rather than running a kv as we usually do, let's go ahead and run knL:

1: kd> knL

 # Child-SP          RetAddr           Call Site

00 ffffd0002054de38 fffff8013f977f7c nt!KeBugCheckEx

01 ffffd0002054de40 fffff8013f85a81b nt! ?? ::FNODOBFM::`string'+0x13ddc

02 ffffd0002054ded0 fffff8013f9d93a3 nt!KiUpdateRunTime+0x57

03 ffffd0002054df10 fffff8013ff8df85 nt!KeClockInterruptNotify+0xe3

04 ffffd0002054df40 fffff8013f89c343 hal!HalpTimerClockIpiRoutine+0x15

05 ffffd0002054df70 fffff8013f95512a nt!KiCallInterruptServiceRoutine+0xa3

06 ffffd0002054dfb0 fffff8013f95550f nt!KiInterruptSubDispatchNoLockNoEtw+0xea

07 ffffd0002053ea10 fffff8013f83e9c4 nt!KiInterruptDispatchLBControl+0x11f

08 ffffd0002053eba0 fffff800002a04b9 nt!KxWaitForLockOwnerShip+0x34

09 ffffd0002053ebd0 fffff8013fe782c7 VerifierExt!KeAcquireInStackQueuedSpinLockAtDpcLevel_wrapper+0x121

0a ffffd0002053ec20 fffff80001af4189 nt!VerifierKeAcquireInStackQueuedSpinLockAtDpcLevel+0xc3

0b ffffd0002053ec60 fffff80001bb8974 igdkmd64!hybDriverEntry+0x6db9

0c ffffd0002053ed10 fffff80001ad82a3 igdkmd64!hybDriverEntry+0xcb5a4

0d ffffd0002053ed70 fffff80001ae2289 igdkmd64+0x492a3

0e ffffd0002053edb0 fffff80001b2b9f5 igdkmd64+0x53289

0f ffffd0002053eee0 fffff80001aa8400 igdkmd64!hybDriverEntry+0x3e625

10 ffffd0002053ef60 fffff8000162b137 igdkmd64+0x19400

11 ffffd0002053f130 fffff8000140c26b dxgkrnl!ADAPTER_DISPLAY_DdiSetVidPnSourceAddress+0x67

12 ffffd0002053f160 fffff8013f954932 dxgmms1!VidSchiExecuteMmIoFlipAtISR+0x2f

13 ffffd0002053f190 fffff8000162ac0f nt!KeSynchronizeExecution+0x42

14 ffffd0002053f1d0 fffff80001401961 dxgkrnl!DpSynchronizeExecution+0xaf

15 ffffd0002053f220 fffff80001402cc9 dxgmms1!VidSchiExecuteMmIoFlip+0x241

16 ffffd0002053f5d0 fffff8000140574e dxgmms1!VidSchUnwaitFlipQueue+0x219

17 ffffd0002053f630 fffff80001404933 dxgmms1!VidSchiProcessDpcCompletedPacket+0x62e

18 ffffd0002053f740 fffff80001404804 dxgmms1!VidSchiProcessDpcDmaPacket+0xb3

19 ffffd0002053f790 fffff8000162ae6b dxgmms1!VidSchDdiNotifyDpc+0xf4

1a ffffd0002053f7e0 fffff80001ba6a65 dxgkrnl!DxgNotifyDpcCB+0x6b

1b ffffd0002053f890 fffff80001b54a97 igdkmd64!hybDriverEntry+0xb9695

1c ffffd0002053f8c0 fffff80001abe680 igdkmd64!hybDriverEntry+0x676c7

1d ffffd0002053f920 fffff8000162b09b igdkmd64+0x2f680

1e ffffd0002053f950 fffff8013f860d10 dxgkrnl!DpiFdoDpcForIsr+0x3b

1f ffffd0002053f9a0 fffff8013f8609f0 nt!KiExecuteAllDpcs+0x1b0

20 ffffd0002053faf0 fffff8013f9577ea nt!KiRetireDpcList+0xd0

21 ffffd0002053fc60 0000000000000000 nt!KiIdleLoop+0x5a

k = Displays the call stack of the given thread.

n = Displays frame numbers.

L (important you capitalize it) = Hides source lines in the display.

This makes a nice, neat, and informative call stack for 0x133 debugging.

-------------------

As we can see in the above call stack, we have plenty of things going on. To quickly break it down, we have a few Direct X Kernel/MMS routines (dxgkrnl & dxgmms1), and various igdkmd64.sys calls (Intel Graphics driver).

We can see that igdkmd64.sys called into KeAcquireInStackQueuedSpinLockAtDpcLevel. KeAcquireInStackQueuedSpinLockAtDpcLevel acquires a queued spin lock when the caller is already running at IRQL >= DISPATCH_LEVEL.

If it was NOT at DISPATCH_LEVEL, it'd be calling into KeAcquireInStackQueuedSpinLock instead, which RAISES it to DISPATCH_LEVEL.

So, with this said, the summary so far is that we're already at DISPATCH_LEVEL at the time of this call from the Intel Graphics driver. The Intel Graphics Driver then uses KeAcquireInStackQueuedSpinLock to acquire the queued spin lock, which is SUPPOSED TO BE FOLLOWED BY KeReleaseInStackQueuedSpinLockto release it AS SOON AS POSSIBLE. What's the problem? Well, it never released. Because of this, a deadlock occurred, and the system bugchecked. I'd like to say a big thank-you to Driver Verifier for catching all of this in action :O)

-- Also, a little trivia while we're on this topic if you're interested! Up until Windows 8/8.1, when a DPC issue happened like this, the system didn't actually crash, it just hung either forever, or until whatever was causing the deadlock actually got around to finishing its original job. Before Windows 8/8.1, if your system hung like this due to a DPC deadlock, etc, you could force a bugcheck with the keyboard (0xE2 bugcheck) to safely bring down the system. The Windows dev's then went ahead and said "Well, this isn't a very good situation on tablets, because you cannot perform said forced-keyboard crash to safely bring down the device". They ended up creating the 0x133 bugcheck which calls nt!KeBugCheckEx if a DPC takes (x) amount of time longer than it's supposed to, or if TWO DPC's take (x) longer than they're supposed to in a certain amount of time, etc.

Could you just shut down the device/system? Sure. Does this mean possible data loss? Yes, and that was the problem, and that's why the bugcheck was developed (thanks tablets)!

---------------------

Ensure you have the latest video card drivers via the manufacturers website (not Device Manager or Windows Update). If you are already on the latest video card drivers, uninstall and install a version or a few versions behind the latest to ensure it's not a latest driver only issue. If you have already experimented with the latest video card driver and many previous versions, please give the beta driver for your card a try.

In your case, you'd want to check Hewlett-Packard's website - http://www8.hp.com/us/en/support.html

You can also try Intel's drivers directly if HP's are a no-go - http://www.intel.com/p/en_US/support/detect

Regards,

Patrick

OK, here is the link to the skydrive

https://onedrive.live.com/redir?resid=860CC7F682A271F0%21782

#3, correct.

Regards,

Patrick