The DLL that was not present in memory despite not being formally unloaded 2
A developer found that a DLL was no longer in memory even though it hadn't been formally unloaded, tracing the issue to Windows' DLL load ordering. When a DLL is loaded at a base address that conflicts with another DLL loaded earlier, the system may relocate it and then later discard the relocated version without clear notification, confusing developers expecting explicit unload.
Background
Raymond Chen writes the "Old New Thing" blog at Microsoft, known for deep-dive Windows internals posts.
This is the second part of a story about a subtle DLL unloading bug. The first part (June 24, 2026) described how calling FreeLibrary on a DLL (to unload it) decrements a reference count, but if that DLL had previously done something that "pinned" it (like a running thread or a timer), the unload can appear to succeed while the DLL's code is still in use — leading to a crash when the pinned code later tries to access DLL resources that were freed.
The core idea: a DLL's "reference count" (how many times LoadLibrary was called) can reach zero, making it eligible for unloading, even though internal Windows mechanisms (threads, callbacks, queued APCs, timers) still hold references to its code. The first post gave the classic case (a DLL's worker thread still running). This post gives a more exotic one: a DLL's timer callback was still queued in the system's timer queue, so it fired after the DLL was "unloaded," accessing freed memory.