how to monitor exe and dll interactions?

[=?Utf-8?B?R2Vvcmdl?=]

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

[David Lowndes]

>Are there any tool or other methods which could be used to monitor which

>class/method exe is accessing a DLL?

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

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.

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

[=?Utf-8?B?R2Vvcmdl?=]

Hi David,
What do you mean *debugger* and *The SysInternals Process Explorer tool*?
Something in Visual Studio 2005?
regards,
George

"David Lowndes" wrote:

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

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

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.

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

[David Lowndes]

>What do you mean *debugger* and *The SysInternals Process Explorer tool*?

>Something in Visual Studio 2005?

VS2005 has the debugger integrated - just press F5 to run your program
under the debugger.

Process Explorer is one of the invaluable free tools supplied by
SysInternals (now part of MS).

http://www.microsoft.com/technet/sys...s/default.mspx

Dave

[Ben Voigt [C++ MVP]]

"David Lowndes" <Da****@example.invalidwrote in message
news:kn********************************@4ax.com...

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

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

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.

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.

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

>
Dave

[=?Utf-8?B?R2Vvcmdl?=]

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

"Ben Voigt [C++ MVP]" wrote:

>
"David Lowndes" <Da****@example.invalidwrote in message
news:kn********************************@4ax.com...

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

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

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.

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.

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

Dave

[=?Utf-8?B?R2Vvcmdl?=]

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

"David Lowndes" wrote:

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

VS2005 has the debugger integrated - just press F5 to run your program
under the debugger.

Process Explorer is one of the invaluable free tools supplied by
SysInternals (now part of MS).

http://www.microsoft.com/technet/sys...s/default.mspx

Dave

[David Lowndes]

>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.

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

[Ben Voigt [C++ MVP]]

"George" <Ge****@discussions.microsoft.comwrote in message
news:25**********************************@microsof t.com...

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.

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)?

>

regards,
George

[=?Utf-8?B?R2Vvcmdl?=]

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

"David Lowndes" wrote:

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.

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

[=?Utf-8?B?R2Vvcmdl?=]

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

"Ben Voigt [C++ MVP]" wrote:

>
"George" <Ge****@discussions.microsoft.comwrote in message
news:25**********************************@microsof t.com...

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.

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)?

regards,
George

[David Lowndes]

>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?

Yes.

It sounds like you need some sort of COM spy utility. The only one I
can immediately see is here:
http://staff.develop.com/jasonw/comspy/default.htm - but it doesn't
appear to be maintained :(

Dave

[Ben Voigt [C++ MVP]]

"George" <Ge****@discussions.microsoft.comwrote in message
news:52**********************************@microsof t.com...

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?

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.

>

regards,
George

"Ben Voigt [C++ MVP]" wrote:

>>
"George" <Ge****@discussions.microsoft.comwrote in message
news:25**********************************@microso ft.com...

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.

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)?

>

regards,
George

[=?Utf-8?B?R2Vvcmdl?=]

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

"Ben Voigt [C++ MVP]" wrote:

>
"George" <Ge****@discussions.microsoft.comwrote in message
news:52**********************************@microsof t.com...

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?

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.

regards,
George

"Ben Voigt [C++ MVP]" wrote:

>
"George" <Ge****@discussions.microsoft.comwrote in message
news:25**********************************@microsof t.com...
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.

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)?

regards,
George