Debugging code when you don't have the source! 
Author Message
 Debugging code when you don't have the source!

Hi all,

Although the title seems a little odd I'll try and explain what I
mean. I have an application which i've deployed to over 1000 users.
One day one of them (or more) finds that it crashes doing a certain
thing. Since they don't have access to the code they can't tell me
what the line is and, say, they can't remember how to cause the crash
or it's something I can't reproduce. It doesn't really matter.

The problem I have now is that unless I go around to their pc,
physically install VB and run the app, I'll never find out what the
problem is.

So I was thinking of some way of having a global error handler that,
when the code crashed, would be able to dump out some meaningful
information into a log file that I could take away and look at which
might (or might not) help me. I have such a thing written into a C
program I maintain and when it comes to trapping wierd errors then
it's a godsend.

However for this VB application I'm a little stuck.

I did a search on the documentation and found that if I compile with
symbolic debug info turned on then I can use Dr. Watson in some
method. But thats where the documentation runs out. Running Dr. Watson
provides me with a message saying "no errors detected" and then when i
click on "ok" it gets minimised.

So I thought about writing my own global error handler, only to find
that you can't use "on error" to call functions. So I'd have to write
an "on error" handler within every function.

So my questions are:

 1. Can I get people to use Dr. Watson or other similar tool to help
me work out what the problem is? If so, how?
 2. Can I write my own error handler within my application without
resorting to one in every single function? If so, how?

Many thanks!

Rich



Fri, 15 Oct 2004 17:42:17 GMT  
 Debugging code when you don't have the source!
Rich,

By the time Dr Watson sees your program, it compiled down
to machine code, so it's unlikely you'll get anything meaningful
(VB-code wise, anyway) out of it.

You don't need an error handler in "every single function".
You *do* need an error handler in every function that
(a) you know has to deal with an error, and
(b) you don't think will have to.
Oh darn; that's *is* every single function.

One thing you might try, depending on how you've structured
your code, is to track the entry and exit points (with arguments
and return values) of every function, writing this out to a log file.
If this can be switched on and off by the Users, they can run
for a bit with the logging on, giving you a trace of what was
going on, and turn it off again once they've recreated the error.

OK, so the application might run a bit(?) slower, but I've
found that Users can be surprisingly accomodating if they
see that a problem is being actively dealt with ...

HTH,
    Phill  W.


. . .

Quote:
>  1. Can I get people to use Dr. Watson or other similar tool

to help me work out what the problem is? If so, how?
Quote:
>  2. Can I write my own error handler within my application
> without resorting to one in every single function? If so, how?



Fri, 15 Oct 2004 19:14:14 GMT  
 Debugging code when you don't have the source!


Quote:
> So I'd have to write an "on error" handler within every function.

Use this if you want to do that:

http://www.mztools.com/

Regards,
Mr T



Fri, 15 Oct 2004 20:51:54 GMT  
 Debugging code when you don't have the source!

Quote:

> Hi all,

> Although the title seems a little odd I'll try and explain what I
> mean. I have an application which i've deployed to over 1000 users.
> One day one of them (or more) finds that it crashes doing a certain
> thing. Since they don't have access to the code they can't tell me
> what the line is and, say, they can't remember how to cause the crash
> or it's something I can't reproduce. It doesn't really matter.

> The problem I have now is that unless I go around to their pc,
> physically install VB and run the app, I'll never find out what the
> problem is.

> So I was thinking of some way of having a global error handler that,
> when the code crashed, would be able to dump out some meaningful
> information into a log file that I could take away and look at which
> might (or might not) help me. I have such a thing written into a C
> program I maintain and when it comes to trapping wierd errors then
> it's a godsend.

> However for this VB application I'm a little stuck.

> I did a search on the documentation and found that if I compile with
> symbolic debug info turned on then I can use Dr. Watson in some
> method. But thats where the documentation runs out. Running Dr. Watson
> provides me with a message saying "no errors detected" and then when i
> click on "ok" it gets minimised.

> So I thought about writing my own global error handler, only to find
> that you can't use "on error" to call functions. So I'd have to write
> an "on error" handler within every function.

> So my questions are:

>  1. Can I get people to use Dr. Watson or other similar tool to help
> me work out what the problem is? If so, how?
>  2. Can I write my own error handler within my application without
> resorting to one in every single function? If so, how?

> Many thanks!

> Rich

My understanding of Dr. Watson is that you need to have it running in
the backround for it to trap an error and that it will trap any error
that produces a 'system' error message. Very useful if the error is
easily reproduced.

Another method that used to be useful is to write your program to
produce a session log. At various points in the program write out to
the session log the current operation and any variables that may be
relevent. This way you can simply read the file and find out what was
being attempted.



Sat, 16 Oct 2004 00:09:51 GMT  
 Debugging code when you don't have the source!
Hi

I remember reading in this group about the possibility to add line-numbers
to the programm, just before the compilation. There was even a tool
available to add those numbers to the source. You could locate the line
where it went wrong through the line number. Fix the error in the not
numbered code and release it again using the same method.

Someone else remembers more.

Cees



Quote:
> > Hi all,

> > Although the title seems a little odd I'll try and explain what I
> > mean. I have an application which i've deployed to over 1000 users.
> > One day one of them (or more) finds that it crashes doing a certain
> > thing. Since they don't have access to the code they can't tell me
> > what the line is and, say, they can't remember how to cause the crash
> > or it's something I can't reproduce. It doesn't really matter.

> > The problem I have now is that unless I go around to their pc,
> > physically install VB and run the app, I'll never find out what the
> > problem is.

> > So I was thinking of some way of having a global error handler that,
> > when the code crashed, would be able to dump out some meaningful
> > information into a log file that I could take away and look at which
> > might (or might not) help me. I have such a thing written into a C
> > program I maintain and when it comes to trapping wierd errors then
> > it's a godsend.

> > However for this VB application I'm a little stuck.

> > I did a search on the documentation and found that if I compile with
> > symbolic debug info turned on then I can use Dr. Watson in some
> > method. But thats where the documentation runs out. Running Dr. Watson
> > provides me with a message saying "no errors detected" and then when i
> > click on "ok" it gets minimised.

> > So I thought about writing my own global error handler, only to find
> > that you can't use "on error" to call functions. So I'd have to write
> > an "on error" handler within every function.

> > So my questions are:

> >  1. Can I get people to use Dr. Watson or other similar tool to help
> > me work out what the problem is? If so, how?
> >  2. Can I write my own error handler within my application without
> > resorting to one in every single function? If so, how?

> > Many thanks!

> > Rich

> My understanding of Dr. Watson is that you need to have it running in
> the backround for it to trap an error and that it will trap any error
> that produces a 'system' error message. Very useful if the error is
> easily reproduced.

> Another method that used to be useful is to write your program to
> produce a session log. At various points in the program write out to
> the session log the current operation and any variables that may be
> relevent. This way you can simply read the file and find out what was
> being attempted.



Sat, 16 Oct 2004 23:10:23 GMT  
 Debugging code when you don't have the source!
Cees,

See http://www.mztools.com/

--A



Tue, 19 Oct 2004 04:10:19 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. I don't know how much I should charge for my source code and copyright

2. Cursor keys don't work in the command window when debugging

3. tab and arrow keys don't work after debugging

4. The debug fired the wrong procedure, and don't reach breackpoint, Make me crazy

5. Having trouble with source code

6. Debugging Source Code in Threads

7. Visual Basic source-code to C++ source-code

8. Visual Basic source-code to C++ source-code

9. Visual Basic source-code to C++ source-code

10. Don't need code, just answers

11. VBA code don't see some query

12. does anybody know why this code don't work

 

 
Powered by phpBB® Forum Software