{"id":107815,"date":"2023-02-10T07:00:00","date_gmt":"2023-02-10T15:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=107815"},"modified":"2023-08-07T13:46:05","modified_gmt":"2023-08-07T20:46:05","slug":"20230210-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20230210-00\/?p=107815","title":{"rendered":"The case of the RPC_E_DISCONNECTED<\/CODE> error thrown from await_resume<\/CODE>"},"content":{"rendered":"

A customer was studying some crashes with the following call stack, with function names abbreviated for readability:<\/p>\n

 # Call Site\r\n00 KERNELBASE!RaiseFailFastException+0x152\r\n01 combase!RoFailFastWithErrorContextInternal2+0x4d9\r\n02 Contoso!winrt::terminate+0x64\r\n03 Contoso!std::coroutine_traits<winrt::fire_and_forget,\u27ec\u2026\u27ed>::promise_type::unhandled_exception+0x9\r\n04 contoso!`Contoso::UserInfoViewModel::LoadUserInfoAsync$_ResumeCoro$1'::`1'::catch$128+0x20\r\n05 ucrtbase!_CallSettingFrame_LookupContinuationIndex+0x20\r\n06 ucrtbase!__FrameHandler4::CxxCallCatchBlock+0x115\r\n07 ntdll!RcFrameConsolidation+0x6\r\n08 Contoso!Contoso::UserInfoViewModel::LoadUserInfoAsync$_ResumeCoro$1+0x502\r\n09 Contoso!std::coroutine_handle<void>::resume+0x16\r\n0a Contoso!std::coroutine_handle<void>::operator()+0x16\r\n0b Contoso!winrt::impl::resume_apartment_sync+0x7f\r\n0c Contoso!winrt::impl::resume_apartment+0xa4\r\n0d Contoso!winrt::impl::disconnect_aware_handler<\u27ec\u2026\u27ed>::operator()+0xd\r\n0e Contoso!winrt::impl::delegate<\u27ec\u2026\u27ed>::Invoke+0x15\r\n0f Contoso!winrt::Windows::Foundation::AsyncActionCompletedHandler::operator()+0x24\r\n10 Contoso!winrt::impl::invoke<\u27ec\u2026\u27ed>+0x17\r\n11 Contoso!winrt::impl::promise_base<\u27ec\u2026\u27ed>::set_completed+0x59\r\n12 Contoso!winrt::impl::promise_base<\u27ec\u2026\u27ed>::final_suspend_awaiter::await_suspend+0x74\r\n13 Contoso!Contoso::UserInfoViewModel::LoadUserNameAndPictureAsync$_ResumeCoro$1+0x715\r\n14 Contoso!std::coroutine_handle<void>::resume+0x16\r\n15 Contoso!std::coroutine_handle<void>::operator()+0x16\r\n16 Contoso!winrt::impl::resume_apartment_sync+0x7f\r\n17 Contoso!winrt::impl::resume_apartment+0xa4\r\n18 Contoso!winrt::impl::disconnect_aware_handler<\u27ec\u2026\u27ed>::operator()+0xd\r\n19 Contoso!winrt::impl::delegate<\u27ec\u2026\u27ed>::Invoke+0x15\r\n1a Contoso!winrt::Windows::Foundation::AsyncOperationCompletedHandler<\u27ec\u2026\u27ed>::operator()+0x24\r\n1b Contoso!winrt::impl::invoke<\u27ec\u2026\u27ed>+0x17\r\n1c Contoso!winrt::impl::promise_base<\u27ec\u2026\u27ed>::set_completed+0x59\r\n1d Contoso!winrt::impl::promise_base<\u27ec\u2026\u27ed>::final_suspend_awaiter::await_suspend+0x74\r\n1e Contoso!Contoso::UserInfoModel::LoadUserNameAsync$_ResumeCoro$1+0x1ea\r\n1f Contoso!std::coroutine_handle<void>::resume+0x16\r\n20 Contoso!std::coroutine_handle<void>::operator()+0x16\r\n21 Contoso!winrt::impl::resume_apartment_sync+0x7f\r\n22 Contoso!winrt::impl::resume_apartment+0xa4\r\n23 Contoso!winrt::impl::disconnect_aware_handler<\u27ec\u2026\u27ed>::operator()+0xd\r\n24 Contoso!winrt::impl::delegate<\u27ec\u2026\u27ed>::Invoke+0x15\r\n25 usermgrproxy!Windows::Internal::Async::HardenedAsyncBase<\u27ec\u2026\u27ed>::FireCompletion+0x154\r\n26 usermgrproxy!AsyncOperationBase<\u27ec\u2026\u27ed>::DoWorkStub+0xd8\r\n27 ntdll!RtlpTpWorkCallback+0x192\r\n28 ntdll!TppWorkerThread+0x639\r\n29 kernel32!BaseThreadInitThunk+0x1d\r\n2a ntdll!RtlUserThreadStart+0x28\r\n<\/pre>\n
They assumed that they were running on the wrong thread, so their proposed solution was to add a<\/p>\n
co_await resume_foreground(Dispatcher());\r\n<\/pre>\n
after every co_await<\/code> to make sure they were on the correct thread. But first, let’s see what’s really going on.<\/p>\n
Reading from the bottom up, we see that at stack frame 25:<\/p>\n
25 usermgrproxy!Windows::Internal::Async::HardenedAsyncBase<\u27ec\u2026\u27ed>::FireCompletion+0x154\r\n<\/pre>\n
The asynchronous operation completed, and therefore it calls its completion delegate:<\/p>\n
24 Contoso!winrt::impl::delegate<\u27ec\u2026\u27ed>::Invoke+0x15\r\n<\/pre>\n
The completion delegate is a C++\/WinRT completion, so it goes to the  disconnect-aware handler: which we<\/p>\n
23 Contoso!winrt::impl::disconnect_aware_handler<\u27ec\u2026\u27ed>::operator()+0xd\r\n<\/pre>\n
Upon completion, the C++\/WinRT library tries to  resume the awaiting coroutine in the original COM apartment context in which the co_await<\/code> began:<\/p>\n
20 Contoso!std::coroutine_handle<void>::operator()+0x16\r\n21 Contoso!winrt::impl::resume_apartment_sync+0x7f\r\n22 Contoso!winrt::impl::resume_apartment+0xa4\r\n<\/pre>\n
They key thing to observe here is that we are making a call from resume_apartment_sync<\/code> directly to the awaiting coroutine. This happens only when the apartment switch has failed, and we are intentionally resuming the coroutine in the wrong apartment so we can report the error.<\/p>\n
Let’s see what the error is.<\/p>\n
0:024> .frame 21\r\n21 Contoso!winrt::impl::resume_apartment_sync+0x7f\r\n0:024> dv\r\n        context = <value unavailable>\r\n         handle = struct std::experimental::coroutine_handle<void>\r\n        failure = 0x000001c8`6f2f0f44\r\n           args = struct winrt::impl::com_callback_args\r\n         result = 0n-45104688\r\n0:024> ?? *failure\r\nint 0n-2147417848\r\n<\/pre>\n
The signed decimal number -2147417848<\/code> corresponds to the error 0x80010108<\/code> which is RPC_E_DISCONNECTED<\/code>. This means that we were unable to switch apartments because the destination apartment no longer exists.<\/p>\n
At this point, the code starts to spiral.<\/p>\n
The calling coroutine is<\/p>\n
1e Contoso!Contoso::UserInfoModel::LoadUserNameAsync$_ResumeCoro$1+0x1ea\r\n<\/pre>\n
and it doesn’t handle the exception. Therefore, the exception gets stowed in the promise, and then the coroutine completes and calls its completion delegate to resume the awaiting coroutine. The completion delegate is another disconnect-aware handler:<\/p>\n
18 Contoso!winrt::impl::disconnect_aware_handler<\u27ec\u2026\u27ed>::operator()+0xd\r\n<\/pre>\n
As before, the C++\/WinRT library tries to resume the awaiting coroutine in the original COM apartment context in which the co_await<\/code> began:<\/p>\n
15 Contoso!std::coroutine_handle<void>::operator()+0x16\r\n16 Contoso!winrt::impl::resume_apartment_sync+0x7f\r\n17 Contoso!winrt::impl::resume_apartment+0xa4\r\n<\/pre>\n
Now, it turns out that all of these coroutines run on the UI thread, so in each case, the C++\/WinRT library is trying to return to the UI thread, and the apartment switch fails, and the cycle continues: The call from resume_apartment_sync<\/code> directly to the awaiting coroutine means that we were once again unable to switch to the original COM apartment. Again the caller doesn’t handle this exception, so the exception is stowed in the promise, and then the caller completion delegate is called.<\/p>\n
One more turn of the cycle: That completion delegate fails to switch to the original COM apartment and once again resumes the caller directly in order to report the error:<\/p>\n
0a Contoso!std::coroutine_handle<void>::operator()+0x16\r\n0b Contoso!winrt::impl::resume_apartment_sync+0x7f\r\n0c Contoso!winrt::impl::resume_apartment+0xa4\r\n0d Contoso!winrt::impl::disconnect_aware_handler<\u27ec\u2026\u27ed>::operator()+0xd\r\n<\/pre>\n
The proposed fix of switching to the UI thread won’t help. In fact, switching to the UI thread just repeats the problem.<\/p>\n
<\/p>\n
The buck finally stops at User\u00adInfo\u00adView\u00adModel::\u00adLoad\u00adUser\u00adInfo\u00adAsync<\/code>, because that is a fire_and_forget<\/code> coroutine, and fire_and_forget<\/code> coroutines treat unhandled exceptions as fatal errors, so the fire_and_forget<\/code> promise calls winrt::terminate<\/code> when an unhandled exception occurs, and that terminates the process.<\/p>\n
To fix the problem, we first need to decide what we should do if the UI thread terminates while our asynchronous work is still running. In this particular case, the asynchronous work is retrieving data in order to update the UI, so if the UI no longer exists, then there’s no point doing the asynchronous work, and we can just abandon it. Therefore, we can add a catch block to the outer fire_and_forget<\/code> coroutine to catch and ignore disconnected errors.<\/p>\n
winrt::fire_and_forget UserInfoViewModel::LoadUserInfoAsync() try<\/span>\r\n{\r\n    \u27ec do asynchronous work to update the UI \u27ed\r\n}\r\ncatch (...)                                                          <\/span>\r\n{                                                                    <\/span>\r\n    \/\/ Ignore disconnected errors, but anything else is fatal.       <\/span>\r\n    \/\/ Disconnected errors mean that our UI thread no longer exists. <\/span>\r\n    if (winrt::to_hresult() != RPC_E_DISCONNECTED)                   <\/span>\r\n    {                                                                <\/span>\r\n        winrt::terminate();                                          <\/span>\r\n    }                                                                <\/span>\r\n}                                                                    <\/span>\r\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
You can keep trying, but the result won’t change.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-107815","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
You can keep trying, but the result won’t change.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/107815","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=107815"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/107815\/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=107815"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=107815"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=107815"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}