Deadlock in CXTPAccessible ctor

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

When starting our app in debug mode we sometimes hang up while we are initializing the command ribbon. The call stack shows the main thread is suspended by a _ZwWiatForSingleObject@12() call. The immediate cause of the hangup is the CXTPAccessible ctor making a call to Init user32.dll.

CXTPAccessible::CXTPAccessible()
{
    m_modUser32.Init(_T("user32.dll"));

The modules window shows me user32.dll has been loaded (symbols are not loaded). I have no reports of this occurring in release builds. Has any one else seen this behavior? Restarting debug is our only way out of this.

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
rdhd Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 886	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Topic: Deadlock in CXTPAccessible ctor Posted: 26 June 2009 at 9:18am
	When starting our app in debug mode we sometimes hang up while we are initializing the command ribbon. The call stack shows the main thread is suspended by a _ZwWiatForSingleObject@12() call. The immediate cause of the hangup is the CXTPAccessible ctor making a call to Init user32.dll. CXTPAccessible::CXTPAccessible() { m_modUser32.Init(_T("user32.dll")); The modules window shows me user32.dll has been loaded (symbols are not loaded). I have no reports of this occurring in release builds. Has any one else seen this behavior? Restarting debug is our only way out of this.

znakeeye Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 26 July 2006 Status: Offline Points: 1672	Post Options Post Reply Quote znakeeye Report Post Thanks(0) Quote Reply Posted: 26 June 2009 at 10:12am
	Does this happen when you perform the typical "stop debugging, start debugging" operation? E.g. Shift+F5, F5.
	PokerMemento - http://www.pokermemento.com/

rdhd Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 886	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Posted: 26 June 2009 at 5:38pm
	I usually do start debugging and stop debugging that via the keyboard. This has just started fairly recently, probably in the last few weeks. The lockup can occur right away as we build our first ribbon or when I open our first document and we build the ribbon for that document (MDI app). Since the DLL is already loaded (according to the modules window), I am not sure what would cause the lockup. There is a way DLL loading can cause deadlock (usually during thread/process attach by referencing another DLL) but I don't believe that is what is going on. I know that one can also deadlock waiting on symbol files to load if one loads the MS symbols on demand and after performing the first load on demand a call to load a web page into an app occurs using the IE web browser control's LoadPage API. That only happens in debug and the explorer browser control and Visual Studio debugger both can end up waiting on a network related critical section (or some synchronization object). I contacted MS about that last year and the only resolution is to wait until after the page loads to manually load the user32.dll symbols. When I look at the threads, I do not see the same routine on the stack that indicates the process is waiting on the network CS so I rule that out too.