VB6 debugging

[John]

We are getting calls from ~2% of our customers where a newly updated app is
locking up and throwing an overflow error. Of course none of the 2% are less
than 500 miles away. We can WebEx, but it doesn't do much more than confirm
that they are having a problem. I ran ListDLLs on the system, but nothing
obvious.

Getting and interpretting a dump is an option, but getting to the point
where I can do so effectively is not going to happen this week.

Any suggestions on how to pursue this further remotely without creating a
debug version of the app with a million message boxes?

TIA!

[Ralph]

"John" <X...@newsgroups.nospam> wrote in message
news:C95968BF-0870-4300...@microsoft.com...

Not really. Unless they are corp/high-tech users that can run WinDbg
locally.

If nothing else they should be able to install Dr. Watson and send you a
full report from it. Forget the dump for a bit. Knowing where and who (from
the stack) will allow you to provide a debug version that zero's in on a
specific location a lot faster.

Otherwise, the most common reason a small number of users (using a working
tested app) will have this error is because of 'bad' or 'unexpected' User
data. So you might do a bit of querying about what is different for these
particular customers.

In general, I wouldn't worry too much about component versioning, ..., or
other exotica. It is most likely an assumption within the code that has gone
awry.

-ralph

[John]

Thanks for responding.

We were able to get a copy of the data in question. Works fine for us.

In at least one of the locations it works fine on the PC of the guy sitting
next to the one with a problem. About half the locations were in french
canada, so we pounded on localization issues to no avail. I've asked support
for make and model of the problem PCs on the faint hope they have something
in common.

I will try a drwatson. Thanks for the heads up on that one.

John

[Ralph]

"John" <X...@newsgroups.nospam> wrote in message

news:EA575591-2EEA-4A6F...@microsoft.com...

> Thanks for responding.
>
> We were able to get a copy of the data in question. Works fine for us.
>
> In at least one of the locations it works fine on the PC of the guy
sitting
> next to the one with a problem. About half the locations were in french
> canada, so we pounded on localization issues to no avail. I've asked
support
> for make and model of the problem PCs on the faint hope they have
something
> in common.
>
> I will try a drwatson. Thanks for the heads up on that one.
>
> John
>

Well it sounds like "unexpected" data is less likely the problem.

The stack at point of error should help.

GL
-ralph

[Dee Earley]

Essentially, add line numbers and error handlers to narrow down where
the error is.
MZTools makes this easy.

Further more:
http://hashvb.earlsoft.co.uk/Debugging#In_the_compiled_program

--
Dee Earley (dee.e...@icode.co.uk)
i-Catcher Development Team

iCode Systems

[John]

We know how to add message boxes and error handlers, but the base area where
the problem occurs is 4500 lines of code (first cut). We can get it narrowed
somewhat, but the customers are not real happy about contributing a lot of
their time to the debugging process. Several cycles of download this, run
that is not really in the cards.

Thanks for the advice.