This documentation is archived and is not being maintained.
Windows Confidential The Known DLLs Balancing Act
Raymond Chen's Web site, The Old New Thing, and identically titled book (Addison-Wesley, 2007) deal with Windows history and Win32 programming. He has no idea what his T-shirt size is anymore.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.
The Windows feature informally called "Known DLLs" refers to a list of DLLs (Dynamic Link Libraries) that are given special treatment by the kernel's module loader. When the loader sees a program with a load-time dynamic link to a known DLL, the known copy is used immediately, ignoring the search algorithm that normally applies to module loading. Some people might consider this a security feature (though an admittedly rather weak one), but in fact security was never the intent of this feature. Known DLLs was really all about performance.
The mechanics of the Known DLLs feature have changed over time. In some versions of Windows®, the kernel uses the list of known DLLs as a starting point, then looks at all the DLLs that those known DLLs link to, then all the DLLs that those DLLs link to, and so on. This process builds up the transitive closure of all the dependencies and treats them all as known. In other versions of Windows, this transitive closure is not built; instead, only DLLs listed explicitly as known are treated as known. In some versions of Windows, the known DLLs are preloaded by the kernel when the system starts; in other versions, no such preloading takes place and the kernel merely uses the list to save itself the trouble of having to search the path for a DLL.
It's not only the interpretation of the list of known DLLs that changes from version to version. The contents of the KnownDLLs registry key are also subject to change. The Windows performance team changes both the list of known DLLs and the rules by which the list is converted into a set of DLLs based on their understanding of how applications use Windows. As is typical in engineering, it's a game of trade-offs. Preloading known DLLs at system startup allows the applications using those DLLs to start up faster, but there is a price. It takes longer to start up the system, and memory consumption increases, since those DLLs remain in memory whether or not they are actually used. It's a game of improving the performance of some components at the cost of others. Striking the right balance is a difficult task and, as you can see, it's constantly being fine-tuned as the pattern of usage evolves.
One consequence of known DLLs that may not be readily obvious is that known DLLs take precedence over locally redirected DLLs. (We looked at locally redirected DLLs in the January 2007 edition of this column.) If you think about it, you may realize that this is actually expected behavior rather than a quirk. After all, the purpose of the list of known DLLs is to bypass the search path and thereby speed up DLL loading. If the kernel had to check for locally redirected DLLs, that would just slow things back down. You might think that adding just one directory to the search path would not be that big a deal, but when that one directory can be a network server halfway across the globe, adding even one directory can be an enormous performance drain.
Believe it or not, we've seen programs that rely on specific DLLs being known. There was one program that had a file called Version.dll in the application directory. Under normal rules, this private copy of Version.dll would override the one in the system directory, but in Windows XP, Version.dll is listed as a known DLL. This means that the copy in the application directory is ignored and the version in the system directory wins.
In Windows Vista®, Version.dll is no longer listed as a known DLL, probably because the performance folks determined that applications didn't use it enough to justify the cost. As a result, this program stopped working on Windows Vista because the application actually relied on the kernel ignoring the DLL that the program installed into its own application directory. The program was willfully installing a DLL onto the search path and then relying on Windows to ignore it! Surely if it wanted Windows to ignore a file, a much more efficient mechanism would simply be not to install the file in the first place. The kicker is that the company that wrote the program filed a bug claiming that it had found a security hole.