This tool window becomes available when you start debugging.
It displays the output generated by the debugging session for your application. If you are debugging multiple applications, the output for each application is displayed in a separate tab named after the corresponding run/debug configuration.
For each application, there are the following nested tabs:
Console: displays system information and error messages, and the console input and output of your application.
Debugger: this tab is divided into the following areas:
Elements: appears if you are using Chrome browser for debugging.
Debug Output: shows messages sent by your application to the debug output, for example with the
Parallel Stacks: shows threads and their stack frames on the diagram.
Each area has a context menu that allows you to configure its behavior and navigate between tabs.
Tooltip and Shortcut
Click this button to stop the current application and run it again.
When an application is paused, click this button to resume program execution.
Click this button to pause program execution.
Click this button to terminate the current process.
Click this button to open the Breakpoints dialog where you can configure breakpoints behavior.
Use this button to toggle breakpoints status.
You can temporarily mute all the breakpoints in a project to execute the program without stopping at breakpoints.
Click this button to abandon changes to the current layout and return to the default state.
Show Options Menu
Click this button to open the menu with the following options available:
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.
Tooltip and Shortcut
Show Execution Point
Click this button to highlight the current execution point in the editor and show the corresponding stack frame in the Frames pane.
Jump to Statement
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 to repeat some routine). You can do this with the Jump to statement command Ctrl+Shift+F10 that is also available in the Run menu and in the Debug window.
You can also jump to statement by dragging the execution pointer with your mouse and dropping it to the target line:
Remember the following when you jump to another statement:
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
Click this button to have the debugger step over the method even if this method has breakpoints inside.
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.
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.
Smart Step Into
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
If you want to choose which of the calls should be stepped into, for example,
When you choose the function to step into, the debugger will set the execution pointer at the first statement of the selected function.
Click this button to have the debugger step out of the current method, to the line executed right after it.
Run to Statement
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.
If line numbers are displayed in the editor, and Click line number to perform run to cursor is enabled on the page of JetBrains Rider settings Ctrl+Alt+S, you can run to this line by clicking its line number.
Force Run to Statement
Click this button to evaluate expressions.
Moving tabs and areas
If you are unhappy with the default layout of the Debug tool window, you can always move the tabs and areas. To do that, just drag a tab or an area to the desired location. The possible target gets highlighted.
Drop the tab or area in the highlighted location.
To restore the default layout of tabs and area, click in the Debug toolbar.