Reputation: 14512
I maintain an old application written in VB6. In client's environment it raises runtime errors which I can't reproduce under debugger. Is there any way to get the stacktrace or location of error?
I mean, without putting trace statements all over the code like here or adding error handlers for logging to every procedure like here.
It seems to be a simple question. Sorry. I just don't know VB6 very well. And it is surprisingly hard to google out any information, considering how widely it is (or used to be) used.
Upvotes: 3
Views: 9506
Reputation: 30398
The VB6 debugger is flaky sometimes. There are alternatives.
Upvotes: 3
Reputation: 5225
If you check the "Create Symbolic Debug Info" checkbox on the Project Properties/Compile tab, then you can debug in Visual Studio just like you would a native C++ application.
Upvotes: 2
Reputation: 7192
Try compiling to pcode and see if you still get the error. This is one common difference between the debug mode of VB6 and runtime. I used to compile to native and ran into errors that only occurred in runtime. When I switched to pcode I found either the error went away or more likely a new error that reflected the real problem cropped up and was more easily reproduced in debug mode.
If despite that you still getting the error then I really recommend starting at the top of your procedure stack and working you way down using Maero's suggestion of
On Error Goto Handler
<code>
Exit <routine>
Handler:
Err.Raise Err.Number, "(function_name)->" & Err.source, Err.Description
It is a pain but there is no real way around it.
Upvotes: 3
Reputation: 2008
It's been a while, but I don't think there is a way to get a stack trace in a VB6 application without adding an error handler and outputting the appropriate message. There were some third party tools that would add error handling to an entire application but I believe it just added "On Error Goto" error handlers throughout the code.
Just as an aside, one of the more insidious runtime errors I ever encountered in a VB6 app was when I used a font that didn't exist on the client's PC in the property of a control. This generates a runtime error that cannot be trapped in code, so no amount of error handling that I added ever uncovered the error. I finally came across it by chance. Hope this helps.
Upvotes: 1