Deadlock identification strategy...

Hi all - I am maintaining/porting our network provider and file system
redirector code. I am new to kernel development. We have run into
relatively few problems getting things to run on Windows 2000 and I have
successfully used Windbg to track down those problems. Recently, however,
we discovered that the Windows 2000 “move” command (either command-line or
from Explorer) causes a failure in the redirector. The problem, to my
inexperienced eyes, appears to be a resource contention (thread deadlock)
problem.

What is the general procedure for identifying the hung thread and the
resource for which it is waiting?

Several people have suggested that I need Softice to deal with this
problem. The reason cited is that Softice gives a better view of all the
threads running and allows better inspection of said threads. Can someone
shed some light here (I haven’t run Softice but could obtain a copy if it
made sense)?

Thanks for your help.

Kjell

Kjell,

Perhaps some people find that SoftICE/NT is simpler to use for debugging
deadlocks, but I’ve never had any problems debugging deadlocks using WinDBG.
My normal technique is to start by finding the thread that is hung (look for
the cmd.exe process in your case.) Then, figure out on what it is hanging.
When you know WHAT it is, you then can search and figure out which OTHER
thread owns that lock, and then you can find out for what THAT thread is
waiting.

If the threads are using ERESOURCES, you can use the “!locks” command to
short-circuit this processing considerably. If the threads are using
KEVENTs for synchronization it can be essentially impossible to find out who
“owns” the KEVENT. The “!thread” command will display addresses (and type
info) for all of the objects on which a thread is blocking, so you can use
that and combine it with the “!kdex2x86.strct” command to display
information about the innards of the various synchronization details.

These commands (“!process”, “!thread”, “!locks”) all work with SoftICE/NT,
or at least so I’ve been told. Perhaps SoftICE/NT has some additional
mechanisms for finding deadlocks as well, but someone else will need to
speak to that issue.

Besides, you can always use both debuggers (at least, that USED to work.
I’m assuming it still does.) Why use just one debugger when you can have
two? :slight_smile:

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@wrq.com [mailto:xxxxx@wrq.com]
Sent: Tuesday, June 27, 2000 12:24 PM
To: File Systems Developers
Subject: [ntfsd] Deadlock identification strategy…

Hi all - I am maintaining/porting our network provider and file system
redirector code. I am new to kernel development. We have run into
relatively few problems getting things to run on Windows 2000 and I have
successfully used Windbg to track down those problems. Recently, however,
we discovered that the Windows 2000 “move” command (either command-line or
from Explorer) causes a failure in the redirector. The problem, to my
inexperienced eyes, appears to be a resource contention (thread deadlock)
problem.

What is the general procedure for identifying the hung thread and the
resource for which it is waiting?

Several people have suggested that I need Softice to deal with this
problem. The reason cited is that Softice gives a better view of all the
threads running and allows better inspection of said threads. Can someone
shed some light here (I haven’t run Softice but could obtain a copy if it
made sense)?

Thanks for your help.

Kjell


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

> What is the general procedure for identifying the hung thread and the

resource for which it is waiting?

Look at the thread’s stack in WinDbg - this will discover - what of the
waiting routines was called, from where, and what was the lock in question.

Max