Determine form/VBA procedure from Access crash dump?

[Mark Loveless]

Back in my mainframe days a crash dump could be parsed by hand to
reveal the application program running at crash time as well as the
offset into said program, which combined with a extended program
listing could be used to determine the partcular application program
statement that killed the thing.

I realize this is a totally different world, but is there a way at
least to determine which form had control at access-decides-to-croak
time? I've got a situation in which closing a form kills Access like
a big dog, and I'm stymied. All my tables/recordsets are closed, and
I've even unbound the bound list box that is the only data-aware item
on the form.

Alternatively, is there a way to force Access to step thru it's own
code and into the code of other forms? I've checkpointed all the
Form_* procedures in the invoking form but get no hits. It leaves the
close of the invoked form and never reaches the Form_* procedures of
the invoker, so I'm stuck.

Help!

Mark Loveless
Reluctant Access Programmer

[Alan Webb]

Mark,
It's a pain, but a class module that is an application scope event handler
can be written which logs significant events as they occur. Then a perusal
of the logs will give some hints as to what was croaking when things went
bad. I have my own code, there may be sample stuff around you can start
from. VBA includes a break mode where you can step through code as it
executes and see where it died.
The smart thing to do is to always write your code using functions instead
of subs so that you can at least return a result code indicating whether the
funciton did what it was supposed to or hosed for some reason. Then when a
function errors out you can log the event code and try to sort out what it
meant.

"Mark Loveless" <ma**@tralfaz.com> wrote in message
news:4a**************************@posting.google.c om...

I realize this is a totally different world, but is there a way at
least to determine which form had control at access-decides-to-croak
time? I've got a situation in which closing a form kills Access like
a big dog, and I'm stymied. All my tables/recordsets are closed, and
I've even unbound the bound list box that is the only data-aware item
on the form.

[Albert D. Kallal]

"Mark Loveless" <ma**@tralfaz.com> wrote in message
news:4a**************************@posting.google.c om...

I've got a situation in which closing a form kills Access like
a big dog, and I'm stymied. All my tables/recordsets are closed, and
I've even unbound the bound list box that is the only data-aware item
on the form.

Do you have any code in the on-close event?

You always place the following command in code:

Stop

The above command will invoice the de-bugger in code. (however, you have
mentioned you are setting break points anyway.....you do know how to set
break points with he mouse in the VB ide...right?

Also, while looking at code..can you do a save and compile all?...you might
have some errors hanging? (can you for example create a mde file?).

It turns out that office DOES in fact do a core dump via Dr. Watson. These
errors (if you choose to hit send) actually get sent to Microsoft for them
analyze.As a results.. if users experience a crash..then MS can fix it in
the next update. While similar to the old days where execute error
occur..what is different is that MS can now get this info in real time (if
you hit send)..

There is also a great article on debugging VBA code.. Lots of great hints
(like how to show the calling program stack of routines called to get you to
a given point).

Check out:

http://www.fmsinc.com/tpapers/vbacode/Debug.asp
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.attcanada.net/~kallal.msn