This is the code produced by the Module Wizard? The code I've generated in my cases doesn't explicitly use $VPTR and things like "$VPTR = $VTBL + 9 * INT_PTR_KIND() ! Add routine table offset" which contain an explicit offset.

Instead it looks like this
SUBROUTINE $DUMCBICONN2_EndSignalDevice($OBJECT, $STATUS)
IMPLICIT NONE

INTEGER(INT_PTR_KIND()), INTENT(IN) :: $OBJECT ! Object Pointer
!DEC$ ATTRIBUTES VALUE :: $OBJECT
INTEGER(4), INTENT(OUT), OPTIONAL :: $STATUS ! Method status
!DEC$ ATTRIBUTES REFERENCE :: $STATUS
INTEGER(4) $$STATUS
INTEGER(INT_PTR_KIND()) invokeargs
invokeargs = AUTOALLOCATEINVOKEARGS()
$$STATUS = AUTOINVOKE($OBJECT, 44, invokeargs)
IF ($$STATUS == DISP_E_EXCEPTION) CALL $$DisplayError(invokeargs)
IF (PRESENT($STATUS)) $STATUS = $$STATUS
CALL AUTODEALLOCATEINVOKEARGS (invokeargs)
END SUBROUTINE $DUMCBICONN2_EndSignalDevice

Using the IVF routines for COM. In my example the AUTOINVOKE call has a 44 which corresponds to your offset of 9. Each of the routines of course has a unique offset into the table.

So when you go to the Module Wizard it shows up on the COM tab, but if you check the Use Automation Interfaces it doesn't produce any Method calls.

When you look (in the OLE/COM Object Viewer) at the interface you are using, does it show the methods you want to use? When you look at your COM object in that viewer does it show that it supports that interface? Presumably it does, but I'm blathering here because when I've had questions with using COM interfaces I've gotten a dearth of responses.

How are you getting your Object value that you are using? If it's from a dialog window, and that window has closed when you get to using this particular method, then the Object will no longer be valid and you'll get this kind of result. That's my best suggestion for now.

regarding the viewer:
If the OLE/COM viewer lists the interface for your Object when you expand it, then it is supposed to support that interface. If you look below the Objects in the Type Libraries section and locate the type for your object and double click on that, it will open the ITypeLib Viewer which will show dispinterfaces and coclasses for your type. If you expand your dispinterface that your trying to use on the left, it will list sections for Constants, Properties and Methods. If you expand the Methods section it will show all the methods available using that interface.

You mentioned that you have two methods that work. Is that with the same Object as for the method that gives the error? The error your getting is the same as one gets when the Object is not valid.

So lets refer to the one that works (of the two of the same class) A and the one that fails F. Have you tried the calls in both orders, A followed by F and then F followed by A. Its the same one that fails both ways? If they are both instances of the same kind of object, and they are both being created and initialized the same way, I'd still look for what could be wrong in the second F object.

I've written applications which use three different COM objects. In two cases the COM objects were ActiveX components, and I resorted to putting them in dialog windows to get them to initialize correctly so that I could use them. In the other case I was able to initialize the COM object without putting it into a dialog window, but I couldn't get the ActiveX objects to initialize in the same way.

In my example that wasn't an ActiveX, I had several instances of the same type Object. I used COMCreateObjectByProgID instead of COMCreateObjectByGUID, but that shouldn't make a real difference, certainly not in whether it works. I didn't do anything further before using my objects. Here is that section of code for my example:
do i=1,maxDEV ! get IDispatch for each object
call COMCreateObjectByProgID("DevCntl.Device.1", devOBJ(I), HRES)
if (HRES/=s_OK) exit ! loop, got problem
end do
Did you check the status return to make sure there wasn't a problem with your creation of the second object?

I don't think there's supposed to be any difference based on the language of the application, that's supposed to be the charm of COM.

With my ActiveX examples this approach failed, the status return of the create was nonzero.

Actually, that last about ActiveX is bogus, probably wrong. The one case was my first COM project, and the dialog route was probably just the way I figured out how to get it to work. The other was the second project, and there hasn't been a need to try to rework those since my understanding has improve ever so slightly.

It is not a common problem, but I admit there is very little guidance on using COM from Fortran. But it does seem to be either an issue with the method or the Module Wizard is not generating correct source for dealing with that method. In the latter case, you have the source so you can step through it and see what is going on.