Debugging VB6 dll from VB6 exe

4
votes

I have a VB6 program that calls a VB6 DLL which in turn calls another VB6 DLL. When I execute the calling program there is an application error which I am unable to pinpoint so I researched how if it was possible to "see" the error in the dll.

I read Stackoverflow entry question about debugging VB6 dll

and followed the directions of Booji Boy to create a vbg. I also followed his directions and removed the two DLLs from he Reference list. The calling program takes a .txt file as input. When I executed the exe I received this error:

Error Number: 13Description: Type mismatch

The error isn't being generated by the application.

What does this mean? How can I debug this issue?

3
dllvb6
The error is a runtime error, and IS being generated by the application, but from inside the VB runtime. Something in your code, or a Dll you're calling, is causing the type mismatch, which the VB runtime is capturing in a "friendly" way. As to how to debug it, it's hard to say without seeing the code. – Nick Shaw
Thank you for responding. This exe-dll-dll project was working a few weeks ago. I will check the paramters being passed from one project to another. – DeveloperM
You shouldn't execute the exe. You should run the exe project from the VB6 IDE. Then the IDE will highlight the line causing the error. – MarkJ

3 Answers

8
votes

You must have all the source code for the EXE and the two DLLs. You add all the projects into single group file i.e. the VBG. You must have a reference in the EXE project to the first DLL. I have no idea why you have been told you have to remove them. You must have a reference in the first DLL project to the second DLL project. VB is clever enough to silently replace the DLL reference with the project reference. It is also clever enough to silently replace the project reference with the DLL reference if you remove a DLL project from the project group.

Make sure you have error handling set to "Break on All Errors" or "Break in Class".

The type mismatch error can occur from simple things like assign a non-numeric string to an numeric variable. It gets more complicated if you are passing object references around. If you see this error occurs on something like:

Set myObject = someOtherObject

... and it looks as if they should be the same type, this might get very complicated. But first, I'll let you do the debug.

0
votes

You can use an open source project made in Visual Basic 6.0. It is called "Debuggy v2".This project has multiple roles:

-debugger -disassembler -Windows resource extractor -file hex editor -window sniffer -API spy

all rolled into one. I may be useful for what you need.

0
votes

When starting to work in a VBG a type mismatch can arise if the library references are inconsistent. One library may be referencing another IN the VBG; a second may be referencing the compiled version. Passing objects between them can result in this error.

Concrete example:

  • VBG contains code for: A.DLL, B.DLL, C.DLL
  • A references B in the VBG
  • C references B which is compiled
  • Code in A calls code in C passing an object defined by a class in B.
  • Type mismatch

C should have referenced B in the VBG.