Avoiding DLL torment

By: Bob Arnson

Abstract: DLL Hell is something all Windows developers go through. It's like a rite of passage. Here's how to make your DLL Hell more compassionate. By Bob Arnson.

Avoiding DLL torment

DLL Hell is something all Windows developers go through. It's like a rite of passage. Here's how to make your DLL Hell more compassionate.

Though many might like to pretend that "DLL Hell" is a problem suffered only by Visual Basic developers, you know in your heart it's not true. Any Delphi developer can tell you what happens if you deploy an application on a system with an older version of comctl32.dll. (Hint: Things break.) Developers who use ADO can work up a lather deciphering this paragraph from Microsoft's Universal Data Access Web site:

This Web release is the second Generally Available (GA) version of Microsoft Data Access Components (MDAC) 2.1 and is referred to as MDAC (GA). The MDAC (GA) release is also referred to as MDAC 2.1 SP2 in Microsoft Knowledge Base articles. Keep in mind that the original MDAC 2.1 was shipped with SQL Server 7.0, and a small incremented version was then shipped with Internet Explorer 5.0 (this was MDAC 2.1 without drivers or providers). Next MDAC (GA) was released to the web. Some articles might refer to this as MDAC 2.1 SP1. The most current release is and is a service pack to the MDAC 2.1 stack. There are no new features in this release. Verify you have MDAC by checking the file version property of Msado15.dll, which should be 2.10.4202.1.

Obviously, DLL Hell is alive and well. Luckily, there are tools out there to help us diagnose and even survive it.

Borland's TDUMP

The first set of such tools comes with your favorite development tool. Whether that's Delphi or Visual C++ or C++Builder, you have a tool that deciphers all the version information and other data embedded in your EXE and DLL files. Delphi and C++Builder, for example, come with TDUMP, a command-line utility that, as the name implies, dumps all the data about a given executable module (EXE, DLL, OCX, and so forth). By searching the TDUMP output for the Imports section report, you know which DLLs your program is linked to. However, TDUMP won't tell you the versions of those DLLs, nor will it dig deeper to tell you anything about the dependencies' dependencies. In other words, if a DLL that your program calls also calls yet another DLL, TDUMP won't tell you about the second DLL. TDUMP also doesn't note any DLLs that are loaded programmatically at runtime.

Microsoft's DUMPBIN and Dependency Walker

Microsoft development tools also come with such a utility, named DUMPBIN. Like TDUMP, it's a console app -- the only UI is command-line arguments, so you'll want to redirect the output to a file and open it in your favorite editor to see the results.

Microsoft tool users have another tool that's a bit more pleasant to use. Dependency Walker is a GUI app that comes with some editions of Visual Studio and Visual C++. Its user interface makes it much more pleasant to use than either DUMPBIN or TDUMP.

As you can see from the screen shot, there's no lack of information. In fact, there's too much information for most uses and Dependency Walker offers no way to turn off any of the panes -- you're limited to hiding and showing the toolbar and status bar.

The two most immediately useful panes are the tree view in the upper-left, which lists the modules hierarchically, and the list view immediately below it, which contains a flat list of all the modules. The tree view can get long, as it shows duplicate entries; the list view removes the duplicates.

After a bit of spelunking on Microsoft's MSDN Web site, I found a link to a page that offers a beta version of Dependency Walker that supports what it calls profiling, which in this means that Dependency Walker can run your application and detect DLLs that are loaded programmatically instead of specified at link time. The beta version of Dependency Walker seems stable but although there's a decent help file with it, there's no documentation about where one might find updates. Nor is there a license agreement, so I'm hesitant to recommend it to anybody, especially if you don't have a license (from Visual Studio, for example) for the released version.


ShowDep is a shareware (US$10 for a single-user license) utility that offers most of the features of the beta version of Dependency Walker and has more on top of it. ShowDep's user interface is a lot less cluttered than that of Dependency Walker, but that neatness comes at a small loss of functionality. For example:

Dependency Walker shows imports and exports in list views, which makes for easy sorting. ShowDep dumps most of its data into a rich edit control, which makes for easy cutting and pasting. Overall, sorting seems to be of more immediate value. 

The dependencies tree view on the left is configurable. ShowDep has toggles suppress core modules -- those like kernel32.dll and user32.dll that are always present and therefore aren't as likely to cause problems -- and to show dependencies as a hierarchy with duplicates or a flat list with duplicates removed. 

ShowDep has an option to "undecorate" (sometimes called unmangle) C++ function names. Unfortunately, it supports only Visual C++ undecorating. C++Builder users will see mangled names.

Unfortunately, ShowDep's shareware version is crippled. Reports, for example, can be saved, but contain the text Sorry, only registered users can save reports. I was surprised to see crippleware, especially with ShowDep's low price -- I thought that had died out in the late 80s. ShowDep can be registered online.

Not a cure

Note that TDUMP, DUMPBIN, Dependency Walker, and ShowDep won't fix any problems -- they're just tools that give you the information you need to make the fix yourself. Generally, it means that you know what versions of which DLLs you need and can make sure that your users have them.

Doing that is a whole other set of tools...

Server Response from: ETNASC04