Investigating the XInitThreads deadlock bug

Eric Pouech pouech-eric at
Thu Feb 5 14:34:15 CST 2004

> I also added some display commands to show you the details of the critical
> section in question. Now, if you look at what the display says you'll
> notice something odd: at first crit = 0x0011d1e0, but then it switches to
> 0x403112b8. And this is without any breakpoints having been set up within
> RtlEnterCriticalSection! So it can't be a context switch - it seems like a
> bug in the debugger. Or is this intentional in some way?
it's not really intentional. However, the first asm insn of any 
functions (the prolog) are used to set up the frame for the function (ie 
the way to look at local vars...)
in the first two instructions, the function's frame is not properly set 
up, however, winedbg believes that it's set up and use the current 
information to look at local & passed variable (while the current frame 
is still the one from the caller).
in general this is not problematic, it may be trickier when using 
conditional breakpoints on passed variables (where you'll never get the 
correct information).
Setting the bp after the prolog (as you did) is the right solution.


More information about the wine-devel mailing list