Windows application crashes without a trace.

I am developing a multithreaded application in C++ under VS2003 for WinXP.
Once in a long while my application disappears without a trace. It vanishes as if it never existed. Not a "unhandled exception", not a BSOD. Nothing. one minute its there, the next minute its gone.
I am catching C++ exceptions on all the threads' exit points, so its not an unhandled exception.
How does one debug such a crash?
Thank
S.

Quote:

---

Originally Posted by sangati

I am catching C++ exceptions on all the threads' exit points, so its not an unhandled exception.

---

Just a word of advice:

There have been many threads started where the claim is "I have checked everything, so the problem isn't xxxxx", and then when we get to look at the code, the problem is what was claimed couldn't happen. What results is that a lot of time and energy gets wasted by persons responding to you if indeed the case is an unhandled exception that you were not aware of, and we're led to initially believe there is no unhandled exception.

An app disappearing can happen if it terminates normally (i.e. WinMain or main() has finished executing), or if an unhandled exception is not caught.

Note that exceptions come in two types - C++ exceptions, and the exceptions that Windows OS has, i.e, access violations, divide by zero, etc. If your code is only checking C++ exceptions, it will not catch the Windows (SEH) exceptions, and vice-versa.

Quote:

---

How does one debug such a crash?

---

Run your program under the debugger. When it crashes, the call stack will appear, and you can see what series of calls led to the crash.

Regards,

Paul McKenzie

Thanks Paul
It's a good point about re-checking the obvious, I'll do that.
The problem with the debugging suggestion though is that it never crashes under the debugger, so I never get a call stack.
Thanks
Sangati

Quote:

---

The problem with the debugging suggestion though is that it never crashes under the debugger, so I never get a call stack.

---

Then

1) There is ansumption you are making which is true for debug builds, but not release builds

or

2) You are not testing the exact same configuration when you are running under the debugger.


There is NO other possible alternative.

I'm running debug mode in both cases. One with the debugger and one without. Debuggers often create a slightly different image from non debugger code (planting break points if nothing else, adding extra data to stack frames etc, although I don't know if VS debugger does that). So if the crash is due to memory curroption, a slightly different image would be enough to eliminate it. Wouldn't it?

It is like memory overflow. it will cause a crash wihout unhandled exception. In this case, you maybe canot using try catch to catch the exception.

Quote:

---

Originally Posted by sangati

I'm running debug mode in both cases. One with the debugger and one without.

---

Run without the debugger, and then while you're program is running, debug it by attaching the debugger to the running process.

Regards,

Paul McKenzie

Paul
Briliant.
So obvious, how come I didn't think of it my self?
Thanks
This catches the program on the crash.
Its an unhandled exception in ntdll.dll.

ntdll.dll!7c90eaf4()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
kernel32.dll!7c8095ab()
ntdll.dll!7c910d5c()
ntdll.dll!7c910e91()
ntdll.dll!7c91056d()
vps.exe!_lock_fhandle(int fh=3) Line 453 C
vps.exe!_write(int fh=-572662307, const void * buf=0xdddddddd, unsigned int cnt=3722304989) Line 87 + 0x9 bytes C
vps.exe!_write(int fh=-572662307, const void * buf=0xdddddddd, unsigned int cnt=3722304989) Line 83 + 0x13 bytes C
00942810()

My code (vps.exe) is only indirectly mentioned but its a good starting point.

A million thanks.
Sangati

Thanks again Paul.
It was a grabage variable as the size parameter to a memcpy call on the local stack. It destroyed the stack alright.
Its working now.
Thanks