{"id":110965,"date":"2025-03-14T07:00:00","date_gmt":"2025-03-14T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=110965"},"modified":"2025-03-14T08:54:14","modified_gmt":"2025-03-14T15:54:14","slug":"20250314-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20250314-00\/?p=110965","title":{"rendered":"The case of COM failing to pump messages in a single-threaded COM apartment"},"content":{"rendered":"

A customer encountered a hang caused by COM not pumping messages while waiting for a cross-thread operation to complete. They were using the task_sequencer<\/code> class<\/a> for serializing asynchronous operations on a UI thread they created to handle accessibility callbacks.<\/p>\n

The hang stack looked like this:<\/p>\n

ntdll!ZwWaitForMultipleObjects+0x4\r\nKERNELBASE!WaitForMultipleObjectsEx+0xe0\r\ncombase!MTAThreadDispatchCrossApartmentCall+0x3a0\r\ncombase!CSyncClientCall::SendReceive2+0x65c\r\ncombase!DefaultSendReceive+0x88\r\ncombase!CSyncClientCall::SendReceive+0x390\r\ncombase!CClientChannel::SendReceive+0xc0\r\ncombase!NdrExtpProxySendReceive+0x68\r\nrpcrt4!NdrpClientCall3+0x764\r\ncombase!ObjectStublessClient+0x180\r\ncombase!ObjectStubless+0x34\r\ncombase!CObjectContext::InternalContextCallback+0x3f0\r\ncombase!CObjectContext::ContextCallback+0x80\r\ncontoso!winrt::impl::resume_apartment_sync+0x58\r\ncontoso!winrt::impl::resume_apartment+0xe8\r\ncontoso!winrt::impl::apartment_awaiter::await_suspend+0x6c\r\ncontoso!\u27e6lambda...\u27e7::operator()<\u27e6...\u27e7>+0x1c8\r\ncontoso!task_sequencer::chained_task::continue_with+0x38\r\ncontoso!task_sequencer::QueueTaskAsync<\u27e6...\u27e7>+0xd0\r\ncontoso!\u27e6lambda...\u27e7::<lambda_invoker_cdecl>+0xa0\r\nuser32!__ClientCallWinEventProc+0x34\r\nntdll!KiUserCallbackDispatcherReturn\r\nwin32u!ZwUserGetMessage+0x4\r\nuser32!GetMessageW+0x28\r\ncontoso!\u27e6lambda...\u27e7::operator()+0x204\r\ncontoso!std::thread::_Invoke<\u27e6lambda...\u27e7>+0x24\r\nucrtbase!thread_start<unsigned int (__cdecl*)(void *),1>+0x48\r\nkernel32!BaseThreadInitThunk+0x40\r\nntdll!RtlUserThreadStart+0x44\r\n<\/pre>\n
We see that we have a UI thread (notice the Get\u00adMessage<\/code> at the bottom of the stack), yet COM decided to block without pumping messages (Wait\u00adFor\u00adMultiple\u00adObjects\u00adEx<\/code> instead of (Msg\u00adWait\u00adFor\u00adMultiple\u00adObjects\u00adEx<\/code>).<\/p>\n
Is this a bug in the task sequencer?<\/p>\n
Let’s look at the stack more closely. A message arrived via __Client\u00adCall\u00adWin\u00adEvent\u00adProc<\/code>, and that then queued a task into the task sequencer. The continue_with<\/code> saw that the task sequencer had no active task, so it ran the new task immediately. That new task wants to run on a different thread, so C++\/WinRT’s apartment-switching code kicked in.<\/p>\n
The apartment-switching code went to resume_apartment_sync, which in turn called  our friend IContext\u00adCallback::Context\u00adCallback<\/code><\/a>, and that called into the COM thread-switching infrastructure, which doesn’t pump messages while wiating for the destination apartment to respond.<\/p>\n
Now, COM is a rather mature technology, and this code path is execised constantly throughout the system, so it’s unlikely that it simply “forgot” to pump messages. The function name MTA\u00adThread\u00adDispatch\u00adCross\u00adApartment\u00adCall<\/code> strongly suggests that COM thinks that the thread is in an MTA. And the use of resume_apartment_sync<\/code> suggests that  C++\/WinRT also thinks that the thread is in an MTA<\/a>:<\/p>\n
else if (is_sta_thread()<\/span>)\r\n{\r\n    resume_apartment_on_threadpool(\r\n        context.m_context, handle, failure);\r\n    return true;\r\n}\r\nelse\r\n{\r\n    return resume_apartment_sync(           <\/span>\r\n        context.m_context, handle, failure);<\/span>\r\n}\r\n<\/pre>\n
If this were an STA thread, then we would have called resume_apartment_on_threadpool<\/code> instead of resume_apartment_sync<\/code>.<\/p>\n
Let’s take a closer look at this thread:<\/p>\n
\/\/ Create a thread to receive accessibility notifications.\r\nm_thread = std::thread([this] {\r\n    ::SetThreadDescription(::GetCurrentThread(), L\"Accessibility STA\");\r\n\r\n    \u27e6 ... \u27e7\r\n\r\n    wil::unique_hwineventhook hook(SetWinEventHook(\u27e6...\u27e7));\r\n    THROW_LAST_ERROR_IF_NULL(hook);\r\n\r\n    MSG msg;\r\n    while (!m_stop && GetMessage(&msg, NULL, 0, 0)) {\r\n        TranslateMessage(&msg);\r\n        DispatchMessage(&msg);\r\n    }\r\n});\r\n<\/pre>\n
Ah, so there’s your problem.<\/p>\n
The thread claims to be an STA thread:<\/p>\n
    ::SetThreadDescription(::GetCurrentThread(), L\"Accessibility STA<\/span>\");\r\n<\/pre>\n
But there is nothing in the thread procedure that actually makes it an STA thread. It never initialized COM in single-threaded mode.<\/p>\n
The thread merely engaged in wishful thinking, proclaming itself to be an STA thread without actually becoming one. (Or maybe it believed in nominative determinism: The mere act of calling itself an STA thread was sufficient to make it true.)<\/p>\n
Since COM is already initialized elsewhere in the process, the new thread gets put into the implicit MTA by default, and it took no action to leave it, so from COM’s point of view, this thread is an MTA thread. And MTA threads are allowed to block without pumping messages.<\/p>\n
What they need to do is actually make it an STA thread, say, by calling Co\u00adInitialize\u00adEx<\/code> with the COINIT_APARTMENT\u00adTHREADED<\/code> flag, and then uninitializing COM before the thread exits to return the thread to its original state. You can kill two birds with one stone with the help of the WIL RAII type.<\/p>\n
\/\/ Create a thread to receive accessibility notifications.\r\nm_thread = std::thread([this] {\r\n    auto uninit = wil::CoInitializeEx(COINIT_APARTMENTTHREADED);<\/span>\r\n\r\n    ::SetThreadDescription(::GetCurrentThread(), L\"Accessibility STA\");\r\n\r\n    \u27e6 ... \u27e7\r\n\r\n    wil::unique_hwineventhook hook(SetWinEventHook(\u27e6...\u27e7));\r\n    THROW_LAST_ERROR_IF_NULL(hook);\r\n\r\n    MSG msg;\r\n    while (!m_stop && GetMessage(&msg, NULL, 0, 0)) {\r\n        TranslateMessage(&msg);\r\n        DispatchMessage(&msg);\r\n    }\r\n});\r\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
A customer encountered a hang caused by COM not pumping messages while waiting for a cross-thread operation to complete. They were using the task_sequencer class for serializing asynchronous operations on a UI thread they created to handle accessibility callbacks. The hang stack looked like this: ntdll!ZwWaitForMultipleObjects+0x4 KERNELBASE!WaitForMultipleObjectsEx+0xe0 combase!MTAThreadDispatchCrossApartmentCall+0x3a0 combase!CSyncClientCall::SendReceive2+0x65c combase!DefaultSendReceive+0x88 combase!CSyncClientCall::SendReceive+0x390 combase!CClientChannel::SendReceive+0xc0 combase!NdrExtpProxySendReceive+0x68 rpcrt4!NdrpClientCall3+0x764 combase!ObjectStublessClient+0x180 […]<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-110965","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
A customer encountered a hang caused by COM not pumping messages while waiting for a cross-thread operation to complete. They were using the task_sequencer class for serializing asynchronous operations on a UI thread they created to handle accessibility callbacks. The hang stack looked like this: ntdll!ZwWaitForMultipleObjects+0x4 KERNELBASE!WaitForMultipleObjectsEx+0xe0 combase!MTAThreadDispatchCrossApartmentCall+0x3a0 combase!CSyncClientCall::SendReceive2+0x65c combase!DefaultSendReceive+0x88 combase!CSyncClientCall::SendReceive+0x390 combase!CClientChannel::SendReceive+0xc0 combase!NdrExtpProxySendReceive+0x68 rpcrt4!NdrpClientCall3+0x764 combase!ObjectStublessClient+0x180 […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110965","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=110965"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110965\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=110965"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=110965"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=110965"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}