right, but looking inside the CRITICAL_SECTION which the thread blocked on, you can get the tid of the thread which holds the cs (OwningThread field IIRC). A+
> Message du 12/06/03 10:31 > De : Mike Hearn <[EMAIL PROTECTED]> > A : [EMAIL PROTECTED] > Copie � : > Objet : Re: Discovering which critical sections threads are in > On Wed, 11 Jun 2003 22:31:39 +0200, Sir Eric Pouech scribed thus: > > normally there's a message printed out when a critsect times out like: > > section 0x12345678 myCS wait timed out, retrying (60 sec) tid=xxxx > > and the tid gives you the thread id of the thread holding the cs > > then, you can use it for example in 'bt <tid>' to get a backtrace of > > that particular thread and look at what it's doing > > Yup, sure, I know how to do that. But the backtrace tells you which thread > blocked, and where it was when it blocked. It doesn't tell you which > thread is already inside it (so you can go find out why it never left). > > In the end yesterday I just stuck some trace statements in and used emacs > to process the resulting huge file :) i feel there should be a better way > though.... maybe having a linked list of RTL_CRITICAL_SECTION structs that > the debugger can walk. > > >
