Which function is being called by InvokeHelper

Question

In my code there is a function call to InvokeHelper. What I found on internet is that InvokeHelper is used to call a function by using dwDispID.

This is the call.

InvokeHelper(0xd, DISPATCH_METHOD, VT_DISPATCH, (void*)&pDispatch, parms, Name);

Now I want to debug inside. But I don't know which function will be called. 0xd is pointing to which function? There is odl file in project as well. Will this invoke some call from that odl? What function?

EDIT:

I found these lines on the top of cpp file.

// Machine generated IDispatch wrapper class(es) created by Microsoft Visual C++

// NOTE: Do not modify the contents of this file.  If this class is regenerated by
//  Microsoft Visual C++, your modifications will be overwritten.

So it looks like this class is wrapper. But wrapper of which class?

Answer 1

First you need to find the definition of the interface that you are calling and which implements IDispatch . If it is your own interface, it would be inside an .idl or .odl file within your project.

Inside the interface definition, each method will have a [DISPID] attribute with corresponding number. You need to find the one with id 0xD or 13. That is your method.

'Will this invoke some call from that odl?'

Yes, if the object on which you execute the call is an instance of a class defined in your ODL. It is hard to tell that without seeing your project, as it is unclear from your sample whether this is an 'external' object (ie defined and implemented elsewhere) or the one from your project.

However, in this case I would say it is a class external to your project, as you mentioned the generated wrapper class. This is created when you add an external COM library to your project - the wrapper conveniently wraps the COM calls into a C++ class.

Your InvokeHelper is already within some method - the name of that method is same as the name of the method on the IDispatch-derived interface which will eventually be called. Therefore, whether you can debug it depends on whether you have the code for the component.

Usually, the name of the generated wrapper can point to the name of the COM component that is wrapped but that is not always the case (it is always similar to the name of the COM class, but there can be multiple classes in the same COM server). To find out which COM class exactly this is, you could check the part of your wrapper header file with line like:

static CLSID const clsid 
  = { 0x9e3c8066, 0x7f88, 0x11d1, { 0xbb, 0x57, 0x44, 0x45, 0x53, 0x54, 0x0, 0x1 } };

This is CLSID of the underlying COM class, and you can look it up in registry to see exactly what is the ProgId of the class and in which dll/exe it is hosted. For more details see here .

First 4 chapters of 'Essential COM' provide great intro to what you need to know about COM to solve 90% of problems related to using COM components.

Answer 2

0xd points to a function that has a matching id in the .idl/.odl file. When a COM object supports IDispatch, each function gets a number like so:

[id(1), helpstring("method Test")] HRESULT Test([in] long number);

In your case, the function has the id of 13 (0xd hex). That is the function that will get "Invoked" at runtime.
You can't step into (debug) the function unless you have the source code and the .pdb files for both sides.

If this file is generated from MFC or from managed code with a runtime callable wrapper, there will be a proxy class created. Its name will be a fairly close match to the COM interface name in the original .idl file. That should give you a clue where the wrapper came from. Make sense?