Why should I even bother to use DLL's in my system?

re: Why should I even bother to use DLL's in my system?

John Sands — Wed, 07 Jul 2004 01:44:00 GMT

Am I right in assuming that the OS knows it's the same DLL because it's loaded from the same location on disk? So a copy of the DLL in another location is treated like another DLL? How does this affect the decision whether to copy shared .NET assemblies into each exe's directory, or put them in a common location, like the GAC?

re: Why should I even bother to use DLL's in my system?

Simon — Wed, 07 Jul 2004 11:17:00 GMT

Curious on the same topic but somewhat unrelated can't you make it access the DLL's from a shadow volume copy made when the DLL is first accessed.

The file is then immediately replacable - you can then make available an API call to notify the system to reload the new DLL for any new processes - once done both the old and new processes are happy until you kill the old ones and restart them with the new DLL... At which point the system is in a similar state to if it was restarted.

re: Why should I even bother to use DLL's in my system?

Mike Dimmick — Wed, 07 Jul 2004 12:27:00 GMT

From my studies, it depends whether you load a DLL using an explicit path or whether you just provide the filename. Implicit loading through static imports or delay loading just uses the module name.

DLLs loaded using explicit paths are treated independently of each other, even if they have the same name. However, it appears that DLLs loaded using the name only will use the first DLL loaded with that name. Only if a DLL with that name is not already loaded will Windows then look for the DLL using the rules listed in the documentation for LoadLibrary.

This bit a poster on CodeProject's forums. He a number of web applications on the same server, one of which had a managed DLL called Security.dll. In another, he was using a .NET Framework feature (I forget which exactly) which required the cryptography DLL, which the framework loads using the old name - security.dll. Whether his application worked or not depended on which application started first.

The reason for this, I concluded, was that when the system tried to load security.dll for the second application, it discovered that the first app's security.dll was already loaded, and used that. That DLL didn't export the required entry point, so the framework threw a MissingMethodException. Surprising, to say the least.

IMO, the Framework should have a way to indicate whether the target of a DllImport is supposed to be a system DLL, and to load the DLL explicitly using the computed path if so. Yes, this stops the administrator being able to substitute a different DLL - but that opens you up to Trojan DLL attacks, precisely the point of the directory search changes in XP SP1 and Server 2003.

On the issue of shutting down apps versus replacing DLLs in place: what if you have a DLL which implements some features but, to cut down on working set and startup time, puts other features into another DLL. Say that we want to replace these DLLs. Say that an application has loaded A.DLL, but hasn't yet needed B.DLL. Our installer overwrites A.DLL and B.DLL, but our application keeps running with A.DLL (v1). Now the application uses the extended feature: A.DLL (v1) loads B.DLL (v2). We have a version mismatch. If the developers haven't explicitly guarded for this case, anything could happen. It's always recommended to upgrade DLLs as a matched set (e.g. MDAC, C run-time).

Shutting down the process is safer. Some processes critical to Windows security can't be shut down since there's no way to start them back up. For example, LSASS.EXE, the Local Security Authority subsystem, talks to the kernel security driver, ksecdd.sys, using a local RPC port - this allows the kernel to authenticate security principals. To prevent processes attaching to this port, the first thing LSASS does (IIRC - I might have this the wrong way round) is to create two new anonymous ports and tells the other half what they are. ksecdd then opens those anonymous ports, then both sides close and destroy the original port. If you stopped LSASS, there's no way for ksecdd to reconnect.

I may have some of the details on that wrong, since I'm doing it from memory. The details are in "Inside Windows 2000" by David Solomon and Mark Russinovich.

re: Why should I even bother to use DLL's in my system?

Mike Dimmick — Wed, 07 Jul 2004 12:37:00 GMT

Oh, and SysInternals' Process Explorer is a good tool for seeing what processes have a DLL loaded. The reason Larry has to reboot is that winmm.dll is loaded by the WinLogon process, which can't be shut down because it's too highly trusted. If WinLogon crashes, XP deliberately blue-screens.

There's a whole bunch of DLLs loaded into WinLogon which therefore can't be replaced on the fly.

re: Why should I even bother to use DLL's in my system?

Larry Osterman — Wed, 07 Jul 2004 14:43:00 GMT

Actually Mike, WINMM.DLL being loaded by winlogon isn't the issue. I originally thought that, and it turns out that I was wrong (you can try it on XP and see - try renaming winmm.dll on a running machine). In my case it's because on longhorn, a dll that's used by one of the known dll's (but that's not explicitly on the known dlls list) was changed to have a static link to winmm, and that static link caused winmm to be considered a known dll.

re: Why should I even bother to use DLL's in my system?

Cesar Eduardo Barros — Thu, 08 Jul 2004 16:29:00 GMT

Larry, why not using position independent code? Then it wouldn't need a base address (and would need a fixup only for things like vtables).

re: Why should I even bother to use DLL's in my system?

Larry Osterman — Thu, 08 Jul 2004 16:45:00 GMT

That is an option Cesar, but it's my understanding that it's very very difficult to truely have position independent code - for instance C++ vtables are inherently position dependent, so that rules out using C++.

What are Known DLLs anyway?

Larry Osterman's WebLog — Mon, 19 Jul 2004 22:23:00 GMT

How did Windows 95 rebase DLLs?

The Old New Thing — Fri, 17 Dec 2004 18:00:00 GMT

Instead of doing it en masse, Windows 95 did it incrementally.