how to monitor exe and dll interactions?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello everyone,


Are there any tool or other methods which could be used to monitor which
class/method exe is accessing a DLL?

Now I met with an issue that when I provide the DLL I developed to a 3rd
parth application, it will crash sometimes and I suspect the 3rd party
application is invoking some class/method which I do not implement the DLL. I
have the full source codes of the DLL, but has no source codes of the exe so
I am wondering whether there are some methods to monitor the interactions --
e.g. I can monitor which class/method the exe is invoking and at the same
time my DLL has not implemented.

I am using Visual Studio 2005 to develop native (unmanaged) C++ DLL, and I
expose the interface of the DLL to exe through COM interface.


thanks in advance,
George
 
Are there any tool or other methods which could be used to monitor which
class/method exe is accessing a DLL?
Click to expand...

A debugger.

The SysInternals Process Explorer tool can tell you which processes
have a DLL loaded.
Now I met with an issue that when I provide the DLL I developed to a 3rd
parth application, it will crash sometimes
Click to expand...

What sort of crash?
I am wondering whether there are some methods to monitor the interactions --
e.g. I can monitor which class/method the exe is invoking and at the same
time my DLL has not implemented.
I am using Visual Studio 2005 to develop native (unmanaged) C++ DLL, and I
expose the interface of the DLL to exe through COM interface.
Click to expand...

If you've got dummy methods that you fear are being called by the
other application, add some diagnostic logging so you have a better
idea what's going on.

Dave
 
Hi David,


What do you mean *debugger* and *The SysInternals Process Explorer tool*?
Something in Visual Studio 2005?


regards,
George
 
David Lowndes said:
A debugger.

The SysInternals Process Explorer tool can tell you which processes
have a DLL loaded.


What sort of crash?


If you've got dummy methods that you fear are being called by the
other application, add some diagnostic logging so you have a better
idea what's going on.
Click to expand...

For example, force all your dummy functions to call DebugBreak.
 
Thanks Ben,


Your solution does not work for me. Because in my situation, I do not have
the non-implemented methods -- even an empty skeleton with a single return
statement. So, I do not have a function to set a break point or break
activelt using DebugBreak.


regards,
George
 
Thanks Dave,


I have downloaded process monitor tool and it looks great! So many cool
figures and dynamic. :-)

For my original question, I think it should be better that I solve it by
myself mostly from my own efforts, but to tell the truth I have no experience
of this tool and it is highly appreciated if you could give me some start
point of this tool, e.g. which menu and which function item I should use from
this tool to monitor the interactions between EXE and COM DLL. Then, from
your directed start point, I will do some research work by myself to make my
hands dirty.


regards,
George
 
For my original question, I think it should be better that I solve it by
myself mostly from my own efforts, but to tell the truth I have no experience
of this tool and it is highly appreciated if you could give me some start
point of this tool, e.g. which menu and which function item I should use from
this tool to monitor the interactions between EXE and COM DLL.
Click to expand...

I won't let you monitor the interactions of your COM DLL, but it will
let you find which processes have it loaded - use the Find menu item
to find the name of your DLL and it'll show any processes that
currently have it loaded.

Dave
 
George said:
Thanks Ben,


Your solution does not work for me. Because in my situation, I do not have
the non-implemented methods -- even an empty skeleton with a single return
statement. So, I do not have a function to set a break point or break
activelt using DebugBreak.
Click to expand...

What does exist? There must be something... because if the function didn't
exist at all there would be no way to compile a call to it.

So what does this non-implemented method look like? A coclass that doesn't
implement a particular interface (break on the failure path of
IUnknown::QueryInterface)? A dispinterface with some DISPIDs not
implemented (break on the failure path of IDispatch::Invoke)?
 
Thanks Dave,


I have tried with process explorer, but it could only get the list of the
DLL which is loaded by an EXE, and can not monitor the interactions between
EXE and DLL (e.g. function call), right?


regards,
George
 
Thanks Ben,


There are some optional interface, which I do not implement (means no
skeleton functions -- e.g. only a return value in implementation body).

Have I made myself understood? Any comments?


regards,
George
 
George said:
Thanks Ben,


There are some optional interface, which I do not implement (means no
skeleton functions -- e.g. only a return value in implementation body).

Have I made myself understood? Any comments?
Click to expand...

If you are not implementing an optional interface, then you return failure
from IUnknown::QueryInterface when that IID is requested, correct?
Therefore just make QueryInterface write a log message or call
OutputDebugString when it sees an unsupported IID, then you can find out
which interfaces the application is trying to use.
 
Thanks Ben,


Seems that some implementation of the methods are not correct, since all the
IID are implemented in QueryInterface.


regards,
George
 
Back
Top