The best we poor developers will be able to do is try to impliment a class
that gets activated for certain *recognized* events... It still needs code
added. See Chip Pearsons site.

The call stack is well hidden and possibly for good reason along the lines
of Intrusion Alert and the Resistance is Futile.

I think one reason why the debugger will jump in there is because it *needs*
to... That's it's job... But all the same it only works with a memory
snapshot. You have a problem going backwards... Always. It's normal to evoke
a debug environment *before* you run so that there *may* be a possibility of
steping back.... Never a certainty.

Classically, the way to find out what went wrong in a program is to take a
dump... No I don't mean anything brown and smelly... A memory dump... Of the
computer.

Tracing backwards don't give nothing... It's that last instruction in
assembler that's important and only that... What's it trying to do and why
can't it do it?

It sez... I want to do this... Tries to do it ... And bombs.

Now we come to the tricky bit... Why?

There are actually a limited number of options.

Most programs are seperated into data and instructions... A typical problem
is that the pointer to the next *instruction* gets lost... And tries to runn
a piece of data instead of a real instrucion. The adverse is true... The
progrma may get lost and try to retrieve data that is actually an
instruction!

This is the basis of a *lot* of malware... The object being to get into the
program and disrupt it.... And or.. Upset the place in memory that's being
looked at.

The bottom though line for this Q though ... I feel anyway... MS ain't goona
tel us how to get at that stack