VB6 - debugging program to assist with compiled program

Question

Good Morning,

I wanted to know if there is any program that can identify which component is causing a run-time error 430. I know enough to debug using VB6 IDE however its a strange case since the error does not occur when in the IDE. I have checked the references and components but they're all intact. So I'm looking for any debugging program that can attached itself to a compiled program and give me an idea of what .DLL component or .OCX component is causing the error more information.

Thanks in advance, Jorgen

UPDATE: I have read all your responses thanks for all the help. Besides from spy++ and Process Monitor I was considering using OllyDbg it has a view called "Executable Modules" that basically show which DLLs are being called. However when I run my program in it, it freezes and doesn't continue loading the GUI. Anyone familiar with OllyDbg and know why this is occurring?

Thanks

Jorgen

Answer 1

Assuming you have all the source code, you can compile your VB6 EXE and the DLLs and OCXs into native code including symbolic debug info so that the PDB files are created (tick the checkbox on the Project > Properties > Compile tab). Then you can either use WindDbg or Visual Studio .NET to trace the problem.

• WinDbg (http://msdn.microsoft.com/en-us/windows/hardware/hh852365) Please see the following:

  • "A word for WinDbg" by Mike Taulty (http://mtaulty.com/communityserver/blogs/mike_taultys_blog/archive/2004/08/03/4656.aspx)
  • "Old school debugging - VB6 middleware applications" by Mark Long (http://blogs.msdn.com/b/marklon/archive/2006/01/28/518616.aspx)

or

• Visual Studio 2008 C++ Express or Professional with your PDBs.

Both ways need to have the source code in exactly the same path on the debug machine as on the build machine. The easiest way then, is to build and debug on the same machine.

Answer 2

It's probably easier to add logging to the application.
It is possible to debug without using the VB6 IDE, but its not easy - I recommend logging.

Answer 3

Logging is good and fine but it can be fustrating experience throwing logging all over the place before you have an idea where to start.

spy ++ is the stuff I use when debugging old vb code along with PView will give me a rough idea where the code is failing. And then add logging to those areas.

And check Hans Passands comment. It might save you some greef.

Answer 4

You can download "Process Monitor" from sysinternals: www.sysinternals.com, set the filters to not appear useless information and investigate for unsuccessful results, quite painful work but with good chances.