> Sorry to butt in, but I think there is a better way :-)
> 
> What I (under Windows) do is the following. I start the debugger and let the
> debugger run the app. When an exception occurs, the debugger is invoked in

With wild pointers, the exception sometimes occurs FAR away from the cause.
 Then you have to start removing large blocks of code to narrow it down to
what exactly you screwed up.  (I once copied a structure using the sizeof()
the wrong structure (the data file header structure instead of the data
file record structure) and overwrite some memory, corrupting the dos memory
chain.  It worked fine until the program exited and tried to free the
memory, at which point dos said "the system has been stopped."

You can easily trash your own structures, variables, etc, and trying to
figure out what you did wrong by looking at the assembly language (which
you didnt' make, the compiler made), is doing it the hard way.  Unless
you've got a compiler error (which I have encountered), it's easier to pick
it out of the source code than the .exe.
 
Rob
 
--- Xblat