15

I recently changed one of the options in the debugger and I think that is what is causing this problem but I can't seem to 'undo' it...I google and all hits come back with the opposite 'why does the debugger not stop on a breakpoint'

anyway can someone shed some light?

EDIT: when I press f5 in debug mode. Everytime. It goes into the Program.cs and stops on

Application.SetCompatibleTextRenderingDefault(false);

in the Main()

Andrew Barber
  • 39,603
  • 20
  • 94
  • 123
kurasa
  • 5,205
  • 9
  • 38
  • 53
  • 1
    What to you mean, 'stops'? How often? In what circumstance? – bmargulies Oct 25 '11 at 22:57
  • Is it stopping because of an exception? – Tim Oct 25 '11 at 23:00
  • 1
    Some debuggers have a mechanism to pause on startup, or to start paused, so that one can set breakpoints in startup code. I don't know if VS2010 has such an option. – Dan Davies Brackett Oct 25 '11 at 23:11
  • It is the first statement in your Main() method. Ought to have something to do with it. – Hans Passant Oct 25 '11 at 23:31
  • 2
    Just a random suggestion... breakpoint locations are stored in the .suo file (at the root of your project, where the .sln file is - make sure you can view hidden files). There's no big harm in deleting this file, as it will be recreated when you close the solution. Try closing VS, deleting the .suo file, re-opening, and see if that makes the problem go away. – Patrick Pitre Oct 26 '11 at 01:28
  • The keyboard shortcut `F5` isn't bound to `Step Into`, by any chance? – ta.speot.is Jan 21 '12 at 03:27

4 Answers4

32

Old thread I know, But I just encountered the same problem. All I did was a Delete All Breakpoints (Ctrl+Shift+F9 for me), then a Clean on my startup project, followed by a Rebuild, then Run. After that it stopped breaking where there were no breakpoints.

Chris Ray
  • 4,833
  • 2
  • 20
  • 19
  • 10
    I've noticed that this tends to happen when you have breakpoints set in files that have the same name as other files. For example if you have two "Program.cs" files in different projects, with breakpoints set in one, the debugger seems to stop on those lines in the other files – Chris Ray Aug 31 '12 at 14:13
  • Good find! Wasted an hour on this – Gulzar Jan 09 '18 at 13:37
6

I just experienced the same problem however mine isn't due to a option change. I think I have found the reason why but no resolution to fix it. I have a Solution with multiple projects, the projects involved are:

  • Business Logic
  • Data Access
  • Console App

In both BL and DA I have a class called Credit.cs. Both classes are in different namespaces.

When I set a breakpoint on line 235 in BL.Credit.cs then the debugger stops on line 236 in DA.Credit.cs even though there are no breakpoints set. I think this is a bug in Visual Studio.

When I remove the breakpoint in BL is subsequently does not stop in the DA either.

I have submitted a bug if you wish to vote https://connect.microsoft.com/VisualStudio/feedback/details/699804/debugger-stops-on-same-line-in-different-class-where-there-is-no-breakpoint

Eugene Niemand
  • 721
  • 6
  • 28
4

Here's a workaround for the behavior of breakpoints activating in each class that has the same name even if fully-qualified names are different. After you set a breakpoint, go to the Breakpoints window (Debug | Windows | Breakpoints if it isn't already up). Right-click the breakpoint that's firing in too many same-named classes (e.g. Project2.Action breaks when you only wanted Project1.Action to have a breakpoint) and selection "Condition." Set the condition value to something like this: this.GetType().FullName == "Project1.Action".

Thereafter, the condition makes it so that execution only breaks on the class with the correct fully-qualified name.

earth_tom
  • 831
  • 1
  • 5
  • 13
  • I used next for visual basic: `Me.GetType().FullName.Contains("Business")`. Non exact match if has many classes to work with. – Dzmitry Lahoda Aug 20 '14 at 10:53
0

Does it stop by giving you an exception or does it just completely stop the execution of your application? If you don't have the UnHandledExceptionHandler in your code it can look like it just stops but you actually have an exception.

UPDATE: Here is what your Main method should look like to capture unhandled exceptions as try/catch don't always work.

    /// <summary>
    /// The main entry point for the application.
    /// </summary>
    [STAThread]
    static void Main()
    {
        AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
        Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);

        Application.EnableVisualStyles();
        Application.SetCompatibleTextRenderingDefault(false);
        Application.Run(new Form1());
    }

    static void Application_ThreadException(object sender, System.Threading.ThreadExceptionEventArgs e)
    {
        throw new NotImplementedException();
    }

    static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
    {
        // You should/MAY see an error right here.
        throw new NotImplementedException();
    }
Scott Wylie
  • 4,725
  • 2
  • 36
  • 48
  • it just stops and then I press F5 again and it continues just fine. – kurasa Oct 25 '11 at 23:02
  • Do you have the event handler for unhandled exceptions per above? If you don't you won't see anything, it just ends. – Scott Wylie Oct 25 '11 at 23:07
  • placed a try catch around it an no exceptions raise - It runs just fine. There is no error on inconvenience of always having to press the f5 3 times – kurasa Oct 25 '11 at 23:16
  • thanks for the code but still doing it. I pasted your 2 event handling lines above the EnableVisualstyles line just like your example and now it breaks 2 lines further down. I remember making a modification to Tools -> Debugging a while back for a reason I can now not even remember and I modified some option from an article I'd read on google and ever since it has done this. I am sure it has got something to do with one of the debug options but I don't know which none... – kurasa Oct 25 '11 at 23:51