Debug window

Debug toolbar

Item	Tooltip and Shortcut	Description
	Rerun `CtrlShiftF5`	Click this button to stop the current application and run it again.
	Resume Program `F5`	When an application is paused, click this button to resume program execution.
	Pause Program `Ctrl+Pause`	Click this button to pause program execution.
	Stop `ShiftF5`	Click this button to terminate the current process .
	View Breakpoints `CtrlAlt0B`	Click this button to open the Breakpoints dialog where you can configure breakpoints behavior.
	Mute Breakpoints	Use this button to toggle breakpoints status. You can temporarily mute all breakpoints in the project to execute the program without stopping at breakpoints.
	Debugger Settings	Opens the menu with the following options: Open Files in Preview Tab: select this option to open files in a preview tab when the corresponding frame is selected. Show Variable Values in Editor: select this option to enable the Inline Debugging feature that allows viewing the values of variables right next to their usage in the editor. Sort Variables Alphabetically: select this option to sort the values in the Variables pane in the alphabetical order. Unmute Breakpoints on Session Finish: select this option to re-enable all disabled breakpoints after the debugging session has been finished.
	Pin Tab	Click this button to pin or unpin the current tab. You may need to pin a tab to prevent it from closing automatically when the maximum number of tabs is reached in this window.

Stepping toolbar

Item	Tooltip and Shortcut	Description
	Show Execution Point `AltNumPad *`	Click this button to highlight the current execution point in the editor and show the corresponding stack frame in the Frames pane.
	Skip to Cursor `CtrlShiftF10`	Instead of running the program up to the target statement, you may want to skip a part of code without actually executing it (for example, to avoid a known bug or not to repeat some routine). You can do this with the Skip to Cursor command `CtrlShiftF10`that is also available in the Run menu and in the Debug window. You can also skip a part of the program by dragging the execution pointer with your mouse and dropping it to the target line: You can also hover over the target statement and then pick the corresponding action: tip If you are familiar with Visual Studio or Visual Studio Code, the same action is called Set Next Statement in Visual Studio and Jump to Cursor in Visual Studio Code. Remember the following when you jump to another statement: Statements between the old and the new execution points are not executed. You can jump back, that is to a statement that was already executed. In this case the already executed statements are not undone. It is impossible to set the next statement in another function.
	Step Over `F10`	Click this button to execute the program until the next line in the current method or file, skipping the methods referenced at the current execution point (if any). If the current line is the last one in the method, execution steps to the line executed right after this method.
	Force Step Over `AltShiftF8`	Click this button to have the debugger step over the method even if this method has breakpoints inside.
	Step Into `F11`	Click this button to have the debugger step into the method called at the current execution point. The debugger will set the execution pointer at the first statement of the first function called from the current line. If no function is called, then the debugger will step to the next statement. tip You can also inspect the call hierarchy without debugging your program. By default, JetBrains Rider enables external-source debugging, which means that when you step into the library code it will be automatically decompiled and the debugger will move the execution point there. If you want the debugger to ignore the library code, you can disable external-source debugging —clear Enable external source debug on the Build, Execution, Deployment \| Debugger page of JetBrains Rider settings `CtrlAlt0S`.
	Smart Step Into `AltShiftF11`	If the current line contains several nested calls, JetBrains Rider lets you choose a call to step into. Consider the following code line: `Console.WriteLine(Foo(Bar("input") + Baz("input")));` The line contains several calls and if you use Step Into, the debugger will first step into the implementation of `Bar()`, then into the implementation of `Baz()` and so on. tip Methods decorated with the [DebuggerStepThrough] attribute are not suggested as stepping targets. If you want to choose which of the calls should be stepped into, for example, `Bar()`, you can use Smart Step Into `AltShiftF11`: When you choose the function to step into, the debugger will set the execution pointer at the first statement of the selected function. The selector also shows you which of the calls were already executed and allows you to execute these calls again. You can enable the 'smart step into' behavior when you invoke Step Into `F11` in a line that contains multiple method calls. To do so, select Always do smart step into on the Build, Execution, Deployment \| Debugger \| Stepping settings page `CtrlAlt0S`.
	Step Out `ShiftF11`	Click this button to have the debugger step out of the current method, to the line executed right after it.
	Run to Cursor `CtrlF10`	Click this button to resume program execution and pause until the execution point reaches the line at the current caret location in the editor. No breakpoint is required. Actually, there is a temporary breakpoint set for the current line at the caret, which is removed once program execution is paused. Thus, if the caret is positioned at the line which has already been executed, the program will be just resumed for further execution, because there is no way to roll back to previous breakpoints. This action is especially useful when you have stepped deep into the methods sequence and need to step out of several methods at once. If there are breakpoints set for the lines that should be executed before bringing you to the specified line, the debugger will pause at the first encountered breakpoint. You can also hover over the target statement and then pick the corresponding action:
	Run to Cursor Non-Stop `CtrlAltF9`	If there are breakpoints between the current execution point and the target statement, you can force the debugger to skip these breakpoints with the Run to Cursor Non-Stop command `CtrlAltF9`.
	Evaluate Expression `CtrlAlt0Q`	Click this button to evaluate expressions.

Item	Tooltip and Shortcut	Description
	Show Execution Point `AltNumPad *`	Click this button to highlight the current execution point in the editor and show the corresponding stack frame in the Frames pane.
	Skip to Cursor `CtrlShiftF10`	Instead of running the program up to the target statement, you may want to skip a part of code without actually executing it (for example, to avoid a known bug or not to repeat some routine). You can do this with the Skip to Cursor command `CtrlShiftF10`that is also available in the Run menu and in the Debug window. You can also skip a part of the program by dragging the execution pointer with your mouse and dropping it to the target line: You can also hover over the target statement and then pick the corresponding action: tip If you are familiar with Visual Studio or Visual Studio Code, the same action is called Set Next Statement in Visual Studio and Jump to Cursor in Visual Studio Code. Remember the following when you jump to another statement: Statements between the old and the new execution points are not executed. You can jump back, that is to a statement that was already executed. In this case the already executed statements are not undone. It is impossible to set the next statement in another function.
	Step Over `F10`	Click this button to execute the program until the next line in the current method or file, skipping the methods referenced at the current execution point (if any). If the current line is the last one in the method, execution steps to the line executed right after this method.
	Force Step Over `AltShiftF8`	Click this button to have the debugger step over the method even if this method has breakpoints inside.
	Step Into `F11`	Click this button to have the debugger step into the method called at the current execution point. The debugger will set the execution pointer at the first statement of the first function called from the current line. If no function is called, then the debugger will step to the next statement. tip You can also inspect the call hierarchy without debugging your program. By default, JetBrains Rider enables external-source debugging, which means that when you step into the library code it will be automatically decompiled and the debugger will move the execution point there. If you want the debugger to ignore the library code, you can disable external-source debugging —clear Enable external source debug on the Build, Execution, Deployment \| Debugger page of JetBrains Rider settings `CtrlAlt0S`.
	Smart Step Into `AltShiftF11`	If the current line contains several nested calls, JetBrains Rider lets you choose a call to step into. Consider the following code line: `Console.WriteLine(Foo(Bar("input") + Baz("input")));` The line contains several calls and if you use Step Into, the debugger will first step into the implementation of `Bar()`, then into the implementation of `Baz()` and so on. tip Methods decorated with the [DebuggerStepThrough] attribute are not suggested as stepping targets. If you want to choose which of the calls should be stepped into, for example, `Bar()`, you can use Smart Step Into `AltShiftF11`: When you choose the function to step into, the debugger will set the execution pointer at the first statement of the selected function. The selector also shows you which of the calls were already executed and allows you to execute these calls again. You can enable the 'smart step into' behavior when you invoke Step Into `F11` in a line that contains multiple method calls. To do so, select Always do smart step into on the Build, Execution, Deployment \| Debugger \| Stepping settings page `CtrlAlt0S`.
	Step Out `ShiftF11`	Click this button to have the debugger step out of the current method, to the line executed right after it.
	Run to Cursor `CtrlF10`	Click this button to resume program execution and pause until the execution point reaches the line at the current cursor location in the editor. No breakpoint is required. Actually, there is a temporary breakpoint set for the current line at the caret, which is removed once program execution is paused. Thus, if the caret is positioned at the line which has already been executed, the program will be just resumed for further execution, because there is no way to roll back to previous breakpoints. This action is especially useful when you have stepped deep into the methods sequence and need to step out of several methods at once. If there are breakpoints set for the lines that should be executed before bringing you to the specified line, the debugger will pause at the first encountered breakpoint. You can also hover over the target statement and then pick the corresponding action:
	Run to Cursor Non-Stop `CtrlAltF9`	If there are breakpoints between the current execution point and the target statement, you can force the debugger to skip these breakpoints with the Run to Cursor Non-Stop command `CtrlAltF9`.
	Evaluate Expression `CtrlAlt0Q`	Click this button to evaluate expressions.