views:

152

answers:

7

I find often that breakpoint on line of code I know are executing do not break correctly.
It also often “runs away” when I do a “step over”, or “step into” etc.

Details.

  • Microsoft Visual Studio 2008 Version 9.0.30729.1 SP
  • Microsoft .NET Framework Version 3.5 SP1
  • The code is a mixture of VB.NET and C# with most of the code in VB.NET.
  • There are a lot of active threads
  • A lot of exceptions are throw and caught by the software.
  • Microsoft(R) Windows(R) Server 2003, Standard Edition

Some other people on the team have seen this problem at different times, but on one know how they fixed it!


Update, thinks for all the useful answers they will help other peole that hit this problem.

Hot fix KB957912 - Updates for Visual Studio 2008 SP1 debugging and breakpoints

Microsoft has released updates for Microsoft Visual Studio 2008 SP1 debugger components. These updates mostly address issues that occur with stepping and with hitting breakpoints.

This seems to have sorted the problmes out for me.

+1  A: 

Most often that is because your code is optimized away. You need a debug build to ensure that the generated executables remain the same line for line at runtime.

Blindy
Thanks, this is not my problem I have check that everywere I am trying to break into is build for debug
Ian Ringrose
A: 

If you have a lot of threads, then this can happen - because multiple threads will trigger different breakpoints. So keep the thread window open to see if you're still on the same thread. Also timestamped tracing/logging might be a better option in this scenario than stepping through code in a multi-threaded app.

The other scenario where this can happen is that the binaries and pdb's don't match. So go for a full rebuild with optimizations turned off.
HTH

Gishu
I am not getting a different breakpoint hit, so I don't think it is due to breaks point being hit in another thread
Ian Ringrose
+1  A: 

Make sure your code and pdb files are in sync. You may need to clean/rebuild the solution if this is occuring.

Paolo
A: 

This Will happen if you are using threads

if you aren't,try to rebuild your application

+1  A: 

Few things:

  1. First clean the solution using the "clean solution".
  2. Run the program in debug mode
  3. Remove all the breakpoints and put a breakpoint where you intend to check.
  4. If its multithread, you might get a breakpoint stop at some time or may get delayed because of breakpoints at other parts of the code.
  5. Ensure your code is reachable where you put a breakpoint. Code below may not every raise a breakpoint break in the else block,

    if(true)

    printf("Hello world");

    else

    printf("no hello world");

You would see the code never reached else part of no hello world.

This may sound funny. But closing the solution and visual studio and deleting directoris like release/debug and restarting system may do the trick.

Kavitesh Singh
+1  A: 

Perhaps a stupid question and it's fairly unlikely as it sounds like your behaviour is intermittent, but I've not seen anyone else ask it - have you checked to make sure you don't have any of the procedures with System.Diagnostics.DebuggerStepThrough attribute set on them?

Doogie
Thats not the problem, as the debuger would just stop on the line after the call. Also we don't have DebuggerStepThrough on most of our code.
Ian Ringrose
A: 

Hot fix KB957912 - Updates for Visual Studio 2008 SP1 debugging and breakpoints

Microsoft has released updates for Microsoft Visual Studio 2008 SP1 debugger components. These updates mostly address issues that occur with stepping and with hitting breakpoints.

This seems to have sorted the problmes out for me.

Ian Ringrose