Controls - Deadlock in CXTPAccessible ctor

Deadlock in CXTPAccessible ctor

Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Controls
Forum Description: Topics Related to Codejock Controls
URL: http://forum.codejock.com/forum_posts.asp?TID=14626
Printed Date: 24 April 2024 at 4:17pm
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com

Topic: Deadlock in CXTPAccessible ctor

Posted By: rdhd
Subject: Deadlock in CXTPAccessible ctor
Date 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 mailto:_ZwWiatForSingleObject@12 - _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.

Replies:

Posted By: znakeeye
Date 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/

Posted By: rdhd
Date 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.