Try starting with “!analyze -hang” - that will show you a certain class
of problems. From there, you can use “!stacks” or “!process 0 7” to get
summary or complete information on each thread. If the thread is
blocked, you’ll see on what it is blocking and can work back from there.
Other possibilities include trying to perform certain operations at APC
level (try “!apc”) or work queue deadlocks (try “!exqueue”).
If you really are looking for outstanding IRPs, us “!irpfind” to locate
them all - but that’s slow over a serial connection.
If you know the specific app that’s hung, try “!process 0 0” to get a
list of processes and then choose the one that represents a known hung
application and do "!process
7" - that will cut down on the
relative verbosity of the information ("!process 0 7" can be
intimidating the first time you do that - typical systems these days
have hundreds of threads.)
Generally, hangs are one of the easiest class of problems to track down,
since the system is excellent at keeping track of the dispatcher objects
on which each thread is waiting. Those dispatcher objects in turn often
have ownership information - which leads from the waiting thread to the
owning thread. The owning thread then is likely waiting for something.
Typically you find a loop in owning/waiting that establishes the
deadlock. If, however, the threads are using synchronization events
(KEVENT) or other dispatcher objects that do not have ownership
information you'll have to do quite a lot more digging to figure it out.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
________________________________
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Zed y
Sent: Tuesday, June 20, 2006 6:23 AM
To: ntdev redirect
Subject: [ntdev] HELP: How to debug "stuck IRPS" in TDI filter
Hi
Our product contains TDI filter and File system filter driver.
Lately, several applications began to stuck with no known reason. I
think that one of our filters causes some of the IRPS to "get stuck" so
the user mode process isn't getting a response to its request and it
gets stuck too.
These are the symptoms:
-Two computers that sometimes have their telnet application stuck when
it tries to disconnect.
-One computer had it's excel stuck. I don't know if excel is creating
some kind of communication so I don't know if the problem is in the TDI
or the file system filter.
-One computer that runs AutoIt (a QA helper app). The AutoIt got stuck
and afterwards all iexplore, msnm, and outlook got stuck (the
application window is freeze after I run it). The wired thing is, that
mozilla firefox runs OK!
All the problems occurred after SEVERAL DAYS of work while our product
was running.
Because most of the problems were in communications apps, we think it's
the TDI filter.
Any idea how to debug such a problem?
Is there a way to get all the stuck IRPS for a process or a driver?
(Maybe doing a manual dump and get it from there?)
Thanks for any help.
--- Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer