how to monitor exe and dll interactions?

Well, if you're providing an exported interface to a client, you should be implementing it in the DLL.

To answer your question, the only way I know of would be to search the source code for the EXE. I don't know of any tool that can provide this information.

Viggy

I have the full source codes of the DLL, but has no source codes of the exeThen sorry, you can have only faceless return addresses of the caller side. The symbolic names get lost while linking. Well, exe map file could help you a bit, but I suspect you have no one, right? :)

Thanks Igor,

Then sorry, you can have only faceless return addresses of the caller side. The symbolic names get lost while linking. Well, exe map file could help you a bit, but I suspect you have no one, right? :)

What is the exe map file?

regards,
George

Not sure if this tool can help you to figure out, since this is COM DLL, and not native DLL.
But you can give it a try: Dependency Walker.

I recommend you downloading latest version from www.dependencywalker.com

Well, since this is the in-proc COM dll case, you always can debug the dll by setting breakpoints at non-implemented methods' returns. Then after return you may see if it gets crashed.

Another point is to debug objects QueryInterface for interfaces queried - mayby you're not providing some vital interface the app requires for. Though an interface abcense typically never gives an effect of crashing.

I can understand your points. But my situation is, 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. ;) Well, then I badly understand your situation. Or you're missing somewhat in your description that really matters to the issue. Or your trouble is not missed impelmentation but faulty one. ;)

I have set a breakpoint in CreateInstance, and all returns of DllGetClassObject and CreateInstance of class factory returns successful. I think it means all the required interfaces are implemented, right? Well, generally it doesn't, sorry. It's hard to say something certain being knowing nothing about your component.

So, I think the issue is that some required method is missing, not required interface. Any comments?The comment would be only one. You just cannot have a situation of "that some required method is missing". Until you implement your interface completely you never can build your COM module.

I appreciate your help all the way. ;) You're welcome. :)

I want to confirm with you that the only solution you could see is to implement all the required methods, and even leave an empty implementation to the methods -- other than leave nothing (no empty implementation)?Well, you could put my point this way, though this is not what I could see, but the only choice I would have - because of COM nature. :D

And there is no tool to monitor the interactions (e.g. which method is invoked from EXE to DLL)? Right?At least I 'm not aware of the one. Why should anybody intercept the calls to his own component? As I said, you always can run the app in debugger session and set breakpoints or simply trace the calls. :)

Nevertheless, this is the article (http://www.microsoft.com/mSJ/0199/intercept/intercept.aspx) that might help to take a bit more deeper look into the problem... ;)