The case of the thread executing from an unloaded third-party DLL
A developer encountered a crash caused by a thread still executing code from a third-party DLL after the DLL had been unloaded. The issue arose because a callback or ongoing operation was not properly canceled before the DLL was freed. The post highlights the dangers of unloading DLLs while threads may still be running code from them.
Background
Raymond Chen writes "The Old New Thing," a long-running Microsoft blog about Windows internals, software quirks, and debugging war stories. This post recounts a crash caused by a thread still running code from a third-party DLL after that DLL had been unloaded from memory.
- DLL (Dynamic-Link Library): A Windows module containing code/data that programs load at runtime. When unloaded, its memory is freed; any thread still executing inside it will jump to garbage or a crash.
- The core issue: A program loaded a third-party DLL, created threads that ran code from it, then unloaded the DLL but forgot to ensure those threads had stopped first. The threads kept running in freed memory, causing an access violation (AV) or unpredictable behavior.
- This is a classic "use-after-free" bug at the module level, often hard to reproduce because the freed memory might not be overwritten immediately.
- Chen's point: Developers must wait for all threads to exit a DLL before unloading it, or the application will crash — and the crash signature (a thread executing in unloaded code) can mislead investigators into blaming the third-party vendor.