How to detect deadlocks in Win32 Multithreaded applications using Windbg
subbu
How to detect deadlocks in win32 multithreaded applications using windbg or
any of the available debuggin tools. My application is running in win 2000
and it is a multithreaded IVRS application which TAPI.
Upon debugging using kd and windbg, it showing deadlocks in winmm.dll. That
is the some of the winmm functions are not returning and hence the
application hangs.
any lead on this.
thanks
Subramanian V
Sr. Software Engineer
Speech and Software Technologies (I) Pvt. Ltd.,
3rd floor, Ceebros Arcade,
No.1, 3rd Cross Road,
Kasturibai Nagar, Adayar,
Chennai - 600020, India
Phone (Work):+91 44 2442 5370, +91 44 2442 5371
Fax (Work): +91 44 2442 5369
Email: su...@sstil.com
Visit us @ http://www.sstil.com
Ivan Brugiolo [MSFT]
Deadlocks are not an easy topic, in general.
If the deadlock is entirely confined inside your process,
and it is due to Critical Sections misuse, then the "!locks"
extension is normally able to give you an overview of the
owned critical sections and the thread involved in the deadlocks.
But, given the richness of Synchronization objects,
you can deadlock a process wih 2 events, or one event and one mutex,
(and on and on), with no good automatic way to detect the deadlock
(the "ownership" of an Event is something that belongs to the logic of the
application
and there is no such a concept of a thread owning an event).
You can have also the multi-process deadlock case,
where you create a chain of threads waitin each other and linked by one or
more
IPC mechanism (RPC over LPC, RPC over NamedPipes, native LPC ports).
The best example of this case is to perform a CoCreateInstance from the code
that initialzie
a NT Service without having set the running state in the Service Control
Manager.
You would be deadlocking Services.exe, RPCSS, and your service in one nice
shot.
Other example would be creating a thread from DllMain.
You would deadlock your process with the help of CSRSS.EXE
For your specific case, you would need to get stack traces of all the
threads involved
in all the processes involved.
Normally, by manual inspection and common sense,
you should be able to identify the loop (if any).
--
This posting is provided "As Is" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"subbu" <su...@sstil.com> wrote in message
news:#woCBatwCHA.2396@TK2MSFTNGP10...