Codejock Forums Homepage
Forum Home Forum Home > Codejock Products > Visual C++ MFC > Controls
  New Posts New Posts RSS Feed - Deadlock in CXTPAccessible ctor
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

Deadlock in CXTPAccessible ctor

 Post Reply Post Reply
Author
Message
rdhd View Drop Down
Senior Member
Senior Member
Avatar

Joined: 13 August 2007
Location: United States
Status: Offline
Points: 605
Post Options Post Options   Thanks (0) Thanks(0)   Quote rdhd Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
znakeeye View Drop Down
Senior Member
Senior Member
Avatar

Joined: 26 July 2006
Status: Offline
Points: 1672
Post Options Post Options   Thanks (0) Thanks(0)   Quote znakeeye Quote  Post ReplyReply Direct Link To This Post 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/
Back to Top
rdhd View Drop Down
Senior Member
Senior Member
Avatar

Joined: 13 August 2007
Location: United States
Status: Offline
Points: 605
Post Options Post Options   Thanks (0) Thanks(0)   Quote rdhd Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down



This page was generated in 0.078 seconds.