tags:

views:

353

answers:

1

http://support.microsoft.com/kb/953102

We spent about 50 hours during Christmas holiday to identify this problem, causing our business critical production app to crash randomly.

The problem was that there was no stack trace to the source code, only native code like NativeWindow.Callback on the bottom of the stack trace.

Any tools out there that you would have used to debug this kind of problem?

+4  A: 

If you can tolerate it, add lots of logging.

Take a guess at where it's happening and bracket that code in entered Foo and exited Foo logs. Then if you see one but not the other on a crash, you known it's in there somewhere so start a binary (or n-ary) search diving into functions as needed. To some extent you will need to roll up the carpet behind you to keep the size of the log down but as long as the crash can be produced reasonably often you should be able to zero in on it that way.

I have an app that I've done this with (I can't debug it any other way in it's intended environment) and found it to be effective, Also it's kinda impressive to say you've worked with 1M+ line log files (to much logging, and to big a test case <g>)

BCS
Yup, divide and conquer is your friend.
plinth

related questions