none
program doesn't crash when the debugger is attached

    Question

  • So I've got this problem that I can't debug.  I can't debug it, b/c when the debugger is attached, the problem magically disappears.

    I was stress testing my program with very large data sets and discovered that we have some sort of bug that's crashing our program when it's pushed to it's maximum capabilities.  The problem is that when I start the program with the debugger attached, it doesn't crash.  It completes processing successfully.  Also, if I attach the debugger after it's crashed, I don't have a usable call stack (the call stack doesn't go far enough back to see what the real cause was).  This is all with the release build btw.

    So how am I supposed to debug this?  And how is it even possible for the debugger to prevent my program from crashing?
    Monday, November 30, 2009 2:37 PM

All replies

  • Take a look at MVP Joe Newcomer's article "Surviving the Release Version":

    http://www.flounder.com/debug_release.htm

    David Wilkinson | Visual C++ MVP
    Monday, November 30, 2009 2:52 PM
  • Take a look at MVP Joe Newcomer's article "Surviving the Release Version":

    http://www.flounder.com/debug_release.htm

    David Wilkinson | Visual C++ MVP

    An excellent article, which I've even read before.  Not very helpful in this case.  The problem is that I need to debug my program when it crashes, but if I have the debugger attached, it doesn't crash.  I've never run into this before, and I have no idea why it would be happening or how to get around it.
    Monday, November 30, 2009 5:56 PM
  • Does it crash if you run it in Debug mode, but not under the debugger? Or if you remove optimization from the release build?

    David Wilkinson | Visual C++ MVP
    Monday, November 30, 2009 6:22 PM
  • When I've run the tests on the debug DLLs it was always with the debugger attached.  I've been meaning to try debug mode without the debugger attached, but the program takes 24+ hours of running to process the large test set using debug DLLs (with release DLLs it finishes overnight).  I haven't tried it yet b/c that basically means two days that I can't get any work done.  At the latest though, I could run it over the weekend.  So once I get that done, I can post the results.

    I haven't tried recompiling without optimizations, b/c that is not an option atm.
    Monday, November 30, 2009 7:54 PM
  • Hmmmm.... sounds like your hands are tied behind your back before you even get started.

    Pretty hard to give advice given this scenario. During our development process, we incorporate a lot of logging throughout our code which can be conditionally turned on and off. In our hands, that has proven almost indispensible in solving riddles such as this when the debugger cannot be used for whatever reason. Is it possible that you can start sprinkling your code with log messages? (Take a look at the Microsoft Enterprise Library for a high-speed and scalable logging solution)

    Secondly, I would suggest that you set up independent computers for your lab or QA environment. It needs to be completely separate. Who cares if it takes 2 or 3 days to run if it is running in parallel while you do other work? This is what the QA environment is for. Is this an option for your organization? Or are you strapped for resources?

    Monday, November 30, 2009 8:10 PM
  • Hello,

    Have you got any progress on this issue with the suggestion? If there is anything else we can help, welcome to post here.

    Thanks,
    Rong-Chun Zhang
    MSDN Subscriber Support in Forum
    If you have any feedback on our support, please contact msdnmg@microsoft.com


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Friday, December 04, 2009 10:56 AM
  • @Brian: Yeah it really is like that, and things seem to change at a glacial pace around here.  I'll make some suggestions though.  We don't have any logging built into the code, but I'm going to try throwing a bunch of trace points in and see if anything interesting pops out.

    @DaveWilk: Alright, I got a VM running this week and was able to run another test in debug (although it took longer than I expected).  It ran successfully without the debugger attached.  So that means the only time it crashes is running release without the debugger...  I'm going to try running it a bunch more times in release with the debugger attached.  I'm hoping that maybe I just got unlucky and the problem isn't completely consistent.
    Friday, December 04, 2009 10:09 PM
  • Hi,

    In application crash situation(debug/release), you can use any tools for creating user dump(dump is the memroy snapshot of your application code) which can be used for analysis. If you are able to link the .pdb files of Release/debug version, it will give you exact line of code which was executed when a first chance of 2nd chance exception occurs.

    You can use MS DebugDiag tool for this. This simple and stright fwd use.

    I think the possible reason for crash while attaching the debuger, is code injection is getting failed, which makes unhandled exception and target application crashes.

    you can try with above tool, it can help you to analize memory leaks too.

    Monday, December 07, 2009 10:22 AM
  • There is a difference between running your program by hitting F5 (Debug > Start Debugging ) and just launching it with Ctrl+F5 (Debug > Start Without Debugging ) then attaching the debugger after the process is started.  They will use different heaps.

    Start your application either with Ctrl+F5 (Start Without Debugging ), or manually, and after the process is running, attach the debugger by using Debug > Attach to Process...


    * ALSO *

    Your environment variables may be different when launched in the debugger, particularly your PATH.  And your Working Directory may be different.  Verify that all these things are the same, or that they cannot be responsible for your crash.

    Other than that, it is likely a race condition, where timing of execution of threads is responsible for the problem.
    • Proposed as answer by Wyck Wednesday, December 23, 2009 8:56 PM
    Monday, December 07, 2009 7:29 PM
  • So I've got this problem that I can't debug.  I can't debug it, b/c when the debugger is attached, the problem magically disappears.

    I was stress testing my program with very large data sets and discovered that we have some sort of bug that's crashing our program when it's pushed to it's maximum capabilities.  The problem is that when I start the program with the debugger attached, it doesn't crash.  It completes processing successfully.  Also, if I attach the debugger after it's crashed, I don't have a usable call stack (the call stack doesn't go far enough back to see what the real cause was).  This is all with the release build btw.

    So how am I supposed to debug this?  And how is it even possible for the debugger to prevent my program from crashing?

    Hi,
     I suppose I should read all the questions and answers above before responding but I think I have got the idea.
    I had the same problem some time ago and I kind of solved it with the following:

    use this to switch off optimization in parts of code:
    #pragma optimize( "", off )
    and this:
    #pragma optimize( "", on )
    to switch it on again to find the problem with the code;

    So with a bit of work one can isolate where the optimized code is causing the problem.

    Hope this helps.
    Ciao,
    Marc646464
    Thursday, December 17, 2009 12:58 AM