VB crash - Can anybody read a memory dump?
Patrick Wetering
third party controls.
From time to time my app is crashing.
My project is so huge that I cannot easily remove control by control
until the error disappears and I know which control caused the problem.
Is there anybody here who can help me by having a look at the memory
dump that VB produces?
Maybe it's possible to say which control caused the problem by looking
at it?
Cheers!
Patrick
Ralph
"Patrick Wetering" <pa...@gmx.de> wrote in message
news:%23sUo2HO...@TK2MSFTNGP03.phx.gbl...
The first question is where is this 'memory map' coming from? OS,
Post-Mortem debugger, or from the VB IDE dying when an error occurs?.
It sounds like the project is erroring when compiled but not when run inside
the IDE. Is this correct?
Without a symbolic-compile or a matching /map file a simple memory dump, and
excellent knowledge of the application itself, it is going to be a tough
read. (Not impossible, but tough.) If it is post-mortem utility you should
also have a Call-Stack which will be more useful.
In this case the best tool is WinDbg. It is complex but can used as a simple
debugger. ie, you don't have to totally understand everything without
gaining some benefit.
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
(As a developer you have to learn out to use a good debugger anyway, so go
ahead and get it now.)
Second, one is kind to force to chew you out a bit. <g>
If you have written an application this large and still can't quickly locate
fail points - that is, quickly identify the specific feature
group/procedures, control, module, or component that is causing an error,
then you need to step back and re-consider how you are instrumenting
error-handling in your program.
So before one gets into lots of suggestions - trapping errors, logging, etc.
Tell us a bit about how you are handling errors now and why you can't seem
to catch them without a "memory dump"?
-ralph
expvb
crash in a compiled VB6 app using VC++:
- In VB6, in the project's properties, go to the Compile tab and select
"Create symbolic debug info". This will create a PDB file when you compile
your project.
- Save and Compile.
- Run the EXE from Windows Explorer.
- Go to VC++ 6.0|File|Close Workspace.
- Go to Build|Start Debug|Attach to process, and select your running EXE.
- Go to View|Debug Windows, and make sure that "Call Stack" window is
visible.
- Let it crash.
- The call stack shows you where the problem is. One of the lines will point
to your source code, when you double click on that, it will show you the
source code and points to the exact line that caused the error.
- If the program closed normally, or you want to try again, go to
Build|Execute <Your EXE file name>, then use "Attach to process" again.
- There are some settings that you could change, if necessary, in
Project|Settings|Debug.
See also:
How to debug a native code Visual Basic Component in Visual C++
http://support.microsoft.com/kb/166275/EN-US/
How To Debug a Visual Basic Out-of-Process Server with Visual C++
http://support.microsoft.com/kb/200034/en-us
Make sure that you disable "Create symbolic debug info" before releasing
your software.
Patrick Wetering
it's different: Crashes occur in IDE only (as far as I experienced),
after pause/ start application.
I'm using quite of lot of custom controls that I wrote myself, code from
vbAccelerator (which I improved myself) and Unicode controls that I got
from the net.
I am relatively sure that my controls don't cause the problems, and I'm
also relatively sure that I improved the vbAcc controls so that they
don't crash anymore.
But "relatively" is of course not a nice word for binary people.
I do handle each and every error with an "On Error Goto". There is no
proc or func or prop that doesn't have an error catcher.
As it sounds it's in fact easier to remove each and every control until
I found the bad boy...
expvb
> Hi Ralph,
>
> it's different: Crashes occur in IDE only (as far as I experienced), after
> pause/ start application.
If you are using subclassing, then any break into debug mode or ending the
application could hang or crash the IDE. You have to let the application end
normally, or exclude some parts of the code when running in the IDE by using
a function like the following:
http://vbnet.mvps.org/code/core/isinide.htm
Ralph
By "pause/start" you are talking about while you are "stepping" through the
code or when you actually invoke a Break (Ctrl+Break) or Restart (Shift+F5)
blah, blah.
I will go so far to say that it isn't really 'easier' on the long run to go
about removing and adding controls. It is generally a bad idea as it takes
time, and the more you fiddle with working code (taking out; putting back
in) the more opportunity you have to create a new set of errors. It is
likely just what I have gotten good at. <g>
Plus it is harder to get help. Best if everyone is on the same page and
stays on the same page. <g>
Are you using a Post-Mortem debugger? Look up Dr. Watson in the Windows Help
(Start). I heartily suggest that you download WinDbg and set it up as you
Post-Mortem debugger on your development box. Even if you still plan on
using VC++ as your primary debugger.
You can either launch the VB IDE and later attach WinDbg or you can launch
VB from WinDbg.
As I said before the Post-Mortem Call Stack alone is usually all it takes.
[Should comment on exvb excellent suggestion: The VC++ debugger (which I
still affectionately call CodeView) is good tool. I second his suggestion
for those who own the full Visual Studio 6 package, are comfortable with the
VC++ environment, and have done a bit VC++ programming. Having all the tools
in one nice package (ah, make that two. <g>) is good too.
However, if you are not comfortable with VC++, then WinDbg is the way to go.
The learning curve is about the same and WinDbg, once you learn it, is more
useful to debugging a larger variety of applications, drivers, devices, etc.
Sure its scary if you never been there before, but so is VC++ if you haven't
used it before.
It is also lighter and can be installed (and uninstalled) on servers and
client boxes with far less intrusion that installing Visual Studio would be.
(With no licensing issues.) Using it as a post-mortem debugger is bit quirky
(though only in the eye of the beholder).
I use both, but then I've been using MSC for almost 30 years. <g>]
Download WinDbg.
Install it as your Windows Post-Mortem debugger.
Instructions are in Windows Help and in the docs with the download.
If you are still having trouble, report back with exact error message and
the call stack, and exvb or someone will have an answer for you, and perhaps
suggestions for better discovery the next time, in less than ten minutes. Or
you can have your money back.<bg>
-ralph
Ralph
"expvb" <nob...@cox.net> wrote in message
news:eyc5OgQu...@TK2MSFTNGP06.phx.gbl...
Man! The phenomenon literally 'screams' subclassing trouble - yet it never
crossed my mind. <g>
Bob O`Bob
> As it sounds it's in fact easier to remove each and every control until
> I found the bad boy...
>
There really are very few exceptions to the rule.
Bob
--
Patrick Wetering
Can I attach the debugger to the VB6 IDE as well???
expvb
> The problem is that - once compiled - it doesn't crash on my computers...
> Can I attach the debugger to the VB6 IDE as well???
No, you have to use it on the compiled EXE.
Patrick Wetering
Thanks for all the tips.
Ralph
> Can I attach the debugger to the VB6 IDE as well???
>
>
You can attach WinDbg to the IDE. You don't get Symbolic information on the
IDE, but the call stack and point of failure is useful.
Be aware that external components are mapped through VB6Debug.dll and of
course ntdll. So the final point of an error is usually not the trouble, but
something else up the line.
If you are interested in quickly identifying "bad boys". IMHO WinDbg is the
only way to go. There I said it. <g>
Attach, launch, run, bang!, a couple of clicks, and there you are ...
-ralph
Ralph
> Attach, launch, run, bang!, a couple of clicks, and there you are ...
>
Or
Launch, attach, run, bang!, a couple of clicks, and there you are ..
(Depending on where you place the missing pronoun. <bg>)
-ralph
Patrick Wetering
a side question:
Would an ocx control that's done in C++ and that's using subclassing be
able to cause the IDE to crash?
Patrick Wetering
I do understand that (normal) subclassing (not the Paul Caton
subclassing) can crash the IDE if it can't find a window anymore
(because the IDE may be in a break), but I thought that controls that
are compiled are somehow not part of this trouble-place anymore. Man,
sorry, I'm talking a little wild, but cannot express myself any clearer.
Maybe you understand it anyway?
Ralph
"Ralph" <nt_cons...@yahoo.com> wrote in message news:...> news:eakwhFTu...@TK2MSFTNGP05.phx.gbl...
is
> pecular to VB (isn't even needed with other platforms) so I would say you
> are correct.
>
> But exvb and others are more familar with it than I am. I seldom go there,
> myself.
>
> -ralph
>
>
Ralph
"Patrick Wetering" <pa...@gmx.de> wrote in message
news:eakwhFTu...@TK2MSFTNGP05.phx.gbl...
The subclassing issue, I think we are talking about, normal or otherwise, is
Jimekus
> "Patrick Wetering" <p...@gmx.de> wrote in message
I've been reading this group for a few months, but this is my first
response. My problem which may be relevant to the OP is that bizarre
crashes have been occuring in my large project, too.
For the last two years, while debugging them in the IDE I found that
the call pointer jumps into the middle of unrelated procedures. The
only cure I have found is to remove whole sections of code surrounding
the error, which are generally from large modules, and put them into
smaller ones.
This begets the question of whether or not there is an upper limit to
VB6 module size.
Ralph
"Jimekus" <Jim...@gmail.com> wrote in message
news:9f717c36-3b28-4b13...@i36g2000prf.googlegroups.com...
=============================
There is. It is 64k IIRC. It is generally too big to get to without effort.
There is also a limitation on other things like procedure length, number of
controls, concatenated strings, etc. depending on context. But normally all
these conditions will cause *compile* errors. Not a corrupted product that
fails at runtime.
BUT when things go wrong anything can happen.
I vaguely remember something different about "debug jumping to odd lines".
But the old brain cells aren't working at the moment. Since your fix works,
I'll go with your idea. ,g>
MichaelC
VB does crash in the IDE from time to time. I think sourcesafe helps it
along. Sometimes VB crashes on me just typing code. It's possible what
you're experiencing is normal.
Michael
Ralph
"MichaelC" <mi...@nospams.com> wrote in message
news:eHsyLBWu...@TK2MSFTNGP03.phx.gbl...
The common cure is to perform frequent full compiles.
A common culprit for a frequent failure is an Addin.
The only problem I ever have had with VSS is if I accidently forget and work
on a open project through both the IDE interface and outside using the VSS
Manager at the same time.
Outside edits while a project is open can lead to interesting effects as
well.
VB is quite paternal over what it considers its own. <g>
-ralph
MichaelC
> The common cure is to perform frequent full compiles.
> A common culprit for a frequent failure is an Addin.
> The only problem I ever have had with VSS is if I accidently forget and
> work
> on a open project through both the IDE interface and outside using the VSS
> Manager at the same time.
> Outside edits while a project is open can lead to interesting effects as
> well.
> VB is quite paternal over what it considers its own. <g>
I've never quite narrowed it down but I think having multiple programmers
using sourcesafe could be part of the problem. Since the other programmer on
my project left I've seen less crashes but can't be certain that is the
cause. it fits with your idea that modifying code outside the IDE causes
problems.
>
> -ralph
>
>