Violation bugcheck (c4) and a deadlock

Patrick

Sysnative Staff
Joined
Jun 7, 2012
Posts
4,618
Alright, so over on answers, a user posted their DMP files for analysis. They were 9F bugchecks, however, rather than being due to an inconsistent power state, it says as follows:

A driver has failed to complete a power IRP within a specific time (usually 10 minutes).

No blocked IRP so cannot run an !irp, instead we have:

Code:
Arg1: 0000000000000004, The power transition timed out waiting to synchronize with the Pnp
    subsystem.
Arg2: 000000000000012c, Timeout in seconds.
Arg3: fffffa800e2f5040, The thread currently holding on to the Pnp lock.
Arg4: fffff80384245810, nt!TRIAGE_9F_PNP on Win7

Both 9F's here in case anyone wants - https://skydrive.live.com/redir?resid=DED77542B4FC4992!131&authkey=!AE1GKB2_klB57L0

So, since I am personally not sure what to do here (and I hope someone can explain what you would do) I instructed the user to enable verifier. After enabling verifier, they did not crash until shutting the system down, and it took exactly 10 minutes to do so before a crash happened and the DMP was generated.

The verifier dump is a violation bugcheck (c4), however, it's ntkrnlmp.exe and here are the arguments:

here is the dump - https://skydrive.live.com/redir?resid=DED77542B4FC4992!133&authkey=!AOOFdkuLlPxa-6k

Code:
Arg1: 0000000000000115, System didn't finish shutting down in a long time.
Arg2: fffffa80113cd880, The address of the thread responsible for the shutdown, that might be deadlocked.
Arg3: 0000000000000000
Arg4: 0000000000000000

I am assuming arg1 corresponds with what was said earlier in the 9F -
A driver has failed to complete a power IRP within a specific time (usually 10 minutes).

However, arg2, I am not sure what that means. That's new terminology for me, and I don't think I am that far into Windows Internals yet :tongue10:

So, just experimenting, I tried running a !locks and got the following:

Code:
0: kd> !locks
**** DUMP OF ALL RESOURCE OBJECTS ****
fffff8039d50ba30: Unable to get value of ExpSystemResourcesList

???? Do we need a kernel dump for things like locks?

I then ran a !poaction to try and get some info on what drivers have power IRPs pending:

Code:
0: kd> !poaction
Error reading PopAction

Allocated power irps (PopIrpList - fffff8039d513900)
Error resolving nt!_LIST_ENTRY...

Irp worker threads (PopIrpThreadList - fffff8039d512f60)
Error resolving nt!_LIST_ENTRY...

Error resolving nt!_POP_CURRENT_BROADCAST...

Not too sure what this means~

I tried running a !deadlock:

Code:
0: kd> !deadlock
Deadlock detection not initialized

I assume this is one of the verifier settings we can tell the user to check before initializing verifier?

Overall, any guidance or teaching in regards to what I am looking at or trying to deal with here would be more than appreciated.

Finally, here's the thread just in case any want to pop in and read what the OP has stated for info - DRIVER_POWER_STATE_FAILURE (9f) - Microsoft Community
 
Last edited:
Here's an explanation for a deadlock - Debugging a Deadlock (Windows Debuggers)

You will also most likely need a Kernel Memory dump too.

A deadlock is when a thread has locked a resource, but then needs another resource to continue processing, the resource it needs is locked by a different thread, which needs the resource held by the other thread. Basically, the two threads are going to be waiting for each other forever.

I was planning to look at locks today, so I'll post an update if I find anything which may be helpful, but I'm sure the others will already know more about deadlocks etc.
 
From the very bottom of the article that x BlueRobot posted:
When a deadlock occurs in kernel mode, use the !kdexts.locks extension to list all the locks currently acquired by threads.

You can usually pinpoint the deadlock by finding one non-executing thread that holds an exclusive lock on a resource that is required by an executing thread. Most of the locks are shared.
 
Welcome Patrick, and I haven't had the chance to come across a deadlock yet, should I be wanting to? ;)
 
If you happen to come across one, that would be fantastic. I will take care of the current lock thread I am in on answers when I get home from classes.
 
Patrick, I have a user on SevenForums who claims to have a deadlock, I've requested for Driver Verifier, and will post back if I find anything :D
 
Oooh, interesting! Have fun : )

Let me know if the DV flags anything. Has the user attached a kernel dump yet or was it a minidump?

Also, after I instructed the ms answers OP to enable Kernel dumps for more info, apparently he/she had windbg installed, and analyzed their kernel. It ended up being excsd.sys which is the Diskeeper Corporation driver. Once it was removed, the crashes were solved.
 
Good Work :thumbsup2:

The OP did originally have a issue with their gaming mouse driver in a previous thread which was solved by another BSOD Analyst, but at the moment, I haven't had any feedback from the user.
 
Okay, I've solved the thread I mentioned, it was the Xbox 360 Wireless Controller driver.

For the Stop 0x9F with the first parameter being 4, I used the !thread extension parameter 3, and then checked the objects the thread was waiting for, and then decided to check the dump the raw stack for that thread.

I know it's a little late ;)
 
Neat, good work. Did it end up being the official X360 driver, or was it the 3rd party MijXfilt.sys?
 
I'm a lil late to this, but reckoned I'd add to it. Figuring out deadlocks can be quite difficult since it involves actually discovering the resource being contended on and then figuring out who started the loop. When searching for deadlocks, I would often do !locks then find locks most suspect (those with more than one owner and being contended over) and then draw a flowchart to visualize the relationship between the owners to see where there's a loop. An example of such is done here.

The Driver Verifier deadlock detection engine isn't all that robust and comprehensive. There's a good number of times where deadlocks have slipped past it without it batting an eye. I believe the Windows 8 DV has improved in this sense, but it's still not entirely possible to find any and all deadlock scenarios, given the complexity of deadlocking and the fact that in the case of deadlocking the system is too unstabled (e.g. frozen) for it to respond to a deadlock that's already occurred. That's why the deadlock detection in DV works by detecting scenarios it believes will end up as a deadlock, even though one has not yet occurred, much like any other check it does which is done in a proactive rather than reactive manner.

Also realize that there's more to deadlocks than just getting in a resource contention loop like fighting over a mutex. This is an example of a bit more complicated deadlock that involves the worker queue. Due to the asynchronous nature of things, deadlocks can manifest in various and sundry ways on a system. Locking resources like semaphores, mutexes, etc., are all there to prevent these situations, but when abused they too can cause deadlocks, but even outside them there are other areas of the kernel - like the worker queue - that can deadlock when abused. Always be aware of this, because sometimes you may have to go above and beyond the ole !locks extension in Windbg to find the cause.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top