DLL dependency analyzer

I have a bunch of projects that reference eachother's dll's through the use of import statements. I'm looking for a dependency analyzer tool that will show me these dependencies.

So far, I've tried Lattix LDM, which shows me the dependencies between h files and c files within a single project but not the inter-project dll dependencies.

I've dried dll analyzer tools such as Dependency walker, and PE Explorer, but these only show references to system and windows dll's. It does not show the ones referenced by import statements.

Does anyone know of a good tool? Your help is greatly appreciated.

Quote:

---

I'm looking for a dependency analyzer tool that will show me these dependencies.

---

You can find it in

• C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\Bin\depends.exe
• dependency walker

It's the same.

Oh, I didn't know it was part of visual studio. But like I said, dependency walker doesn't show me what I need. Do you know of any other tools that might?

If dependency walker does not show it, it means it is not implicitly linked.

BTW, did you mention, those referenced by #import or #pragma. Just trying to confirm.
If you did mention #import, then sorry, you are out of luck. #import are used for COM dlls and these are not implicitly linked but loaded at runtime on demand when a CoCreateInstance is done on the class. So, they DO NOT show up as dependencies.

Quote:

---

Originally Posted by Chris256

Oh, I didn't know it was part of visual studio. But like I said, dependency walker doesn't show me what I need. Do you know of any other tools that might?

---

I apologize. I guess I did not read all your post. What you want is not possible. You want to see the dependencies on DLL loaded with LoadLibrary, right? That's not possible.

Imagine you write a program an input the name of the DLL that you later load with LoadLibrary(). How can a tool show those names.

However, if you are desperate about this, you can look into the executable in the data section for strings. Strings passed to LoadLibrary, like

Code:

---

LoadLibrary("mydll.dll");

---

will show up in that data section. Perhaps you can identify them. BTW, you can use a PE explorer/viewer to have a better look on your executable sections.

Quote:

---

Originally Posted by cilu

will show up in that data section. Perhaps you can identify them. BTW, you can use a PE explorer/viewer to have a better look on your executable sections.

---

That wouldn't still account for COM dlls loaded via CoCreateInstance.

To OP. Is there a specific problem you are facing now ?

Quote:

---

Originally Posted by kirants

That wouldn't still account for COM dlls loaded via CoCreateInstance.

---

Of course. I said for LoadLibrary(). ;)

Thanks for your help guys, this discussion has been helpful.

So basically, the impression I'm getting here is the following. I cannot do this with a static code analysis tool. I basically have to text search the code for strings that end with ".dll" and ".exe" or search for import statements. Is this a fair conclusion? Is there anything else I could investigate before resorting to this?

Quote:

---

Originally Posted by Chris256

So basically, the impression I'm getting here is the following. I cannot do this with a static code analysis tool.

---

Yes.

Quote:

---

I basically have to text search the code for strings that end with ".dll" and ".exe" or

---

Fair enough. But not enough. You should rather look for LoadLibrary. Because, the parameter passed to LoadLibrary is what is important and it can come from a variable instead of a hard coded static string like "blahblah.dll".

Quote:

---

search for import statements.

---

Fair enough.

Quote:

---

Is this a fair conclusion? Is there anything else I could investigate before resorting to this?

---

No. This will only make sure of dlls loaded by your code ( for which you have sources ). There are infinite ways of loading dlls.. some explicitly , some implicitly. But, if you are concerned only about those that are shipped by you, that checklist can probably catch 95% of the cases.

Anyways, am not clear what you are trying to do. I mean, what is your final goal ?

Another way might be to attach Developer Studio to the process. The output window should show you all the DLL's currently in use by the process.

Viggy

...and another one is to enumerate process modules at runtime.

Unfortunately, there's no fault-proof way to detect all modules you need since some of them may be loaded dynamically and in very, very rare case (for example, platform-dependent APIs).

BTW, such problem you face with when installer project must be built. And missed modules can be detected only by thorough installer testing procedure. :D

Why didnot using dynamic tool?