The DLL that was not present in memory despite not being formally unloaded
Raymond Chen explains a debugging scenario where a DLL appeared missing from memory even though it had never been formally unloaded. The culprit was a Windows feature that automatically unloads DLLs with no loaded resources after a period of inactivity, which can surprise developers who expected the DLL to persist.
Background
- Raymond Chen is a veteran Microsoft developer who has written the "The Old New Thing" blog since 2003, focusing on deep Windows internals and obscure system behaviors.
- This post describes a debugging scenario where a DLL appeared to vanish from memory without ever being formally unloaded — a phenomenon rooted in how Windows manages memory-mapped executable images.
- Key context: Windows uses **memory-mapped files** for DLLs; the OS maps a DLL into a process's address space, and when all references to that mapping are released, the system may **evict the underlying pages** without triggering a formal DLL unload (FreeLibrary). The DLL's code can thus be paged out even while the process still "holds" a reference to it, causing a crash or odd state that looks like the DLL was removed.
- This illustrates the difference between a DLL being "loaded" (its mapping exists in the process's working set) and its data being "present in physical memory" — a nuance critical for low-level debugging but opaque to most developers.