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

possible duplicate of [What could cause Vb6 run time error 430](http://stackoverflow.com/questions/280383/what-could-cause-vb6-run-time-error-430) — Hans Passant, Mar 11 '14 at 16:41
Thanks @HansPassant however all checks out no local DLLs in the root directory of the program and the DLLs that I have the native code for were compiled with binary compatibility. Thanks again for your references. — user1803784, Mar 18 '14 at 23:06

score 3 · Accepted Answer · answered Mar 12 '14 at 21:57

3

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.

answered Mar 12 '14 at 21:57

clairestreb

1,243
12
24

I don't have all the native codes as some DLLs are from an external company such as Crystal reports and Fortis. Thanks for your advise – user1803784 Mar 18 '14 at 23:03
But you could debug your code & find out which 3rd party component is causing the problem. Then check whether its properly installed. – MarkJ Mar 20 '14 at 16:52
WinDbg help me find the DLLs giving the issue I am still having the issue but the crash course @MarkJ suggested helped a lot. I will debug further more. I also will still try the displays suggestion as he stated thanks Mark. – user1803784 Mar 26 '14 at 14:35
I found the issue. The .vbp was referencing a DLL from another environment. Where I work we have a folder with all the programs stored in that location which is used by everyone within the business, and we also have a copy of the same folder with the same programs HOWEVER with slightly different source code. The issue was occurring because the .vbp from FOLDER1 was referencing the the DLL from FOLDER2. Bottom line double check your references and insure to implement a software version management system. – user1803784 Mar 31 '14 at 16:10

score 1 · Answer 2 · edited May 23 '17 at 12:23

1

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.

edited May 23 '17 at 12:23

Community

1
1

answered Mar 11 '14 at 19:31

MarkJ

30,070
5
68
111

Do you mean logging using the "On Error Go To" statement because this would display the same 430 run-time error message. I need to know which dll is causing the error. – user1803784 Mar 18 '14 at 23:00
It would help you find the exact line of code which caused the error, and that would help you identify which DLL / ocx is causing the problem. – MarkJ Mar 20 '14 at 16:45

score 0 · Answer 3 · answered Mar 12 '14 at 07:39

0

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.

answered Mar 12 '14 at 07:39

Archlight

2,019
2
21
34

I have never used spy++ before but I will try this option as well. I just need to get familiar with the program. Thanks for your advise – user1803784 Mar 18 '14 at 23:04

score 0 · Answer 4 · answered Mar 12 '14 at 11:38

0

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.

answered Mar 12 '14 at 11:38

ooopsoft

410
2
6

Yes I am currently trying this option. I have used process monitor before but not to this extent. I have tried using it to show where the process is not successful but still have no head way. I shall keep trying thanks for your advise. – user1803784 Mar 18 '14 at 23:02

VB6 - debugging program to assist with compiled program

4 Answers4