 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / November 2007how to monitor exe and dll interactions?
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? 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 Hi David, What do you mean *debugger* and *The SysInternals Process Explorer tool*? Something in Visual Studio 2005? regards, George > >Are there any tool or other methods which could be used to monitor which > >class/method exe is accessing a DLL? [quoted text clipped - 20 lines] > > Dave >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/sysinternals/default.mspx Dave 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 > >What do you mean *debugger* and *The SysInternals Process Explorer tool*? > >Something in Visual Studio 2005? [quoted text clipped - 8 lines] > > Dave >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 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 > >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 [quoted text clipped - 8 lines] > > 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? 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 > >Are there any tool or other methods which could be used to monitor which >>class/method exe is accessing a DLL? [quoted text clipped - 19 lines] > 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 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 > > >Are there any tool or other methods which could be used to monitor which > >>class/method exe is accessing a DLL? [quoted text clipped - 23 lines] > > > Dave > 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 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 > > Thanks Ben, > > [quoted text clipped - 13 lines] > > 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? 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 [quoted text clipped - 20 lines] >> > regards, >> > George Thanks Ben, Seems that some implementation of the methods are not correct, since all the IID are implemented in QueryInterface. regards, George > > Thanks Ben, > > [quoted text clipped - 33 lines] > >> > regards, > >> > George
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.