The case of the DLL that was not present in memory despite not being formally unloaded, part 1
Raymond Chen investigates a mystery where a DLL disappeared from memory without being formally unloaded. The article begins a deep dive into how Windows manages module references, examining possible causes like explicit FreeLibrary calls, reference count issues, or unexpected thread detachments. This first installment sets the stage for diagnosing the missing DLL.
Background
- Raymond Chen writes "The Old New Thing" (devblogs.microsoft.com/oldnewthing), a long-running blog that dissects weird, real-world bugs inside Windows—often obscure issues that only expert developers encounter but that reveal deep truths about how the OS works internally.
- This post is part of a multi-part series. It describes a mysterious crash where a DLL (a Dynamic Link Library—a shared code module that Windows loads into a process on demand) vanishes from memory even though the program never called FreeLibrary (the normal way to unload a DLL). The author traces how the DLL could have been evicted without a formal unload.
- Relevant background: Windows loads DLLs into the address space of a process; each load increments a reference count. Unloading requires the count to hit zero. If it disappears without hitting zero, something unconventional is at play—like a forced code removal or a memory-corruption issue.
- Target reader: Windows developers and programmers debugging similar crashes; assumes familiarity with process memory, DLL loading, and reference counting.