User and Reference Guide

  • 2021.1
  • 12/04/2020
  • Public Content

Breakpoint Restrictions

The debugger can use both hardware and software breakpoints, each of these has strengths and weaknesses:
  • Hardware Breakpoints
    are implemented using the DRx architectural breakpoint registers described in the Intel® 64 and IA-32 Architectures Software Developer Manuals. They have the advantage of being usable directly at reset, being non-volatile, and being usable with flash or other read-only memory. The downside is that they are a finite resource.
  • Software Breakpoints
    require modifying system memory as they are implemented by replacing the opcode at the desired location with a special instruction. This makes them an unlimited resource, but the memory dependency mean you cannot install them prior to a module being loaded in memory, and if the target software overwrites that memory then they will become invalid.
In general, any debug feature that must be enabled by the debugger does not persist after a reset and may be impacted after other architectural mode transitions such as SMM entry/exit or VM entry/exit. Specific examples include:
  • CPU Reset clears all debug features, except for reset break. This means, for example, that user-specified breakpoints will be invalid until the target halts once after reset. Note that this halt can be due to either a reset-break, or due to a user-initiated halt. In either case, the debugger restores the necessary debug features.
  • SMM Entry/exit disables/re-enables breakpoints. This means you cannot specify a breakpoint in SMRAM while halted outside of SMRAM. If you wish the break within SMRAM, you must first halt at the SMM entry-break and manually apply the breakpoint. Alternatively, you can patch the BIOS to re-enable breakpoints when entering SMM, but this requires the ability to modify the BIOS, which cannot be used in production code.

Product and Performance Information


Performance varies by use, configuration and other factors. Learn more at