Debugger.Break Method ()


The .NET API Reference documentation has a new home. Visit the .NET API Browser on to see the new experience.

Signals a breakpoint to an attached debugger.

Namespace:   System.Diagnostics
Assembly:  mscorlib (in mscorlib.dll)

public static void Break()

Exception Condition

The System.Security.Permissions.UIPermission is not set to break into the debugger.

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.

The following code example demonstrates how to stop the debugger at the call to WriteLine.

Console.WriteLine("Hello, world.");


for permission to start a debugger. Associated enumeration: PermissionState.Unrestricted


for operating with unmanaged code. Associated enumeration: SecurityPermissionFlag.UnmanagedCode Security action: Demand.

Universal Windows Platform
Available since 8
.NET Framework
Available since 1.1
Portable Class Library
Supported in: portable .NET platforms
Available since 2.0
Windows Phone Silverlight
Available since 7.0
Windows Phone
Available since 8.1
Return to top