none
win32 com server (user32.dll?) and System.Windows.Form RRS feed

  • Question

  • Hi,

     

    I'm just trying to understand an issue (moved from http://social.msdn.microsoft.com/Forums/en-US/vsx/thread/844f9a83-b6f4-43d3-aaed-87c52aa9455a/, where the solution to my problem was found).

     

    My question is this:  If I create a form on a thread in MTA mode, why are there concurrency issues (i.e. exceptions thrown) in what seems to be the win32 in-proc server?

    I noticed that when there were a large volume of GUI events on the form that these kind of issues (appearing to be race related) pop up.

    I realize that the standard practice is to use STA.  I just don't understand why a single thread in my form causes issues in the com server.  Does the com server determine its apartment type from the calling client?

    Or perhaps it is because the synchronization that COM provides is absent when either the client or server is MTA, i.e. COM synchronizes access only when both client and server use the STA model?

    If this is the case, then somehow calls from my client are being answered asynchronously from multiple server threads?

     

    Thanks - as I mentioned, I realize that using an MTA apartment bounded thread to run a form in .NET will cause issues.  I just want to understand enough of the details of the .NET / win32 interface to better explain and understand this behavior.


    GS @ School of Computing, University of Utah
    • Edited by Geof2323 Friday, March 4, 2011 10:50 PM correct typo
    Friday, March 4, 2011 10:47 PM

Answers

All replies

  • User interface code + multi-threaded apartment = death

    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP
    • Marked as answer by Geof2323 Saturday, March 5, 2011 2:04 AM
    Saturday, March 5, 2011 1:46 AM
  • Sheng, you rule.

     

    Exactly what I was looking for!  This explains the deadlock on WaitForSingleObject and the NullReferenceException apparently when the COM server attempted to post on the MTA apt thread's message queue.

     

    Geof


    GS @ School of Computing, University of Utah
    Saturday, March 5, 2011 2:04 AM