Industrial-strength debugging?

[garry star]

My app is crashing in various places depending on how I move code around or include/exclude code. My guess is something is overwriting memory somewhere but I have no idea where. It happens on Vista 64-bit and XP 32-bit. I've tried
tools on
debug display on
debug code on
trace on

ran it in PB9 IDE under the debugger, ran it outside of PB9. Used
OurUnhandledExceptionFilter() but it didn't really tell me anything I didn't already know.

Are there any industrial-strength tools to try and figure this out?

Thanks...
Garry

My eventlog (Vista) showed this once:
Faulting application PIDS.EXE, version 1.0.0.0, time stamp 0x00003039, faulting module PIDS.EXE, version 1.0.0.0, time stamp 0x00003039, exception code 0xc0000005, fault offset 0x0002a9a0, process id 0x8a4, application start time 0x01c9db40e46f7ea7.

Usually it shows this:
Faulting application PIDS.EXE, version 1.0.0.0, time stamp 0x00003039, faulting module PIDS.EXE, version 1.0.0.0, time stamp 0x00003039, exception code 0xc000008f, fault offset 0x0002e5af, process id 0x1b80, application start time 0x01c9db40601b7507.

[Chris Boss]

Gary,

This is a personal opinion, but personally I have found that it is some times better to "be" the debugger, rather than "depend" upon a debugger.

What I mean is that a software based debugger is limited, since it is not intelligent. Don't get me wrong, software debuggers are useful when used correctly, but they can't replace the intelligent mind of an experienced programmer.

More often I find things like a messagebox or even the beep command a better debugger than letting software do it. One must examine all the information your application provides and logically find the most probable cause of a problem.

One of the best places to start is a pencil and paper (I know, its awfully high tech). Run your application and make notes on paper of when the application crashes (what were you doing at the time). Note all the details that make be important.

Now see if you can replicate the crash. You should be able to do the exact same steps every time and it should behave exactly the same way every time (aka. crash).

Now examine the source code which was executed during or just before the crash (you should be able to figure out logically where it is).

The point is, don't depend upon the debugger so much. "Be" the debugger.

I have dealt with memory corruption before and often the app will crash at a place that simply put "does not make sense". The problem is that code executed earlier, did the memory corruption, but only later does other code "die" because of it.

This is why a notepad where you jot down all the details about exactly how your app is made to crash is important.

Let me illustrate:

You try all sorts of ways to make your app crash, but only when you follow steps A,B,C, D does it crash.

The app is crashing in step D.

The code which is executed at that point looks fine.

Now when you follow steps A,B, E, J, D in that order, the code in step D does not crash.

Why ?

Because memory was corrupted in possibly step C and because you didn't do step C, the step D does not crash.

You need to look at step D and then start tracing backwards to see what code was executed before it (when it crashed) and likely the culprit in somewhere in that earlier code.

Logic, my friend.

Thats your debugger!

[Richard Angell]

I would definitely play with TRACE statements to selectively cover small or large groups of code. I have found this helpful as well for homing in on code errors and oversights. Things like out of bounds can often be pinpointed more closely for some cases. If you turn trace on and off several times it hleps rather on big continual trace.

Have you Googled exception code 0xc000008f and exception code 0xc000008f. Might turn up a lead there for your particuar situation. Are you interacting with other programs. ports, etc.?

[Michael Mattias]

0005 is a page fault (request access to memory not owned)...but 008F (143d)?

%STATUS_FLOAT_INEXACT_RESULT     = &HC000008F???
...
%EXCEPTION_FLT_INEXACT_RESULT    = %STATUS_FLOAT_INEXACT_RESULT

EXCEPTION_FLT_INEXACT_RESULT The result of a floating-point operation cannot be represented exactly as a decimal fraction.

Figuring that one out is way beyond my pay grade.

Based on described application...all I can think of is, yes, you really did corrupt something somewhere.

[later]

Whoa there... just a minute....

I've tried
tools on
debug display on
debug code on
trace on

I don't see #DEBUG ERROR ON there. That may be enabled automatically when running in the stepping debugger (I don't use the SD), but that's the one which will tell you when you commit an array bounds violation.

I'd also suggest #DEBUG OVERFLOW ON , but that does not exist. Send those new feature suggestions to [email protected]

Also, take a look at Cliff Nichols' new (this week) debugging code. I haven't tried it, but it might be useful to you.

MCM