Codejock Developer Community : Deadlock in CXTPAccessible ctor

Codejock Developer Community : Deadlock in CXTPAccessible ctor http://forum.codejock.com/ Copyright (c) 2006-2013 Web Wiz Forums - All Rights Reserved. Wed, 13 May 2026 02:46:32 +0000 Fri, 26 Jun 2009 17:38:13 +0000 http://blogs.law.harvard.edu/tech/rss Web Wiz Forums 12.04 360 forum.codejock.com/RSS_post_feed.asp?TID=14626 <![CDATA[Codejock Developer Community]]> http://forum.codejock.com/forum_images/codejock-logo.gif http://forum.codejock.com/ <![CDATA[Deadlock in CXTPAccessible ctor : I usually do start debugging and...]]> http://forum.codejock.com/forum_posts.asp?TID=14626&PID=50371&title=deadlock-in-cxtpaccessible-ctor#50371 Author: rdhd
Subject: 14626
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.]]> Fri, 26 Jun 2009 17:38:13 +0000 http://forum.codejock.com/forum_posts.asp?TID=14626&PID=50371&title=deadlock-in-cxtpaccessible-ctor#50371 <![CDATA[Deadlock in CXTPAccessible ctor : Does this happen when you perform...]]> http://forum.codejock.com/forum_posts.asp?TID=14626&PID=50357&title=deadlock-in-cxtpaccessible-ctor#50357 Author: znakeeye
Subject: 14626
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.

]]> Fri, 26 Jun 2009 10:12:54 +0000 http://forum.codejock.com/forum_posts.asp?TID=14626&PID=50357&title=deadlock-in-cxtpaccessible-ctor#50357 <![CDATA[Deadlock in CXTPAccessible ctor : When starting our app in debug...]]> http://forum.codejock.com/forum_posts.asp?TID=14626&PID=50354&title=deadlock-in-cxtpaccessible-ctor#50354 Author: rdhd
Subject: 14626
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.

]]> Fri, 26 Jun 2009 09:18:22 +0000 http://forum.codejock.com/forum_posts.asp?TID=14626&PID=50354&title=deadlock-in-cxtpaccessible-ctor#50354