Prev: wlan Info
Next: Obtain Window Handle & Send a variable to it
From: Rahul on 5 May 2010 12:26
Hi All,

We have a VC++ application (Native) developed in VSTS 2008. Sometimes
the application just vanishes without showing any crash dialog (The
default Windows Error Handler dialog) or generating any crash dump.
This happens in many systems which have identical installation,
Windows XP (SP3) with Windbg installed as the default debugger which
catches the exceptions and shows stack trace 99% of the time. But
sometimes the application just vanishes as if it had executed exit(0)
(Nothing in the TaskManager also)

Are there some exceptions which even WinDbg can not catch and hence
the program just terminates, What could be the other reasons for this.

Thanks in advance
Rahul
From: Alf P. Steinbach on 5 May 2010 12:46
* Rahul:
>
> We have a VC++ application (Native) developed in VSTS 2008. Sometimes
> the application just vanishes without showing any crash dialog (The
> default Windows Error Handler dialog) or generating any crash dump.
> This happens in many systems which have identical installation,
> Windows XP (SP3) with Windbg installed as the default debugger which
> catches the exceptions and shows stack trace 99% of the time. But
> sometimes the application just vanishes as if it had executed exit(0)
> (Nothing in the TaskManager also)
>
> Are there some exceptions which even WinDbg can not catch and hence
> the program just terminates, What could be the other reasons for this.

At least with g++, which uses the old msvcrt.dll MS runtime library, a stack
overflow can generate your observed behavior.

This is typically caused by an infinite recursion.

With novice programmers (so prevalent in the industry, many of them with 5+
years experience) it can conceivably also be caused by large raw arrays as
locals, including use of Microsoft's alloca-based Unicode/char conversion.

In either case it might help to turn on stack probe checking and try to
reproduce the faults. In the very last case, stack based string conversions, a
fix might be to make the app Unicode only. I.e., simply avoiding conversions.

But it sounds like your application is prone to crashing.

This might be caused by bad use of raw pointers, which in turn is caused by
complexity, which is a euphemism for spaghetti.

If that's the case then it's much more difficult to track down, because memory,
including the stack, might be corrupted in a way "just so" to foil your
detection attempt (this is a consequence of Murphy's law).


Cheers & hth.,

- Alf
From: Goran on 5 May 2010 13:07
+1 for Alf, stack exhaustion is the culprit no. 1.

Goran.
From: Rahul on 5 May 2010 13:58
Thanks Alf,

So infinite recursion and large stack based array's seems to be the
problem. But why does the default debugger not catch these crashes.
I even tried on the system where Visual Studio was installed, It also
failed to catch those exceptions (unless we run the program the inside
debugger itself)

Is there any way to catch these crashes without running the program in
the debugger, and why are they not caught by the debugger by default
(just for understanding the technical difficulty involved in this).

Thanks
Rahul
From: Jochen Kalmbach on 5 May 2010 14:24
Hi Rahul!

> Is there any way to catch these crashes without running the program in
> the debugger, and why are they not caught by the debugger by default
> (just for understanding the technical difficulty involved in this).

The WER/Default-Debugger is called from within the application. If the
application is not able to catch the unhandled exception, then WER will
not be called.
In Vista / Windows 7 there was some improvement in the OS to better
handle such situations.

Greetings
Jochen
 |  Next  |  Last
Pages: 1 2
Prev: wlan Info
Next: Obtain Window Handle & Send a variable to it