Hardware and Software Breakpoints

By default, the source debugger attempts to use software breakpoints as they are more scalable in many-thread systems and they also are an unlimited resource.

Software breakpoints require inserting a special opcode at the desired break location in memory; they can only be used in a writable memory region. They also cannot be used for non-execution breaks (such as breaking on a memory access).

Hardware breakpoints are dependent on the debug registers (DRx) and hence limited to 4 on x86 architecture.

In some cases, the source debugger may elect to promote a software break to a hardware break; for example, when setting a software break in read-only memory (such as flash) and the operation fails, the source debugger detects this failure and automatically sets a hardware break instead. A warning message is displayed.

You can override the default usage of software breaks by selecting Options > Options... and switch on Use Only Hardware Breakpoints.


Hardware breakpoints are a limited resource and using all available resources may degrade high-level language features such as step out, go here and others. A warning message will be displayed in the Console window in these cases.

For more complete information about compiler optimizations, see our Optimization Notice.