VB6 always crashing
Thomas Schoch
terminate my application.
I'm not using any 'END' statements, have checked that all object
variables are reset. Still VB crashes about 95 times out of 100.
Has anyone noticed the same and/or knows how to fix this?
Thomas Schoch
Elephant Software AG
Switzerland
Frank Prengel [MS]
Might be the Add-Ins. Try to disable them (one by one, esp. the Source Code
Control Add-In) and see if the problem goes away. If so, re-install.
Hth,
Frank
Douglas Marquardt
Hi Thomas:
> I have a rather large application where VB always crashes when I
> terminate my application.
What do you do when you terminate your app (i.e. what's your clean up code,
etc)?
Can you step through as shutdown and narrow it down to a line(s) of code
that cause the problem?
Will help if I can.
Doug.
Thomas Schoch
>What do you do when you terminate your app (i.e. what's your clean up code,
>etc)?
programm finishes after the MDI form being unloaded. No END
statements.
>Can you step through as shutdown and narrow it down to a line(s) of code
>that cause the problem?
No, because VB crashes after executing the last statement or better
after unloading the MDI form.
Douglas Marquardt
> No, because VB crashes after executing the last statement or better
> after unloading the MDI form.
There could be a number of things that may be the problem (too many to
mention/think of), but perhaps you could investigate a couple of possible
causes I can think of off the top of my head (I'm sure others will post
their thoughts too on this one):
1. Corrupt code/form module. One method you can use to help determine
this, or at least narrow down what module may be causing the error, is to
start a new project and add bits and pieces of the old project to it a
little bit at at time, and run/compile the project/exe until you experience
the crash again. (i.e. add a copy of a form with no code, run/compile the
project, add the code for that form, run/compile the project, etc). Along
the same train of thought... you could try to just comment out all the code
in your project a little bit at a time until finally the app does not crash
anymore -- then uncomment code until the crash occurs again.
2. Passing the wrong type of data to API declarations (i.e. passing a
string ByRef when it should be ByVal). Check all your declarations and
variables that you are passing, etc.
3. Proper clean up of objects (you did not post your code so I don't know
for sure how exactly you are doing this). The recommend method for this is
to release all references to objects and unload all loaded forms, i.e.
Private Sub MDIForm_Unload(Cancel As Integer)
Dim Index As Integer
Set m_objMyClass = Nothing
...etc
For Index = Forms.Count -1 To 0 Step -1
Unload Forms(Index)
Next Index
End Sub
Hope one of the above helps,
Doug.
Jeff Ashley
Sounds like unresolved subclassing to me . . .
Thomas Schoch
I have tried different things now:
- Wrote a logfile to check if all object vars are set to nothing
- disabled all addins
- Checked corrupt code. The project compiled ok
And the crashes are still occuring
Any other ideas?
Thomas Schoch
Elephant Software AG
Switzerland
On Thu, 17 Aug 2000 07:19:14 -0600, "Douglas Marquardt"
<no_...@dummy.com> wrote:
>Hi Thomas:
>
>> No, because VB crashes after executing the last statement or better
>> after unloading the MDI form.
>
Douglas Marquardt
Hi Thomas:
> - Checked corrupt code. The project compiled ok
>
> And the crashes are still occuring
Are you saying that this only happens in the compiled exe -- never in design
mode?
Doug.
Thomas Schoch
Doug,
no, the other way round: it's ok in compiled mode but not in design
mode!
Thomas Schoch
Elephant Software AG
Switzerland
Douglas Marquardt
Hi Thomas:
> no, the other way round: it's ok in compiled mode but not in design
> mode!
OK... so at what point did it start crashing (that is, if you followed my
directions about commenting code, etc)?
Doug.
Thomas Schoch
Well I didn't actually comment the code out to find the problem. My
project has about 40 forms and 50 modules/classes. It would be quite
hard to take parts out of the project.
We are using Desaware's SpyWorks subclassing control. Could this be
the culprit?
Thomas Schoch
Elephant Software AG
Switzerland
Douglas Marquardt
> Well I didn't actually comment the code out to find the problem. My
> project has about 40 forms and 50 modules/classes. It would be quite
> hard to take parts out of the project.
I never said debugging was going to be easy ;-)
> We are using Desaware's SpyWorks subclassing control. Could this be
> the culprit?
I have used that in the past with no problems; however, it may not be the
control but with how you are using it -- that would be a good place to start
with your debugging process (i.e. turn off subclassing, if that helps, then
gradually turn back on parts until the crashes occur).
Doug.
Thomas Schoch
Hi Doug,
I have done some more debugging. It's definitely not the subclassing
control that is causing the problem.
I have found out though that if I have a break point on the last line
of code things look a whole lot better. I have not hat a crash yet. As
soon as I clear the break point VB crashes again.
One more idea I have to follow up: we have a number of COM objects
that we use. What if I set the reference to nothing and a crash
happens in the terminate code of these COM objects? I'll try Numega's
Failsafe to catch one of these errors.
BTW: Do you know of a tool that shows all the inprocess DLLs loaded
together with any running program?
Thomas Schoch
Elephant Software AG
Switzerland
Douglas Marquardt
> I have found out though that if I have a break point on the last line
> of code things look a whole lot better. I have not hat a crash yet. As
> soon as I clear the break point VB crashes again.
Sounds to me like an object in your app is trying to reference an invalid
reference/object during the shutdown process. When you place a breakpoint
in your app, the object has time to clean itself up before the
refererence/object becomes invalid; when you don't use a breakpoint, it trys
to clean itself up using a reference that has already become invalid (hope I
explained this properly so you get my point).
> One more idea I have to follow up: we have a number of COM objects
> that we use. What if I set the reference to nothing and a crash
> happens in the terminate code of these COM objects?
Are you saying that *is* what you are doing, or that you want to *try* doing
this? (perhaps post a code example of your termination process)
In any case, it appears to me that the problem may be a result of how you
are cleaning up (terminating) your objects.
> BTW: Do you know of a tool that shows all the inprocess DLLs loaded
> together with any running program?
I thought something in the SpyWorks package would do that? Don't recall for
sure though.
Doug.