COM outbound call results in “An outgoing call cannot be made since the application is dispatching an input-synchronous call.”

Question

I have a COM server (C++/STA (MFC based app)) and a COM client (C#/MTA). The COM server must live in an STA, since it\'s an MFC app (I have no choice in this matter). The client

Answer 1

You can create a timer when you get the message and then do your COM calls and further processing in your TimerProc/WinProc under WM_TIMER. This works for me.

Answer 2

RPC_E_CANTCALLOUT_ININPUTSYNCCALL means that you attempted to make a marshalled COM call from within the handler for a windows message sent via SendMessage. This is to help avoid certain deadlock situations. You have a number of options, which boil down to "avoid COM calls in a SendMessage handler":

• You could use PostMessage to queue up a message to yourself, and in that posted message handler, invoke the COM callback.
• You could use asynchronous DCOM, and avoid blocking on the result of the call from within the message handler.
• You could marshal the callback interface, then invoke it from a thread pool work item. Since this is independent from the main application's message loop, it won't be in a SendMessage call, and it could even be in a MTA.
• You could forgo the MFC COM support, and invoke CoRegisterClassObject directly from another thread. This means any calls into your server COM object will be invoked from the COM thread pool (or, if you use a STA thread, from that thread), not from the MFC UI thread, so you'll need to use Windows messages to communicate across threads; but if you need to make synchronous calls back to the client it may be the best approach.

Answer 3

No matter how much I twist and turn, I cannot remove myself of the STA context within the app when I'm being called from the client. It doesn't matter if I host the server object in an MTA, I still have to obey the laws of COM. The STA is a really nasty "correctional facility" in this case. I'm doing hard time...

This has led me to a rather ugly path, but it works. Instead of using COM to communicate back to the client, I'm hand rolling my own communications path to the MTA that hosts the server object and the callback references. I'm basically creating my own marshalling code by setting up a call queue (STL container with parameters to send), which the MTA thread picks up and delivers to the client. The response is then returned to the code that's responding to the initial call. Synchronization is done using Win32 event objects.

Luckily, there aren't many callbacks I have to cover, and the nature of the mechanism is static, and will only be used for my own purposes (will not be run in a production environment).

Wheew... Sometimes I wonder what life would've been if I chose to become a carpenter instead.