1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Application disappears without any crash dump

Discussion in 'Windows XP' started by Rahul, May 5, 2010.

  1. Rahul

    Rahul Flightless Bird

    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
     
  2. Alf P. Steinbach

    Alf P. Steinbach Flightless Bird

    * 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
     
  3. Goran

    Goran Flightless Bird

    +1 for Alf, stack exhaustion is the culprit no. 1.

    Goran.
     
  4. Rahul

    Rahul Flightless Bird

    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
     
  5. Jochen Kalmbach

    Jochen Kalmbach Flightless Bird

    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
     
  6. Charlie Gibbs

    Charlie Gibbs Flightless Bird

    In article
    <1509753c-6b6d-4459-8db0-13597ede8843@h37g2000pra.googlegroups.com>,
    rsharma.champ@gmail.com (Rahul) writes:

    > 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).


    My favourite way of dealing with these things is to define a buffer
    on either site of the local variables:

    void myfunc ()
    {
    char buffer1[512];
    ... other local variables ...
    char buffer2[512];

    memset ((void *) buffer1, 0, sizeof (buffer1));
    memset ((void *) buffer2, 0, sizeof (buffer2));
    ... code ...
    }

    Often that's enough to stop the mysterious disappearances. You can
    then check "buffer1" and "buffer2" at various points in the code to
    see whether they suddenly become nonzero. That should catch simple
    overflows, but a truly wild pointer could clobber the stack far
    enough away that nothing bad happens until the program exits.
    Still, it's a start...

    --
    /~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
    \ / I'm really at ac.dekanfrus if you read it the right way.
    X Top-posted messages will probably be ignored. See RFC1855.
    / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
     
  7. r_z_aret@pen_fact.com

    r_z_aret@pen_fact.com Flightless Bird

    On Wed, 5 May 2010 10:58:29 -0700 (PDT), Rahul
    <rsharma.champ@gmail.com> wrote:

    >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,


    Adding ASSERTs to do sanity checks on pointers just before they are
    used can trap many pointer problems. This is less painful if done
    while coding. With luck and thought, you might be able to add them
    iteratively now: add some in places most likely to trap an error, keep
    adding until one triggers, then use the one that triggered to choose
    where to add more. Repeat as necessary.

    ASSERTs to test arrays that might be clobbered give less direct clues,
    but are better than nothing. And some clues you see while running a
    program point more directly to an array.

    Adding some way to monitor progress of the program can help you find
    the part of your source code that causes a crash. I've used calls to
    MessageBox. I add at least one to code I'm pretty sure runs before the
    crash and at least one to code I'm pretty sure runs after the crash.
    And after each crash, I narrow the gap between calls. This is very low
    tech, and seems painful. But often enough, I can rather quickly narrow
    the gap enough for me to see the likely problem, blanket the code with
    ASSERTs, and/or step through with a debugger.

    >
    >Thanks
    >Rahul


    -----------------------------------------
    To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

    Robert E. Zaret, MVP
    PenFact, Inc.
    20 Park Plaza, Suite 400
    Boston, MA 02116
    www.penfact.com
    Useful reading (be sure to read its disclaimer first):
    http://catb.org/~esr/faqs/smart-questions.html
     
  8. Charlie Gibbs

    Charlie Gibbs Flightless Bird

    In article <5u56u5d7vl1qqkmlq2jgk6i5jnmg0rati9@4ax.com>,
    r_z_aret@pen_fact.com (r_z_aret) writes:

    > Adding some way to monitor progress of the program can help you find
    > the part of your source code that causes a crash. I've used calls to
    > MessageBox. I add at least one to code I'm pretty sure runs before the
    > crash and at least one to code I'm pretty sure runs after the crash.
    > And after each crash, I narrow the gap between calls. This is very low
    > tech, and seems painful. But often enough, I can rather quickly narrow
    > the gap enough for me to see the likely problem, blanket the code with
    > ASSERTs, and/or step through with a debugger.


    If you narrow it down using a kind of binary search, the process can
    indeed be fairly fast.

    A variation of this is to #ifdef out chunks of your code, if necessary
    replacing them with a dummy routine that inserts needed values. Once
    you get the program to stop crashing, start re-enabling sections of
    code until it resumes crashing. Again, a binary search technique can
    speed up the process. A possible fly in the ointment (which applies
    to any technique that adds or removes code) is that the clobbered
    memory location might move to someplace non-critical, giving the
    illusion that you've found the bug when it's really just gone into
    hiding.

    --
    /~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
    \ / I'm really at ac.dekanfrus if you read it the right way.
    X Top-posted messages will probably be ignored. See RFC1855.
    / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
     

Share This Page