In the Debug view, each thread in your program is displayed as a node in the tree. A typical debug target in the Debug view is described according to this diagram:

In the Debug view, launches used to start the debug session for the program are displayed at the top node level (pointer A. in the diagram). Beneath the launch, a node representing the debug engine is displayed (pointer B. in the diagram). Each thread in your program is then displayed (pointer C. in the diagram). When program execution stops, by default, the node for the stopping thread automatically expands to show its stack frame(s) (pointer D. in the diagram). If you manually expand other threads, these threads will automatically expand the next time the program suspends. Finally, a node representing the process and program being debugged is displayed (pointer E. in the diagram).
When program execution is suspended, the source for the selected stack frame opens in the editor, highlighting the source line that the program is about to execute. If there are many threads in the program, the stack for the thread that caused the stop may be scrolled off the end of the debug frame.
The sections that follow explain the actions that can be performed using the toolbar icons in the Debug View. As shown in the diagram below, the Debug view can also be used for setting the debugger daemon. For information about this, see the related topic about listening for debug engines.

You can perform these basic debug actions in the Debug view:
or press
F8.
) or
press Shift+F8 - or right-click the debug target (or one of its threads
or stacks) that you want to terminate, and choose one of the terminate
actions.
).
This action might be unavailable, depending on how the program you
are debugging was started.
)(Ctrl+F8).
If the process is selected when this action is used, all threads of
the process will stop. If your debug engine supports suspending and
resuming individual threads, and if a thread is selected, only that
thread will stop. This support is only available if you are using
Version 11.1 or later of the debug engine. The thread or threads,
in the application will suspend until you issue a Resume action.
When you issue a suspend action, the debug engine sends a SIGSTOP to
the program that you are debugging.Halting is useful when you have a runaway process that is running, but not hitting a breakpoint. You can regain control of the application by halting it. When you halt a program, it will typically stop in Disassembly view in the editor.
When a thread is suspended, the step controls can be used to step through the execution of the program line-by-line. While performing a step operation, if a breakpoint or event is encountered, execution suspends at the breakpoint or event, and the step operation ends. You can use step commands to step through your program a single instruction or location at a time.
The following step commands are available:
)(F6): When you issue a step
over, the program steps to the next source line.
)(F5): When you issue a step
into, your program will step to the next statement. If the current
line contains a call to another function, the debugger will stop in
that function.The behavior of this command is affected by the Use
Step Filters action (
)(Shift+F5). If the filter is off (push button not selected),
the debugger will stop in a called function even if it does not contain
debug information and disassembly must be displayed. If the filter
is on (push button selected) , the debugger will only stop in the
called function if source can be displayed. If source cannot be displayed,
it behaves as though you had issued a Step Over.
The DER_DBG_ STEP_DEBUG debug engine environment
variable affects the behavior of the Use Step Filters action.
)(F7): When you issue a step
return, your program runs to the point in the calling program immediately
after the call to the current function. You will normally stop at
the location following the calling instruction. If the calling program
has debug information, this may be in the middle of a source line.
): When you issue this action, the debugger issues a step
into action repeatedly. You can control the delay between each step
by selecting the Animated Step Into action
again.