A customer tracked one of their crashes to an invalid handle exception being raised when one thread closed a handle that another thread was waiting for. Or at least that’s how they presented the problem.<\/p>\n
The stack trace in the crash dump said<\/p>\n
ntdll!KiRaiseUserExceptionDispatcher+0x3a\r\nKERNELBASE!WaitForMultipleObjectsEx+0x123\r\nKERNELBASE!WaitForMultipleObjects+0x11\r\ncontoso!Widget::WaitUntilReadyAsync$_ResumeCoro$1+0x1316\r\ncontoso!std::experimental::coroutine_handle<void>::resume+0xc\r\ncontoso!std::experimental::coroutine_handle<void>::operator()+0xc\r\ncontoso!winrt::impl::resume_background_callback+0x10\r\nntdll!TppSimplepExecuteCallback+0x14d\r\nntdll!TppWorkerThread+0x819\r\nkernel32!BaseThreadInitThunk+0x17\r\n<\/pre>\nHere’s a simplified version of the code:<\/p>\n
struct Widget : std::enable_shared_from_this<Widget>\r\n{\r\n wil::unique_event m_readyEvent{ wil::EventOptions::ManualReset };\r\n wil::unique_event m_shutdownEvent{ wil::EventOptions::ManualReset };\r\n\r\n winrt::IAsyncOperation<bool> WaitUntilReadyAsync()\r\n {\r\n co_await winrt::resume_background();\r\n\r\n HANDLE events[] = { m_readyEvent.get(), m_shutdownEvent.get() };\r\n auto status = WaitForMultipleObjects(ARRAYSIZE(events), events,\r\n FALSE \/* bWaitAll *\/, INFINITE);\r\n\r\n switch (status) {\r\n case WAIT_OBJECT_0:\r\n co_return true; \/\/ the ready event is set\r\n\r\n case WAIT_OBJECT_0 + 1:\r\n co_return false; \/\/ the shutdown event is set\r\n\r\n case WAIT_FAILED:\r\n FAIL_FAST_LAST_ERROR();\r\n\r\n default:\r\n FAIL_FAST();\r\n }\r\n }\r\n};\r\n<\/pre>\nThe customer’s debugging showed that the
Widget<\/code> object had already destructed. (The coroutine should have done aauto lifetime = shared_from_this()<\/code> to ensure that theWidget<\/code> did not destruct while it was still in use.) The destructor ofwil::unique_event<\/code> closes the event handle, so we have a case of closing a handle while a thread was waiting on it. TheWait\u00adFor\u00adMultiple\u00adObjecs<\/code> documentation calls this out:<\/p>\nIf one of these handles is closed while the wait is still pending, the function’s behavior is undefined.<\/p><\/blockquote>\n
The customer noted that the behavior was undefined, but nevertheless wondered why they were crashing at the
Wait\u00adFor\u00adMultiple\u00adObjects<\/code> call. When they tried to reproduce the error in-house by forcing the object to destruct during the wait, but they couldn’t get the crash that their clients were getting.<\/p>\nThe first thing to note is that “undefined behavior” means that anything can happen. Maybe it crashes, maybe it hangs, maybe it returns “The event is set” even though it isn’t, maybe it just seems to work okay. There’s no requirement that the undefined behavior be consistent from one instance to another.<\/p>\n
But you don’t need to use the “undefined behavior” escape hatch to explain the behavior.<\/p>\n
If you have a case where one thread closes a handle after another thread has started waiting for it, then you also have a case where one thread closes a a handle before<\/i> another thread has started waiting for it.<\/p>\n
If this is possible…<\/p>\n
\n\n
\n Thread 1<\/th>\n Thread 2<\/th>\n<\/tr>\n \n WaitForMultipleObjects(...);<\/tt><\/td>\n <\/td>\n<\/tr>\n \n \u00a0<\/td>\n CloseHandle(...);<\/tt><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Then this is also possible because there is no synchronization between the two threads, so one CPU might just get lucky and execute a tiny bit faster than the other:<\/p>\n
\n\n
\n Thread 1<\/th>\n Thread 2<\/th>\n<\/tr>\n \n \u00a0<\/td>\n CloseHandle(...);<\/tt><\/td>\n<\/tr>\n \n WaitForMultipleObjects(...);<\/tt><\/td>\n <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n In this case, it’s clear that the
Wait\u00adFor\u00adMultiple\u00adObjects<\/code> will fail with “invalid handle” since the handle had already been closed by the time we try to wait on it.<\/p>\nTherefore, my guess was that we are in the second case, where the
CloseHandle<\/code> raced ahead of theWait\u00adFor\u00adMultiple\u00adObjects<\/code>, causing theWait\u00adFor\u00adMultiple\u00adObjects<\/code> to wait on an invalid handle. We know that it’s possible, and the exception code of “invalid handle” is consistent with that theory.<\/p>\nThe customer was not entirely convinced that the object was being destroyed before the wait. They observed that the
status<\/code> variable always held the value 41. What does 41 mean?<\/p>\n