i am working on an application which calls the COM component of a partner’s application. Ours is .Net, theirs isn’t. I don’t know much about COM; I know that the component we’re calling is late-bound i.e.
obj As Object = CreateObject("THIRDPARTY.ThirdPartyObject")
We then call a method on this COM object (Option Strict Off in the head of the VB file):
obj.AMethod(ByVal Arg1 As Integer, ByVal Arg2 As Integer, ByVal Arg3 as Boolean)
I am a bit nonplussed that even though this call works, this overload doesn’t exist in the COM interop .dll that is created if I instead add a reference to the COM server using Add Reference. The only available call to this method that it says is available is AMethod().
However, this in itself is not what bothers me. What bothers me is that this call works for a while, THEN throws a TargetParameterCountException after a few dozen calls have executed successfully.
I ask thee thus, StackOverflow:
What. The. Hell.
The only thing I can guess at is that the documentation for the COM component states that this method is executed synchronously – so therefore maybe whatever’s responsible for throwing that exception is being blocked until some indeterminate point in time? Other than that, I’m completely stumped at this bizarre, and more importantly inconsistent behaviour.
edit #1:
More significant information that I’ve just remembered – from time to time the call throws an ExecutionEngineException instead. It only took one glance at the documentation to realise that this is VERY BAD. Doing a little bit of digging suggests to me that the late-binding call is causing stack corruption, crashing the entire CLR. Presumably this means that the runtime is shooting down bad calls (with TargetParameterCountException) some of the time and missing them (ExecutionEngineException) others.
edit #2:
Answering David Lively’s questions:
- The call with zero arguments that’s currently in the code has been there for a long time. I haven’t been able to get hold of a manual for the third party’s COM implementation past two major revisions ago, so it’s possible that they’ve withdrawn that signature from service
- There is only one location that this method is called from
- This is one desktop app calling another, on the same machine. Nothing fancy
- The object is persisted throughout the scope of the user’s interaction with the application, so there’s never a new one created.
Unfortunately, it seems likely that there is indeed a bug in the implementation, as you suggest. The trouble with this vendor is that, when we report a bug, their response tends to follow the general form: i) deny there’s a problem; ii) deny it’s their problem; iii) refuse to fix it. These three steps tend to span a frustratingly long period of time.
OK, basically – false alarm. I’ve done it wrong – I’ve copied some code over from somewhere improperly and the thing I’m calling was never supposed to support that overload. What I find interesting is that the component didn’t reject that late-bound call out of hand, but did everything it was supposed to do, at least initially.