How Windows finds a DLL
When a program asks for a library by name, something has to turn that name into a file on disk. That resolution step is where the genuinely hard DLL problems live: not "no file was found", but "the wrong file was found and it loaded successfully".
Why a search order exists at all
Imports name a library, not a path. That indirection is what makes a system update able to replace a library under every program at once — and it is also what makes it possible for a different file with the same name to be picked up instead.
Why two programs can load different copies
Two processes on one machine can each load a library of the same name from a different place, because the search is performed per process, in a context the process itself can influence. A bug that reproduces for one user and not another is very often this.
What this page will cover in full
- The default search order, step by step, and which steps a process can remove
- Known DLLs: the set the system refuses to resolve from anywhere else
- Side-by-side assemblies and activation contexts
- Application-local libraries, and manifests that force them
- The load-library search flags, and what a wrong one does quietly
- How to record what was actually loaded, rather than reasoning about what should have been