Finding external calls in a C++ dll

Question

We currently use a hardware driver's DLL for a particular piece of hardware we interface with. However, we also have an old internally developed DLL written with VC++ around 2002 that wraps that DLL for a few core functions. This code has been long lost, and was developed well before I came on the scene. So, it cannot be supported or even viewed in the case of a failure. We're trying to cut out the middleman by accessing the driver directly from our C#.NET application.

I do know this DLL simply wraps the hardware vendor's DLL, but the method signatures do not equal up. It looks like it is calling multiple driver functions in the single method. My question is this: how would I be able to view all the external calls this wrapper DLL is making to the driver DLL for this particular function? I'm not concerned about any of the other code; I'm fairly certain I can deduce that if I can just figure out the calls it's making to the driver.

Edit: A more concise explanation (that is made up)...

Driver.dll has a function called StartAcquisition(int, string). It also has a variety of setup functions.

Wrapper.dll has a function called StartAcquisition(int, string, double, int).

I suspect Wrapper.dll is calling Driver.dll's StartAcquisition(int, string) in addition to a few other calls (likely those setup functions). I want to know what those other calls could be.

Answer 1

DLL export viewer

Answer 2

I think that PE.Explorer might help you.

Even if it doesn't list it directly, you can still get the dissassembly and check for import tables mapping. Maybe by pairing this tool with another one like Windbg or OllyDbg you might get interesting results.

Any tool that can help you WILL have to deal with dissassembly. With the current Portable Executable format (PE), there are explicit sections for imports/exports. To map these tables with code needs some kind of interpretation, that's why I don't think a tool that does it straight away exists.

Answer 3

You could try a disassembler like IDA Pro (http://www.hex-rays.com/idapro/).

Answer 4

It looks like you will have to build your own little utility to find and disassemble existing programs, and then use your favorite utility to scan the output text and search for your call. I hope you don't have to, but it might be faster than finding an utility that already does that.

Answer 5

If you have access to the interface of the vendor DLL, you could build your own mock replacement library and put it in the path so the legacy DLL come to use it. The mock library would do nothing and just report when any of the exports was called and when.