Debugging a VB Application

jhance,

Maybe you can point them to some tutorial or book, e.g.
http://www.vb2themax.com/HtmlDoc.asp?Table=Books&ID=3400&Page=1
(It has C++ in title, but it is on VB site)

I would first suggest you to clear your \temp and \tmp folders.
Then I would ask if this started recently - after you installed or reinstalled some other software.
It is good chance some dll is damaged/changed.

Maybe you can ask them to create debug version for you.
In VB IDE, Project properties, on Compile tab, there is checkbutton "Create Symbolic Debug Info".
Then it is possible "function: <nosymbols>" will have some name they will recognize.

In VB code, I would check few things:
- In Class_Terminate events they should use 'On Error Resume Next' error handling.
- if they are saving pointers to objects into non-object variables, they should revise that technique
(in VB it is not possible to check if pointer points to valid object)
- any CopyMemory, StrPtr, VarPtr or ObjPtr usage, or subclassing
If this happens on any Win2K machine
- some APIs have different declaration for Win2K

ASKER

>>I would first suggest you to clear your \temp and \tmp folders.

This problem is 100% reproducable and happens in exactly the same way on 3 different systems, but this particular error happens only on W2K systems. There are similar errors that happen on Win98.

I suspect they are setting an object to "Nothing" and then not re-creating it. The crash happens if you choose a function in the application that opens a window, you close that window and then open it again. Then it crashes. If you open a DIFFERENT window first, then you never see this problem.

So my theory is that the first time you open the window an object get created and a flag is set. When you close the window the object is destroyed but the flag is not cleared. Then when you open it again, the flag says the object is already created but it's not really there and so when it gets referenced, BOOM! (At least that my C/C++ centric explanation)

>This problem is 100% reproducable
Your explanation should be enough for them to fix the problem, maybe you should change your approach.
- send a lovely young girl to ask them very nice to repair it
- sue them if you have warranty or you have maintenance contract
- find another supplier (e.g. ameba won't tell you "We do not have a solution for this" ;-))

ASKER

I sent them the description of how to cause the problem and the DR WATSON log. And they reply (as I noted above):

"The error log dump is useless information for anyone other than a Microsoft engineer familiar with
their use of hex addresses. We do not have a solution for this."

They claim not to know how to diagnose this. If this were a VC++ problem, I would be able to tell them EXACTLY how to backtrack to the line in the source code that caused the fault. My problem is that I have very limited knowledge of how VB works and how to debug.

>I would be able to tell them EXACTLY how to backtrack to the line in the source code

I'm afraid this cannot be done in VB that easy.
VB IDE will let you change code / add functions while debugging, but VB cannot use its debugger when application is compiled.

There are tools that will add line numbers to vb source, and log everything - as AzraSound mentioned.

If they are willing to work with you/us, ask for
- debug version of EXE - no optimizations
- code of the 'function in the application that opens a window' and code in Form_Load() and Form_Unload() in that window (form).

Maybe you can point them to this topic area.

AzraSound

>>There are tools that will add line numbers to vb source, and log everything - as AzraSound mentioned

actually, the products i mention are more than the typical add-ins using line numbers and Erl for locating errors. i believe they tap into the realm of true debugging using the debug libraries. most likely, they implement a lot of what is discussed in these series of "Bugslayer" articles by John Robbins:

http://www.wintellect.com/instructors/robbins/sum.asp

AzraSound

first article of particular interest may be this one:
http://www.microsoft.com/msj/defaultframe.asp?page=/msj/0498/bugslayer0498.htm

it comes with a free utility that you may be able to use

ameba said, "- find another supplier (e.g. ameba won't tell you "We do not have a solution for this" ;-)) "

That's pretty much what I was going to suggest.

And I've also never found the DrWatson info to be of any use.

--
In general, you fix a VB bug by either:

1) Guessing as to where the problem is, then fixing things until the problem goes away (the amateur way, which is also useful yo professionals working on unimportant projects.)

2) Adding proper error-trapping to ensure that any error occurs display a decent message and allows the app to either properly shut down or at resume without shutting down.

I suspect that the company you are dealing with fits category #1. If they don't understand #2, then you probably want to find a new source for your code, even if it means getting it re-written by an expert.

How do you know if someone's an expert? It's pretty hard, because you generally have to be an expert to know, and then you wouldn't need this person. However, one approach is to look at references, ask about other projects, and MOST OF ALL, see if they'll give you a straight answer to your questions. When they start side-stepping your questions, it's time to side-step them as your expert-for-hire.

ASKER

Believe me, I would love to find another supplier.

Unfortunately, this is a commercial application where there is no competition and this is the only choice.

The application is Meet Manager from Hy-Tek Sports, Ltd.:

http://www.hy-tekltd.com/swim/

My kinds are involved in swimming and I (being the skilled computer person that I am) often end up running this program during swim meets. It is incredibly annoying to have it crash all the time especially since a system reboot is often needed afterwards since parts of the program keep running and it thinks there is already a copy running when you try and restart the application.

These guys are pretty clueless and it would be GREAT if there were an alternative... But this application is just about the only choice and (worst of all) is probably 99% entrenched in the amateur swimming scene.

Sounds like an opportunity ...

Meanwhile, I guess the best you can do is to try to convince the amateur programming group that this can be fixed by simply adding error trapping...

Do you think they'd be willing to part with the source code so you can fix it yourself? We tried this with a company once, and they offered to "rent" us the source code as long as we returned it with the fixes so they could sell the new version since they had no intention of upgrading. We politely told them to shove it and wrote our own version since we had a very good grasp of everything that was needed!

Since you sound quite qualified to handle a project such as that, the only question seems to be whether you have the time and desire to overcome this bug.

ASKER

I agree it's an opportunity. A work-alike program could be a big success. I think they charge way too much for this app. A minimal system with all the parts needed for a swim meet is about $800. I think a competitive program at $400 would sell fast the next time upgrades came out (which are expensive too....) And I'm sure that even converting their database would be relatively trivial as they are all based on MS ACCESS (i.e. mdb files).

What I don't have (and I'm sure you can relate to this) is TIME! I'm already as busy as I can be....

If you can give me specs, I work with a group that does projects like this, and we may be able to get you a free prototype. E-mail me at RSpahitz @ yahoo . com

ASKER

Well, I guess the opinion is that VB programs cannot truly be debugged since the crash data doesn't relate back to anything! What a sorry state of affairs!!!

I'm sure glad I never wasted much energy toward learning it...

>I'm sure glad I never wasted much energy toward learning it...

Yeah, right, you are a "Real Programmer".