{"id":102719,"date":"2019-07-18T07:00:00","date_gmt":"2019-07-18T14:00:00","guid":{"rendered":"http:\/\/devblogs.microsoft.com\/oldnewthing\/?p=102719"},"modified":"2019-07-17T21:09:21","modified_gmt":"2019-07-18T04:09:21","slug":"20190718-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20190718-00\/?p=102719","title":{"rendered":"After I made my DLL delay-load another DLL, my DLL has started crashing in its process detach code"},"content":{"rendered":"

A customer had a DLL, let’s call it CONTOSO.DLL<\/code>, and that DLL linked to another DLL, let’s call it WIDGET.DLL<\/code>. To improve DLL load time, they made WIDGET.DLL<\/code> a delay-loaded DLL via the \/DELAYLOAD<\/code> linker option<\/a>. This worked out great, except that sometimes their DLL crashed when shutting down.<\/p>\n

When the WIDGET.DLL<\/code> was a static dependency, the loader made a note to ensure that WIDGET.DLL<\/code> was loaded and ready before calling CONTOSO.DLL<\/code>‘s initialization function, and made sure that WIDGET.DLL<\/code> remained valid until CONTOSO.DLL<\/code> completed its uninitialization.<\/p>\n

Switching the WIDGET.DLL<\/code> to a \/DELAYLOAD<\/code> DLL removes this static dependency, and the loader isn’t around to help any more.<\/p>\n

When the process shuts down, the loader uninitializes the DLLs in an order that tries\u00b9 to preserve the static dependencies, so that a DLL waits until all its dependents are uninitialized before itself uninitializing. However, the loader does not have insight into dynamically-created dependencies, and the DLLs may unload out of order<\/a>.<\/p>\n

What happened is that CONTOSO.DLL<\/code> initialized without WIDGET.DLL<\/code>, and then later somebody needed a widget, so it loaded WIDGET.DLL<\/code> and did some widget stuff, and then cached the widget so it wouldn’t have to go through all that nonsense again.<\/p>\n

In the CONTOSO.DLL<\/code> module’s DLL_<\/code>PROCESS_<\/code>DETACH<\/code> code, it checks\u00b2 if there is a cached widget, and if so, destroys it.<\/p>\n

WIDGET.DLL was a dynamic dependency, the module loader doesn’t take it into account when calculating the order in which modules should be uninitlalized. The loader sees no static dependency between CONTOSO.DLL<\/code> and WIDGET.DLL<\/code>, so the order in which they uninitialize is arbitrary.<\/p>\n

And if the arbitrary decision ends up selecting WIDGET.DLL<\/code> to uninitialize first, then you have a crash when CONTOSO.DLL<\/code> tries to call into an already-uninitialized DLL.<\/p>\n

Note that this problem occurs only at process shutdown. If CONTOSO.DLL<\/code> unloads via a runtime call to Free\u00adLibrary<\/code>, it will still be able to call into WIDGET.DLL<\/code> because it hasn’t yet called Free\u00adLibrary<\/code> on WIDGET.DLL<\/code>. But during process shutdown, the module loader needs to free all the things, and the outstanding Load\u00adLibrary<\/code> won’t prevent that from happening.<\/p>\n

The solution is to bypass widget cleanup if the DLL_<\/code>PROCESS_<\/code>DETACH<\/code> handler realizes that the process is terminating. Just leak the widget. The building is being demolished. You don’t need to sweep the floors<\/a>.<\/p>\n

The DLL was able to start without the widget DLL. It should be able to finish without the widget DLL.<\/p>\n

\u00b9 I say “tries” because circular dependencies make such an effort impossible to achieve, but the loader does the best it can.<\/p>\n

\u00b2 It’s important to check for evidence of widgets before trying to clean up widget-related things. Otherwise, you may end up loading a DLL in your DLL_<\/code>PROCESS_<\/code>DETACH<\/code> handler<\/a>, and that’s not good.<\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

You started without it. You should be able to finish without it.<\/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-102719","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"

You started without it. You should be able to finish without it.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/102719","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=102719"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/102719\/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=102719"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=102719"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=102719"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}