If you haven’t noticed, I am a big fan of reviving the fanfare of some of the older development tools that are out there. Of course, there are constantly new tools released to help developers work smarter, faster, and more effectively – but often with all of the excitement over these new tools we forget about old standbys.
Dependency Walker is a tool that when you need it, you really need it. The fact that it is a free, lightweight download which doesn’t require an install to run is just added bonus.
The DLL Problem
We use a third-party DLL in our primary project at work which interacts with Progress. The problem is on a fresh system install and run, you receive the following error:
The dreaded “Could not load file or assembly or one of its dependencies.” The key here is the dependencies portion. I know the Progress.ssl.dll exists and is in the right directory, it compiles correctly, but a dependency inside this DLL is affecting the runtime execution.
How do I know what the dependency is?
Dependency Walker to the Rescue
First, we need to download Dependency Walker – go here: http://dependencywalker.com
Pick the appropriate version for your OS and take in the great retro-vibe of the website; it shows a little age doesn’t it!
After the download, simply unzip it to any directory on your computer and run depends.exe. Next, open the DLL that you are struggling with (Progress.ssl.dll in my case).
Notice, the popup message and the yellow question marks next to DLL’s which have potential problems. In this particular case, MSVCR71.DLL is the culprit and needed to be copied into a directory in system path.
Here is another screenshot of the error for the DLL’s:
After you’ve attempted to resolve the issue (and this may be different each time based on the particular scenario), refresh Dependency Walker to see if the dependent DLL is corrected or simply try your .NET project again and see if it works properly. In my case, MSVCR71.DLL was all that was needed and we were back on track.
If you have other “tried and true” tools that you still use today, please add them to the comments so we can keep them alive and maybe help a developer out!
One thought on “Reviving Dependency Walker”
I’ve just become a fan of Dependency Walker overnight. Have had a nightmare time building an installer package for an old MFC application we have just updated to Visual Studio 2010, and which we are deploying on modern machines which have not heard of MFC.
By comparing our Dependency Walker readout of the DLL call chain with directory lists of which DLLs are actually installed by default on Vista, V64, W7 and W7-64, we have been able to determine exactly which distributables to package.
As far as I know, Dependency Walker is the only way to do this.