Visual Studio Debugging - revisiting same memory state
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 7 of 7

Thread: Visual Studio Debugging - revisiting same memory state

  1. #1
    Join Date
    Aug 2009
    Posts
    68

    Visual Studio Debugging - revisiting same memory state

    Hello,

    When running my code in Visual Studio, there is a particular point in the code where my program is crashing. To debug this, I am adding a break point in Debug mode just before that point, and observing what happens as I step through the code. However, to get to this break point in the code takes about a minute of running the program. So I'm wondering if there is a tool in Visual Studio to reload the state of a program's memory from a previous run, so that I can immediately get to the break point without having to wait for a minute each time?

    Thanks!

  2. #2
    Join Date
    Apr 1999
    Posts
    27,429

    Re: Visual Studio Debugging - revisiting same memory state

    Quote Originally Posted by karnavor View Post
    Hello,

    When running my code in Visual Studio, there is a particular point in the code where my program is crashing. To debug this, I am adding a break point in Debug mode just before that point, and observing what happens as I step through the code. However, to get to this break point in the code takes about a minute of running the program.
    What if this "minute of running the program" is what causes the ultimate crash, or at least makes it reproducible?

    You shouldn't be changing any behaviour in the program if you're trying to debug a crash. Doing so may make that crash no longer appear.

    If the wait is truly innocuous, then change the code to skip the code that waits, or change the code to make the wait shorter, or while debugging, change the value of variables or change execution paths (Set Next Statement, for example) to skip the slow code.

    But still, my warning stands -- change the code or execution path during debugging, and you may not be able to recreate the problem if the problem is one of memory corruption or issues similar to that.

    Regards,

    Paul McKenzie
    Last edited by Paul McKenzie; October 31st, 2013 at 01:26 PM.

  3. #3
    GCDEF is offline Elite Member Power Poster
    Join Date
    Nov 2003
    Posts
    12,106

    Re: Visual Studio Debugging - revisiting same memory state

    Seems like waiting one minute isn't that big a deal. You should be able to figure it out within a few runs.

  4. #4
    Join Date
    Aug 2000
    Location
    New York, NY, USA
    Posts
    5,526

    Re: Visual Studio Debugging - revisiting same memory state

    Quote Originally Posted by karnavor View Post
    ... So I'm wondering if there is a tool in Visual Studio to reload the state of a program's memory from a previous run, so that I can immediately get to the break point without having to wait for a minute each time?
    I would try to create a dump using MiniDumpWriteDump() function at the point you are interested in.
    Then you can load this dump as many time as you want and start debugging.
    This, of course, require a special build, so I am not sure if you can save any time with that.
    Vlad - MS MVP [2007 - 2012] - www.FeinSoftware.com
    Convenience and productivity tools for Microsoft Visual Studio:
    FeinViewer - an integrated GDI objects viewer for Visual C++ Debugger, and more...

  5. #5
    Join Date
    Nov 2000
    Location
    Voronezh, Russia
    Posts
    5,990

    Re: Visual Studio Debugging - revisiting same memory state

    In fact, it can be done even with a regular debug build. You put a breakpoint wherever you need to start from, and wait until it gets hit. Then in the bottom of Debug menu VS will provide an entry something like Save Dump As.
    Best regards,
    Igor

  6. #6
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    3,920

    Re: Visual Studio Debugging - revisiting same memory state

    if it's because you are passing the breakpoint many times before the case that actually fails.
    either add some that manages a counter or a timer and set a breakpoint inside a conditional.
    Code:
       ... code..
       static int i=0;
       if (++i == 1234)  // <-  whatever condition you want here
             i=i;       // <- set breakpoint here instead
       TheFunctionWithTheOriginalBreakPoint();
       ... more code...
    or add a condition to the breakpoint trigger.


    The problem is that the first method may cause the problem to go away or manifest itself in another manner. This is a sign of a very hard to track down bug, typically a memory overwrite somewhere, the point of failure can be totally different from the point of detection.
    THe problem with the 2nd method is that it may slow down debugging significantly, or it may be impossible to codify in the breakpoint condition system of VS.

  7. #7
    Arjay's Avatar
    Arjay is offline Moderator / MS MVP Power Poster
    Join Date
    Aug 2004
    Posts
    11,307

    Re: Visual Studio Debugging - revisiting same memory state

    We're talking about a minute, not several days of running. Have a little patience. <g>

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center