Fix RPC_E_CANTPOST_INSENDCALL (0x80010003) error

Quick answer (if you know what you're doing): Don't call PostMessage while inside an intertask SendMessage. Instead, use a timer, a worker thread, or a custom queue to defer the post until the SendMessage completes.

What's actually happening here

This error shows up when your code is inside a callback triggered by SendMessage (which waits for the reply) and then you try to call PostMessage (which returns immediately). The system says: "Hold on — you can't do that." It's a safety rule built into Windows to prevent reentrancy issues and deadlocks in the message pump.

Real-world scenario: You're writing a COM component or a plugin for an old VB6 app. Your event handler gets called when the user clicks a button. The host app uses SendMessage under the hood. Inside that handler, you try to post a custom message to your own window. Boom — 0x80010003.

The exact error code is 0X80010003, and the description says: "The caller is dispatching an intertask SendMessage call and cannot call out via PostMessage." The system is blocking you because allowing the post could corrupt the message queue state.

Fix it — step by step

1. Identify where the SendMessage is happening. Add a call to InSendMessage() in your code. If it returns non-zero, you're inside a send. That's your problem spot.
2. Remove the direct PostMessage call from inside that handler. Replace it with something that delays the post until the send finishes. The simplest fix: use a flag and a timer. Set a boolean flag to true, then set a timer for 1 millisecond. When the timer fires, check the flag and call PostMessage then.
3. Alternative: use a worker thread. If your app already has a thread pool or background thread, queue the post there. The thread can safely call PostMessage because it's not inside any send call.
4. If you control both sides of the call, change the architecture. Replace SendMessage with PostMessage + callback. That way you never block, and the restriction goes away. This isn't always possible, especially if you're dealing with third-party code.
5. Test it. After you make the change, run your app and trigger the scenario again. The error should stop. If it doesn't, check that the flag and timer logic is correct — the timer callback must run after the send has completed.

Alternative fixes when the main one doesn't work

Sometimes you can't easily defer the post. Here are other options:

• Use PostThreadMessage instead of PostMessage. This avoids the restriction in some cases, but not all. Test it.
• Wrap the call in a try-catch and handle the error gracefully. This won't fix the underlying issue, but it'll stop the crash. You'd log the error and maybe queue the message manually for later processing.
• Change from SendMessage to SendMessageTimeout. Add SMTO_BLOCK or SMTO_NORMAL flags. This sometimes shifts the context enough that the restriction doesn't apply. Rare, but worth a shot.
• If you're in a COM call, check the threading model. Make sure your object is in an STA (single-threaded apartment) if the host expects it. Mismatched apartments can cause this too. Use CoInitializeEx with the right flag.

Prevention — don't let it happen again

The rule is simple: never perform any UI-related call that posts messages (like PostMessage, SetWindowText, or even some clipboard operations) while you're in a SendMessage callback. If you're writing a component that will be hosted by an app you don't control, assume SendMessage is used somewhere and plan for it.

One pattern I've used for years: create a small message queue in your code. When a SendMessage callback fires, instead of calling PostMessage, just push an item onto the queue. Then in your main message loop (or a timer), drain that queue with actual PostMessage calls. This decouples the call from the context and eliminates the problem entirely.

Also, test your code in a debugger with breakpoints set on InSendMessage. If you see it return true when you didn't expect it, you've found a hidden send context. Fix those early.

That's it. This error is frustrating, but it's a hard safety wall built by the Windows team for good reason. Work with it, not against it.