A customer reported that each time they created and exited a thread, their DLL reference count goes up by one. This was a problem because their code loads a DLL and then calls a function in it. That function creates a thread, waits for the thread to finish, and then returns. After the function returns, their main program tries to unload the DLL, but the DLL remains in memory. Their debugging (with the !dlls<\/tt> debugger extension) showed that when they created a thread, the DLL reference count went up by one, but it did not drop back down when the thread exited.<\/p>\n
The customer asked why This question struck the DLL loader team as odd, because We went back to the customer to get some more information.<\/p>\n The customer said that they create the thread with Okay, that explains it.\u00b9 They are creating the thread with The documentation for For an executable file linked with Libcmt.lib, do not call the Win32 It is not where<\/p>\n So it’s not If you call The customer noted that they also tried When you exit the thread with we see that this bypasses the destructor of Moral of the story: If you use And if you use \u00b9 It also points out that the customer’s question is misleading. They asked why If you use a wrapper, you need to follow the wrapper’s rules.<\/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-110604","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":" If you use a wrapper, you need to follow the wrapper’s rules.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110604","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=110604"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110604\/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=110604"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=110604"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=110604"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Create\u00adThread<\/code> increments the DLL reference count, but Exit\u00adThread<\/code> doesn’t decrement it.<\/p>\nCreate\u00adThread<\/code> doesn’t increment the DLL reference count, and a quick sanity test confirmed their recollection: Creating a thread with Create\u00adThread<\/code> does not increment the DLL reference count. Consequently, Exit\u00adThread<\/code> is correct in not decrementing it.<\/p>\n_beginthreadex<\/code>. Switching to std::thread<\/code> didn’t help.<\/p>\n_beginthreadex<\/code> and ending it with ExitThread<\/code>.<\/p>\n_beginthread<\/code> and _beginthreadex<\/code><\/a> has a big banner that says<\/p>\nExitThread<\/code> API<\/span> so that you don’t prevent the run-time system from reclaiming allocated resources. _endthread<\/code> and _endthreadex<\/code> reclaim allocated thread resources and then call ExitThread<\/code>.<\/p><\/blockquote>\nCreate\u00adThread<\/code> that increments the DLL reference count. It’s _beginthreadex<\/code>. You can see it in the code, which is provided in the Windows Platform SDK under C:\\extern \"C\" uintptr_t __cdecl _beginthreadex(\r\n void* const security_descriptor,\r\n unsigned int const stack_size,\r\n _beginthreadex_proc_type const procedure,\r\n void* const context,\r\n unsigned int const creation_flags,\r\n unsigned int* const thread_id_result\r\n )\r\n{\r\n _VALIDATE_RETURN(procedure != nullptr, EINVAL, 0);\r\n\r\n unique_thread_parameter parameter(\r\n create_thread_parameter(procedure, context));\r\n\r\n \u27e6 ... more stuff ... \u27e7\r\n<\/pre>\nstatic __acrt_thread_parameter* __cdecl create_thread_parameter(\r\n void* const procedure,\r\n void* const context\r\n ) throw()\r\n{\r\n unique_thread_parameter parameter(\r\n _calloc_crt_t(__acrt_thread_parameter, 1).detach());\r\n if (!parameter)\r\n {\r\n return nullptr;\r\n }\r\n\r\n parameter.get()->_procedure = procedure;\r\n parameter.get()->_context = context;\r\n\r\n \/\/ Attempt to bump the reference count of the module in which the user's\r\n \/\/ thread procedure is defined, to ensure that the module will stay loaded\r\n \/\/ as long as the thread is executing. We will release this HMDOULE [sic]\r\n \/\/ when the thread procedure returns or _endthreadex is called.<\/span>\r\n GetModuleHandleExW(\r\n GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS,\r\n reinterpret_cast<LPCWSTR>(procedure),\r\n ¶meter.get()->_module_handle);\r\n\r\n return parameter.detach();\r\n}\r\n<\/pre>\nCreate\u00adThread<\/code> that is incrementing the DLL reference count. It’s _beginthreadex<\/code>. And the DLL reference count decrements when the thread procedure returns or when you call _endthreadex<\/code>:<\/p>\nstatic void __cdecl common_end_thread(unsigned int const return_code) throw()\r\n{\r\n \u27e6 ... other stuff not relevant here ... \u27e7\r\n\r\n if (parameter->_module_handle != INVALID_HANDLE_VALUE &&\r\n parameter->_module_handle != nullptr)\r\n {\r\n FreeLibraryAndExitThread(parameter->_module_handle, return_code);<\/span>\r\n }\r\n else\r\n {\r\n ExitThread(return_code);\r\n }\r\n}\r\n\r\nextern \"C\" void __cdecl _endthread()\r\n{\r\n return common_end_thread(0);\r\n}\r\n\r\nextern \"C\" void __cdecl _endthreadex(unsigned int const return_code)\r\n{\r\n return common_end_thread(return_code);\r\n}\r\n<\/pre>\nExitThread<\/code> directly, then you bypass the cleanup code that _endthreadex<\/code> performs, which means that you leak a bunch of stuff, including the DLL reference.<\/p>\nstd::ExitThread<\/code> to exit a std::thread<\/code>:<\/p>\n\/\/ Don't do this!\r\nauto thread = std::thread([] {\r\n \u27e6 ... do some stuff ... \u27e7\r\n ExitThread(42); \/\/ all done\r\n});\r\n<\/pre>\nExit\u00adThread()<\/code>, the thread ends without allowing the active function calls to clean up. If we look at std::template <class _Tuple, size_t... _Indices>\r\nstatic unsigned int __stdcall _Invoke(void* _RawVals)\r\n noexcept \/* terminates *\/ {\r\n \/\/ adapt invoke of user's callable object to _beginthreadex's\r\n \/\/ thread procedure\r\n const unique_ptr<_Tuple> _FnVals(static_cast<_Tuple*>(_RawVals));\r\n _Tuple& _Tup = *_FnVals.get(); \/\/ avoid ADL, handle incomplete types\r\n _STD invoke(_STD move(_STD get<_Indices>(_Tup))...);\r\n _Cnd_do_broadcast_at_thread_exit(); \/\/ TRANSITION, ABI\r\n return 0;\r\n}\r\n<\/pre>\n_FnVals<\/code>, which means that we leak the _Tuple<\/code> that holds the thread callable and parameters. We also bypass the call to _Cnd_std::std::_beginthread<\/code> or _beginthreadex<\/code>, you must exit the thread either by returning from your thread function or by calling _endthread<\/code> or _endthreadex<\/code>. Don’t go straight to Exit\u00adThread()<\/code>.<\/p>\nstd::_endthread<\/code> or _endthreadex<\/code> or Exit\u00adThread()<\/code>.<\/p>\nCreate\u00adThread<\/code> increments the DLL reference count, but they aren’t calling Create\u00adThread<\/code> themselves, so how do they know that it’s Create\u00adThread<\/code> that’s doing it?<\/p>\n","protected":false},"excerpt":{"rendered":"