Why is there a long delay between a thread exiting and the Wait­For­Single­Object returning?

A customer reported that they were using the Wait­For­Single­Object function to wait for a thread to exit, but they found that even though the thread had exited, the Wait­For­Single­Object call did not return for over a minute. What could explain this delay in reporting the end of a thread? Can we do something to speed it up?

My psychic powers tell me that the thread didn’t actually exit.

What the customer is observing is probably that their thread procedure has returned, signaling the end of the thread. But a lot of stuff happens after the thread procedure exits. The system needs to send DLL_THREAD_DETACH notifications to all of the DLLs (unless the DLL has opted out via Disable­Thread­Library­Calls), and doing so requires the loader lock.

I would use the debugger to look for the thread you thought had exited and see what it’s doing. It might be blocked waiting for the loader lock because some other thread is hogging it. Or it could be running a DLL’s detach code, and that detach code has gotten stuck on a long-running operation.

I suspect it’s the latter: One of the DLLs is waiting for something in its detach code, and that something takes about a minute.

We didn’t hear back from the customer, which could mean that this was indeed the problem. Or it could mean that this didn’t help, but they decided that we weren’t being helpful and didn’t pursue the matter further. Unfortunately, in a lot of these customer debugging engagements, we never hear back whether our theory worked. (Another possibility is that the customer wrote back with a “thank you”, but the customer liaison didn’t forward it to the engineering team because they didn’t want to bother them any further.)