"Invalid Procedure Call or Argument", but only in a compiled or P-Code EXE

Question

I have a VB6 program which I've been maintaining for ten years. There is a subroutine in the program called "Prepare Copy", which looks like this (Edited to add changes):

Public Sub PrepareCopy()

On Local Error GoTo PrepareCopyError

MsgBox "in modeldescription preparecopy"

Set CopiedShapes = New Collection

MsgBox "leaving preparecopy"
Exit Sub
PrepareCopyError:
    MsgBox Err.Description, , Err.Number
    Resume Next
End Sub

Where CopiedShapes is dimmed out as a VB6 Collection.

That code is now kicking out a Runtime Error 5 -- Invalid Procedure Call or Argument. It appears from the interstitial debugging code that the error arises between the MsgBox "in modeldescription preparecopy" and the MsgBox "leaving preparecopy" lines, and that the On Error code path never executes.

Once the Error 5 dialog box is cleared, then the MsgBox "leaving preparecopy" dialog appears, after which the program closes out.

It's behaving this way on my development machine and two client computers.

It is only happening in runtime code, and does not appear to make a difference whether I compile it or use P-Code

What I'm asking for here is speculation as to what causes this sort of thing to happen.

Answer 1

Does the error occur only on machine/s different than where the code was compiled? It may be that some DLLs are missing in the runtime environment (like MSVBRT.dll or the like).
Easiest way to figure it out: run on the build machine.

If it doesn't happen there, you can create a deployable version (an installer) through VB6) that will include all that's needed. OR, use SysInternals' Procmon to monitor the process as it runs and see which resource (file, DLL, reg key) it's attempting to access at the time of the error.

Answer 2

Your recent comment says that the variable is Public CopiedShapes as New Collection.

1. Could you try removing the new in the declaration?

2. Are there any instances in the Collection with a Sub Class_Terminate() which are being called when the old Collection is garbage collected along with its contents?

Answer 3

What happens if you add a new variable in this function and then assign a new collection to it? Does this create the error too?

dim x as collection
msgbox "After Dim X"

Set X = new collection
msgbox "After Set X"

Perhaps the problem lies outside of this function ... ?

Answer 4

Procmon was not helpful. Microsoft took a deep-dive image of the system at the point the problem was occurring.

They found a bad HRESULT failure code. Something deep in the VB6 runtime was attempting to access a late-bound but undeclared object through an IDispatch interface. They swiftly scheduled a call with me. I asked which object was being called through IDispatch; there are no late-bound calls in the VB6 portions of my project. ("option explicit")

In the call, they told me to go away. They refused to help identify further root causes, because VB6 code was involved and the support department is forbidden to troubleshoot VB6 problems. I countered that this was clearly a problem in the supported runtime, to no avail.

Instead, I got a 20 minute lecture on the economies of supporting something when there was no money to be made. I replied with a war story about a thrice-virtualized application still running after 35 years at a phone company.

They were good guys; they wanted to help me solve the problem but their policies forbade it. I'm no closer to a root cause today than I was when I posted the question.

However, if you call MsgBox from the VB6 runtimes, it sends WM_USER messages to other VB6 forms in the project. That, in turn, in my case, triggered MDIForm_Activate in which there was this code:

Me.TreeView1.SetFocus

And that, in spite of the fact that TreeView1 was by definition declared explicitly, was what they declared as the cause of the failed late-bind IDispatch call, all the while refusing to explain how that could be. The guy on the phone even went so far as to say that he absolutely could figure it out, but Microsoft policy forbade it, because that's VB6, there.

Removing the SetFocus call removed the circumstance which produced the error.