Some information relates to prerelease product that may be substantially modified before it’s released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
Signals a breakpoint to an attached debugger.
public: static void Break();
public static void Break ();
static member Break : unit -> unit
Public Shared Sub Break ()
The UIPermission is not set to break into the debugger.
The following code example demonstrates how to stop the debugger at the call to WriteLine.
Debugger.Break() Console.WriteLine("Hello, world.")
Debugger.Break(); Console.WriteLine("Hello, world.");
If no debugger is attached, users are asked if they want to attach a debugger. If users say yes, the debugger is started. If a debugger is attached, the debugger is signaled with a user breakpoint event, and the debugger suspends execution of the process just as if a debugger breakpoint had been hit.
Starting with .NET Framework 4, the runtime no longer exercises tight control of launching the debugger for the Break method, but instead reports an error to the Windows Error Reporting (WER) subsystem. WER provides many settings to customize the problem reporting experience, so a lot of factors will influence the way WER responds to an error such as operating system version, process, session, user, machine and domain. If you're having unexpected results when calling the Break method, check the WER settings on your machine. For more information on how to customize WER, see WER Settings. If you want to ensure the debugger is launched regardless of the WER settings, be sure to call the Launch method instead.