Is there a .dll dependency scanner that will...

  • Thread starter Thread starter Andreas Perfora’tus [Stu]
  • Start date Start date
A

Andreas Perfora’tus [Stu]

scan ALL program files and make note of any referenced dll's that do not
exist on my system?

I have "dependency walker" but it only scans one .exe at a time. Surely
there must be something similar that would scan the entire system like
DLLArchive by analogueX but finds missing dlls instead of unused ones.

thanks ACF for all the help - past, present and future.
 
Andreas said:
scan ALL program files and make note of any referenced dll's that do not
exist on my system?
I have "dependency walker" but it only scans one .exe at a time. Surely
there must be something similar that would scan the entire system like
DLLArchive by analogueX but finds missing dlls instead of unused ones.
thanks ACF for all the help - past, present and future.
Click to expand...

It's entirely likely that any programs which can't find a referenced
..dll file won't run anyway. Are you referring to .dll files that are
referenced in your registry maybe?
 
It's entirely likely that any programs which can't find a referenced
.dll file won't run anyway. Are you referring to .dll files that are
referenced in your registry maybe?
Click to expand...

You're right. Some programs won't run at all when a .dll is missing. For
example, 1337player did nothing after installing it. Dependency Walker
showed the missing .dlls and after locating them 1337player ran perfectly.

However, Zoomplayer, for example, would run. But it would crash
occasionaly. So I ran Dependency Walker on it and found missing .dlls for
it. I located them and put them in my system directory and the crashes
stopped completely.

That was what led me to wonder how many other programs might actually be
missing a .dll or two that may only cause seemingly random crashes. But to
have to check every one manually with Dependency Walker...
 
Andreas said:
You're right. Some programs won't run at all when a .dll is missing. For
example, 1337player did nothing after installing it. Dependency Walker
showed the missing .dlls and after locating them 1337player ran perfectly.
However, Zoomplayer, for example, would run. But it would crash
occasionaly. So I ran Dependency Walker on it and found missing .dlls for
it. I located them and put them in my system directory and the crashes
stopped completely.
That was what led me to wonder how many other programs might actually be
missing a .dll or two that may only cause seemingly random crashes. But to
have to check every one manually with Dependency Walker...
Click to expand...

Note though (and I'm sure you're aware of this) Dependency Walker (I'm
using ver. 2.1.2519) only works for 32 and 64 bit modules. There used
to be a program some guy in France wrote that kinda handled 16 bit
programs. Can't remember it's name. Came with a real good help file
that was a tutorial in programming almost or something kinda. Dunno
why I lost that program. It was a real good one.
 
Note though (and I'm sure you're aware of this) Dependency Walker (I'm
using ver. 2.1.2519) only works for 32 and 64 bit modules. There used
to be a program some guy in France wrote that kinda handled 16 bit
programs. Can't remember it's name. Came with a real good help file
that was a tutorial in programming almost or something kinda. Dunno
why I lost that program. It was a real good one.
Click to expand...

Thanks for the tip, John. I'll poke around and see if I can locate a 16-bit
program. Seems to me I recall having one once-upon-a-time also. I'll let
you know if I find a good one. :)
 
Thanks for the tip, John. I'll poke around and see if I can locate a
16-bit program. Seems to me I recall having one once-upon-a-time also.
I'll let you know if I find a good one. :)
Click to expand...

Ok, here's the first one I've found. It is the one I was thinking of.

Find DLLs 63790 bytes 20.05.1996

FDDLLS - helps you find unused DLLs on your system by finding, sorting and
classifying Windows executable files. FDDLLS can list the EXE and DLL files
on your system by name, extension or reference count. Uploader: Rene Upraus

Information page with screenshots:
http://www.keyscreen.com/KeyScreen(s)4/fddlls.htm

Working Download Link Page:
http://www.aco.ee/files/winutils/diagnost-size.html

Direct Download Link:
http://www.aco.ee/files/winutils/fddlls.arj
 
Thanks for the tip, John. I'll poke around and see if I can locate a
16-bit program. Seems to me I recall having one once-upon-a-time also.
I'll let you know if I find a good one. :)
Click to expand...

Another I had in mind was GoRefs. Not sure if it does 16 bit apps though.
Can't seem to find one on my system to check it at present. :)

goRefs, version 1.3, gorefs.zip, 110K

Any program for Windows is an EXE file (executable) plus several DLLs
(program extensions). Each DLL in turn refers to other DLLs, etc. etc. When
one starts a program, Windows loader analyses this dependency tree, finds
all the necessary modules and, if everything is found, loads them into a
new process memory and begins the program execution.
goRefs imitates this dependency resolution process without actually
loading any code. It shows you what is needed for a given program and where
it will be found.

http://home.eol.ca/~andgur/software/devel.html
 
Andreas said:
Ok, here's the first one I've found. It is the one I was thinking of.

Find DLLs 63790 bytes 20.05.1996

FDDLLS - helps you find unused DLLs on your system by finding, sorting and
classifying Windows executable files. FDDLLS can list the EXE and DLL files
on your system by name, extension or reference count. Uploader: Rene Upraus

Information page with screenshots:
http://www.keyscreen.com/KeyScreen(s)4/fddlls.htm

Working Download Link Page:
http://www.aco.ee/files/winutils/diagnost-size.html

Direct Download Link:
http://www.aco.ee/files/winutils/fddlls.arj
Click to expand...

That was a good program too, but isn't the one I was talking about. It
does find duplicate .dll files and labels them as being referred to or
not.
However,thanks to Google. I just did a search and found the program
I was referring to. It's called "Scanbin" and was written by Jean
Claude Bellamy. It's located here:

http://members.aol.com/bellamyjc/en/scanbin.html
 
That was a good program too, but isn't the one I was talking about. It
does find duplicate .dll files and labels them as being referred to or
not.
However,thanks to Google. I just did a search and found the program
I was referring to. It's called "Scanbin" and was written by Jean
Claude Bellamy. It's located here:

http://members.aol.com/bellamyjc/en/scanbin.html
Click to expand...

Great. Thanks very much.

Oh, and btw, not that it matters now, I found out though testing
WinFile.exe that GoRefs does NOT handle 16-bit apps.
 
On that special day, John Corliss, (jcorliss@secrewspam.to#) said...
However,thanks to Google. I just did a search and found the program
I was referring to. It's called "Scanbin" and was written by Jean
Claude Bellamy. It's located here:

http://members.aol.com/bellamyjc/en/scanbin.html
Click to expand...

I dug out a *very* old backup CD which contains programs for my old Win
3.1, which all had been collecxted on an old 486 machine with a DX 33
processor.

Among the system tools I found things with names like

ZAP
ZAP.EXE - Duplicate DLL and VBX locator

FDDLLS
FDDLLS helps you find unused DLLs on your system by finding, sorting and
classifying Windows executable files. FDDLLS can list the EXE and DLL
files on your system by name, extension or reference count.

CLNSYS
Clean System Directory - v1.5
This program scans your system looking for
all references to DLL files in your Windows
system directory. Those DLL files in the
system directory that have no programs
calling on them can be moved out of the
system directory, saving disk space and
improving system performance. For
experienced users. Win 3.1 & Win 95

If any is requested, I can easily send them, they are all very small.


Gabriele Neukam

(e-mail address removed)
 
CLNSYS
Clean System Directory - v1.5
Click to expand...
Those DLL files in the
system directory that have no programs
calling on them can be moved out of the
system directory, saving disk space and
improving system performance.
Click to expand...

Aren't some DLLs called "dynamically"...and hence aren't listable in this
way? I've always been confused on this.

Here's what is says in Dependency Walker:

"Dependency Walker version 2.0 adds application profiling, a technique
used to watch a running application to see what modules it loads. This
allows Dependency Walker to detect dynamically loaded modules that are
not necessarily reported in any on the import tables of other modules."

So I'm curious how effective programs like CLNSYS would be if they don't
include application profiling. Any insight on this?
 
On that special day, jason, (me@privacy.net) said...
"Dependency Walker version 2.0 adds application profiling, a technique
used to watch a running application to see what modules it loads. This
allows Dependency Walker to detect dynamically loaded modules that are
not necessarily reported in any on the import tables of other modules."

So I'm curious how effective programs like CLNSYS would be if they don't
include application profiling. Any insight on this?
Click to expand...

Sorry, but I can't really tell. Until now, I had believed that
"dynamical loading" does mean, a dll file isn't loaded at the start time
of a given application, but only whern it is really needed, and that the
reference to the dll which is meant to be loaded only when needed, is
still stored in the exe file of the application. So, if you scan an
exefile for dll and vbx entries, you will still find these, be them
loaded at once or later on.

Of course, any given loaded module/dll/vbx may load more related
libraries, which again would have to be scanned for, and several of the
most basic modules of Windows are referencing each other, so if you
aren't careful enough, using the method described above, might cause the
program to track the references in a never ending loop.

Why should a program only check for modules that are loaded, while the
application is running? It doesn't make much sense.

Think of Office. You open word, and write a letter, and have Dependency
Walker log, what Word is calling for. Fine. But by now, Dependency
Walker has listed only *part* of what Word really needs.

Imagine that at the next time, you might open Word and use it to create
a Children's Birthday Invitation (as you don't have Powerpoint), and of
course insert some pictures, and print in landscape mode. Suddenly, Word
uses a very different set of libraries.

If you had relied on the information given by "Word used only these
libraries for the letter", and had deleted all the rest, some of the
functions which are called by changing the apperance of the text,
inserting graphics, and printing in landscape, might not work, because
the supporting libraries had been removed. This is surely not what you
want.

I wouldn't rely on the information what is *currently* loaded. It isn't
worth risking the system's integrity.


Gabriele Neukam

(e-mail address removed)
 
Gabriele said:
On that special day, jason, (me@privacy.net) said...


Sorry, but I can't really tell. Until now, I had believed that
"dynamical loading" does mean, a dll file isn't loaded at the start time
of a given application, but only whern it is really needed, and that the
reference to the dll which is meant to be loaded only when needed, is
still stored in the exe file of the application. So, if you scan an
exefile for dll and vbx entries, you will still find these, be them
loaded at once or later on.

Of course, any given loaded module/dll/vbx may load more related
libraries, which again would have to be scanned for, and several of the
most basic modules of Windows are referencing each other, so if you
aren't careful enough, using the method described above, might cause the
program to track the references in a never ending loop.

Why should a program only check for modules that are loaded, while the
application is running? It doesn't make much sense.

Think of Office. You open word, and write a letter, and have Dependency
Walker log, what Word is calling for. Fine. But by now, Dependency
Walker has listed only *part* of what Word really needs.

Imagine that at the next time, you might open Word and use it to create
a Children's Birthday Invitation (as you don't have Powerpoint), and of
course insert some pictures, and print in landscape mode. Suddenly, Word
uses a very different set of libraries.

If you had relied on the information given by "Word used only these
libraries for the letter", and had deleted all the rest, some of the
functions which are called by changing the apperance of the text,
inserting graphics, and printing in landscape, might not work, because
the supporting libraries had been removed. This is surely not what you
want.

I wouldn't rely on the information what is *currently* loaded. It isn't
worth risking the system's integrity.
Click to expand...

Neither solution is fool-proof, that's why dependency walker contains
both techniques.

I'll try to give an overview (and keep this fairly simple), but I am
ignoring some of the details.

DLL's are dynamically loaded, as the name implies. Originally (early
days of windows), there was no information in the program "header"
telling you that it would need a particular DLL. More recent versions
of windows and programming tools allow for putting DLL names into the
program header (import table) so that the system can tell what DLLs
will be used. Dependency walker uses that information to make the DLL
listing. Dependency walker then looks at the header for each DLL and
does the same thing all over again, recursing down (but being careful
to avoid that infinite loop you mentioned).

But there are older programs (and older programming tools) that don't
list dlls in the header. Also, there are times when you don't want to
list the DLLs - for example, if you want to have an "optional" dll,
kind of a plug-in, that you only reference and load when its use is
actually required. If the dll is missing, you can throw up an error
message (like "you didn't pay for that optional feature, so I can't do
that for you"). Or you can disable or hide certain program features if
that dll is missing.

That's why dependncy walker has the option to monitor a program's
execution to see what dlls are actully used. You're right, this is
only as useful as your ability to exercise *all* parts of a program,
so it has its limits. But it can be useful, particularly to a
programmer who may know something about how the program was written.

Because of this, there is no *certain* way to tell if a particular DLL
is unused and can be safely deleted. IMO it's not worth the trouble to
try to do so -- disk space is cheap. If you are concerned about rogue
dlls on your system, look to programs such as adaware or spybot. Or do
a clean windows install.

Terry
 
On Thu, 4 Dec 2003 22:55:20 +0100, Gabriele Neukam wrote:

["Dependency Walker & profiling]
Until now, I had believed that "dynamical loading" does mean, a dll file
isn't loaded at the start time of a given application, but only whern
it is really needed, and that the reference to the dll which is meant
to be loaded only when needed, is still stored in the exe file of the
application. So, if you scan an exefile for dll and vbx entries, you
will still find these, be them loaded at once or later on.
Click to expand...

In most cases, all needed dynamic link libraries are referenced within
the import table. There is a translation scheme to ensure correct calls
of the functions listed there. So if for instance a newer version of
a library has some internal changes - everything should go right,
nevertheless.

But a software developer can call every function by ordinal number
right from within the code, too. If he does, you can only find out
about it by disassembling the code or via profiling. You will find
this kind of functions calls mostly within (good or bad) security
concerned circumstances...
Think of Office. You open word, and write a letter, and have Dependency
Walker log, what Word is calling for. Fine. But by now, Dependency
Walker has listed only *part* of what Word really needs.
Click to expand...

You are right. Profiling can only show you what's actually going on.
So you can be sure sth. is fishy if you see it happen. But you can't
be sure that everything is *always* ok if you don't see bad things
right now.

BeAr
 
Terry said:
I'll try to give an overview (and keep this fairly simple), but I am
ignoring some of the details.
Click to expand...

Because of this, there is no *certain* way to tell if a particular DLL
is unused and can be safely deleted. IMO it's not worth the trouble to
try to do so -- disk space is cheap.
Click to expand...

That's the conclusion I had tentatively come to, but I was wondering if I
was being overly conservative. Based on your description, apparently not.
Thanks for the detailed explanation.
 
Terry Orchard said:
DLL's are dynamically loaded, as the name implies. Originally (early
days of windows), there was no information in the program "header"
telling you that it would need a particular DLL. More recent versions
of windows and programming tools allow for putting DLL names into the
program header (import table) so that the system can tell what DLLs
will be used. Dependency walker uses that information to make the DLL
listing. Dependency walker then looks at the header for each DLL and
does the same thing all over again, recursing down (but being careful
to avoid that infinite loop you mentioned).

But there are older programs (and older programming tools) that don't
list dlls in the header. Also, there are times when you don't want to
list the DLLs - for example, if you want to have an "optional" dll,
kind of a plug-in, that you only reference and load when its use is
actually required. If the dll is missing, you can throw up an error
message (like "you didn't pay for that optional feature, so I can't do
that for you"). Or you can disable or hide certain program features if
that dll is missing.

That's why dependncy walker has the option to monitor a program's
execution to see what dlls are actully used. You're right, this is
only as useful as your ability to exercise *all* parts of a program,
so it has its limits. But it can be useful, particularly to a
programmer who may know something about how the program was written.

Because of this, there is no *certain* way to tell if a particular DLL
is unused and can be safely deleted. IMO it's not worth the trouble to
try to do so -- disk space is cheap. If you are concerned about rogue
dlls on your system, look to programs such as adaware or spybot. Or do
a clean windows install.
Click to expand...

Terry's answer pretty much sums it up.

All Windows modules contain an import table that lists the modules
they require to load. If any of these modules are missing or bad,
then the module that imports them will fail to load. Newer modules
may also have a delayload import table. This is not something the OS
cares about, but it does tell programs like Dependency Walker what the
application might load at runtime.

When you first open a program in Dependency Walker, you will see every
dependency listed in both tables. There is no way to know more than
that without actually running the program to see if it decides to load
something not listed in the tables. That is where the profiling comes
into play. Profiling will watch the program and add modules to the
list. In the end, you get the most complete list that is possible,
but it still doesn't guarantee the program will never load something
different in the future. There is simply no way to determine this.

In the old days, most modules were loaded implicitly and showed up in
the import tables. Nowadays, it is mostly just core Windows modules
that are usually loaded this way. You will find a lot of modules
loaded at runtime via COM. These can only be found by the profiling
feature in Dependency Walker. VB and .NET apps almost exclusively
load all non-core DLLs this way.

- Steve
 
Back
Top