Action    name: Debugger
 

Opens the debugger window.

In this window, you can view the register values for the selected thread. The debugger always selects the thread where the latest debugging event occurred.

For most registers, we have two different boxes:

       - the first box (on the left) indicates the current value of the register.
         Blue indicates that the value has changed since the last debugging event.
         Purple indicates that the value has been modified by the user.
         A popup menu is available on this control, offering different commands.

       - the second box (on the right) shows the current value of the register,
         interpreted like an address (if possible).

For a segment register, we only have one box indicating the current value.

For the flags register, we have one box indicating the current value, and small boxes indicating the status of the most important flags.

A popup menu is accessible everywhere in the window, which allows the user to show or hide different parts of the window: toolbar, thread list and available register classes.

See also Debugger submenu.

 Action    name: ProcessStart
 

This command starts the process in the debugger. If the process was suspended, it will continue its execution. See also

• Attach to process...

• Process options

• Pause process

• Terminate process

• Detach from process

• Debugger submenu

 Action    name: SetupProcess
 

This dialog box allows to specify different settings related to the process being debugged.

Application

        Host application to launch.
        When the debugging target (== 'input file') is an executable file, this field is equal to the 'input file'.
        If this field is wrong, IDA will not be able to launch the program.
        For remoting debugging, this field denotes a remote file.

Input file

        The input file used to create the database.
        For remoting debugging, this field denotes a remote file.

Directory

        Directory to start the application. If empty, then the current directory
        will be used.
        For remoting debugging, this field denotes a remote directory.

Parameters

        Optional parameters to pass to the debugged application (or the host application)
        when it starts. This field may be empty.
        The standard input/output/error channels can be redirected using
        the bash shell notations. for example: >output 2>&1

Hostname If entered, denotes the name of the remote host with the application to debug. In this case, a remote IDA server on this host must be launched. Click here to see the list of remote servers. Port

        The port number of the remote server

Password

        Optional password to protect your server from strangers connecting to
        it and running arbitrary commands. The same password switch must be
        specified on the remote server.

The hostname, port, and password are not available for debuggers connected locally to the computer. See also

• Start process

• Debugger submenu

• How to launch remote debugging

Here are the debugger commands:

• Debugger window

• Tracing submenu

• Thread list

• Module list

• Start process

• Attach to process...

• Process options

• Pause process

• Terminate process

• Detach from process

• Take memory snapshot

• Manual memory regions

• Step into

• Step over

• Run until return

• Run to cursor

• Set current ip

• Show application screen

• Breakpoints

• Source view

• Watch view (source level)

• Watches (assembler level)

• Tracing

• Debugger options

• Switch debugger...

See also

• Menu Bar

• How to launch remote debugging

• Debugger for macOS

• Debugger for Bochs

• Remote GDB debugger

• Remote iOS debugger

• WinDbg debugger

• Replayer debugger

• PIN Tracer

• Dalvik debugger

 Action    name: ThreadRunUntilReturn
 

This command executes assembler instructions and stops on the instruction immediately following the instruction that called the current function.

Internally, IDA executes each instruction in the current function until a 'return from function' instruction is reached.

See also

• Step into

• Step over

• Debugger submenu.

 Action    name: ThreadRunToCursor
 

This command executes instructions until the instruction under the cursor is reached.

Internally, IDA setups a temporary breakpoint on the instruction under the cursor. See also Debugger submenu.

 Action    name: ThreadStepOver
 

This command executes one assembler instruction at a time, stepping over procedures while executing them as a single unit.

Internally, in the case of a function call, IDA setups a temporary breakpoint on the instruction following this function call. See also

• Step into

• Run until return

• Debugger submenu.

 Action    name: ProcessDetach
 

This command detaches the debugger from the debugged process. Note: this command is only available on Windows XP or Windows 2003 Server !

See also

• Start process

• Pause process

• Terminate process

• Debugger submenu.

 Action    name: ShowUserScreen
 

This command displays the application screen.

It is useful for the text mode debugger.

When the debugged application runs in the same window as IDA itself, the application output is hidden by IDA windows. This command allows to see the application screen in this case.

To return to IDA display, press any key.

This command is available when the application is suspended or finished. See also Debugger submenu.

 Action    name: ProcessAttach
 

This command displays running processes corresponding to the disassembled file in the database and allows the user to choose a process to attach to.

See also

• Start process

• Process options

• Pause process

• Terminate process

• Detach from process

• Debugger submenu.

 Action    name: ThreadStepInto
 

This command executes one assembler instruction at a time, stepping into functions. See also

• Step over

• Run until return

• Debugger submenu.

 Action    name: ThreadSetCurrentIp
 

This command sets the instruction pointer of the current suspended thread to the current cursor location.

It is accessible only when the debugger is active and the process is suspended. See also Debugger submenu.

 Action    name: ProcessTerminate
 

This command terminates the debugged process. See also

• Start process

• Pause process

• Detach from process

• Debugger submenu.

 Action    name: ProcessPause
 

This command pauses a running process. Please note that it is not always possible to pause a process executing the system code. See also

• Start process

• Terminate process

• Debugger submenu.

Here are the commands to use the debugger watches (assembler level).

• Watch list

• Add watch

• Del watch

See also

• Debugger submenu

• Source level watchies

Watch list

Action    name: WatchList
 

Opens the assembler level watch list window.

In this window you can view memorized watches. A watch allows the user to continuously see the value of a defined item.

Add watch

Action    name: AddWatch
 

This command adds a watch at the current address. The watch is visible in the Watch list window.

Delete watch

Action    name: DelWatch
 

This command deletes an existing watch.

Here are the commands to use the tracing features of the debugger.

• Trace management

• Tracing window

• Clear trace

• Instruction tracing

• Function tracing

• Basic block tracing

• Add write trace

• Add read/write trace

• Add execution trace

• Stack trace

• Tracing options

See also Debugger submenu.

Trace management

Recorded traces can be managed from the Tracing window. Traces are saved in a directory specified in the tracing options dialog.

Saved binary trace files can be loaded, saved and replayed with the new replayer debugger module, diffed against other traces (to spot differences between executions) or displayed in a proximity view (displaying the execution call graph).

Tracing window

Action    name: TracingWindow
 

Opens the 'Tracing' window.

In this window, you can view some information related to all traced events. The tracing events are the information saved during the execution of a program. Different type of trace events are available: instruction tracing events , function tracing events and write, read/write or execution tracing events.

During the execution, the list of traced events is disabled, as it couldn't be continuously synchronized with the execution without rendering the whole tracing very slow.

If a '=' character is displayed in the 'Thread' and 'Address' columns, it indicates that the trace event occurred in the same thread and at the same address as the previous trace event.

Select trace

Load a binary trace file in the 'Tracing' window.

This command displays all the saved trace files that correspond to the MD5 of the current IDB and allows the user to load one of them. The traces can be replayed with the replayer debugger, inspected manually in the disassembly view or displayed as a callgraph in a proximity view.

Other options

Show a dialog with additional options for managing trace files.

This command displays a window with all the available commands to manage trace files.

Edit trace description

Show the description of a binary trace file.

This command displays a window with the description of a selected binary trace file and allows to edit it.

Diff to binary trace

Diff the currently loaded trace against a recorded trace.

This command displays a window to select a trace file to diff against the currently loaded trace, displayed in the 'Tracing' window.

If highlight options are enabled in Tracing Options, instructions from the currently loaded trace will be displayed with the background "main color" and instructions from the diff trace file will be displayed with the "diff color". Common instructions will be highlighted with an average of the two.

Remove binary trace

Delete a binary trace file from disk.

This command displays a window to select a recorded trace file to delete from disk.

Import binary trace

Import a binary trace file from a different IDB.

This command allows to import binary trace files recorded for an IDB with a different MD5. For example, it can be used to load recorded traces from a malware sample which is practically the same, but differs in a few bytes.

Export binary trace

Export to a binary trace file all events displayed in the 'Tracing' window.

This command exports to a binary trace file the current trace being displayed in the Tracing window. The trace can be loaded later, removed or diffed against other trace files.

Export trace to text file

Export to a text file all events displayed in the 'Tracing' window

This command exports the current trace being displayed in the Tracing window to a text file.

Show trace callgraph

Show the callgraph of the loaded trace in a proximity view.

This command displays the callgraph of the currently loaded trace in a proximity view.

Clear trace

Action    name: ClearTrace
 

This command removes all trace events from the Tracing window. It also removes any loaded trace file used for diffing against the currently loaded trace.

Instruction tracing

Action    name: ToggleTraceInstructions
 

This command starts instruction tracing. You can then use all the debugger commands as usual: the debugger will save all the modified register values for each instruction.

When you click on an instruction trace event in the 'Tracing' window, IDA displays the corresponding register values preceding the execution of this instruction. In the 'Result' column of the Tracing window, you can also see which registers were modified by this instruction. By using this information, you can for example quickly determine which instruction modified a specific register, or you can even backtrace the execution flow. Note that the IP register is never printed in the 'Result' column, although it is usually modified by almost any instruction (except perhaps some prefixed instructions like REP MOVSB, ...).

Internally, the debugger runs the current thread step by step to properly obtain all the required register values. This explains why instruction tracing is slower than a normal execution.

Function tracing

Action    name: ToggleTraceFunctions
 

This command starts function tracing. You can then use all debugger commands as usual: the debugger will save all addresses where a call to a function or a return from a function occurred.

Internally, the debugger runs the current thread step by step to properly detect all function calls and returns. This explains why functions tracing is slower than a normal execution.

Basic block tracing

Action    name: ToggleTraceBasicBlocks
 

This command starts basic block tracing. You can then use all debugger commands as usual: the debugger will save all addresses where a temporary basic block breakpoint was reached.

Internally, the debugger runs the current thread normally, setting temporary breakpoints in the last instruction of every basic block of every function referenced from the current function and also at any call instruction in the middle of the traced basic blocks.

Basic block tracing is slower than normal execution but faster than instruction or function tracing.

Add write trace

 Action    name: WriteTraceAdd
 

This command adds a write trace to the current address.

Each time the given address will be accessed in write mode, the debugger will add a trace event to the Tracing window.

In fact, write traces are nothing more than breakpoints with special properties: they don't stop and they simply add a trace event when the breakpoints are reached.

Internally, the debugger will add a hardware breakpoint on the given address, so all the restrictions for hardware breakpoints are also valid for write traces.

Add read/write trace

Action    name: ReadWriteTraceAdd
 

This command adds a read/write trace to the current address.

Each time the given address will be accessed in read or write mode, the debugger will add a trace event to the Tracing window.

In fact, read/write traces are nothing more than breakpoints with special properties: they don't stop and they simply add a trace event when the breakpoints are reached.

Internally, the debugger will add a hardware breakpoint on the given address, so all the restrictions for hardware breakpoints are also valid for read/write traces.

Add execution trace

This command adds an execution trace to the current address.

Each time the instruction at the given address will be run, the debugger will add a trace event to the Tracing window.

In fact, execution traces are nothing more than breakpoints with special properties: they don't stop and they simply add a trace event when the breakpoints are reached.

Internally, the debugger will add a breakpoint instruction at the given address.

Stack trace

Action    name: StackTrace
 

Opens the stack trace window.

This window displays the function calls that brought the current instruction.

The top of the Stack Trace window lists the last function called by the program. Below this is the listing for the previously called functions. Each line indicates the name of the function which called the function represented by the previous line.

Double clicking on a line jumps to the exact address of the instruction realizing this call.

Currently, IDA uses the EBP frame pointer values to gather the stack trace information. It will fail for functions using other methods for the frame.

Tracing options

This dialog box allows you to specify different settings related to the tracing features.

Trace buffer size

  This setting indicates how many tracing events can fit in the trace buffer.
  If the debugger must insert a new event and the buffer is full,
  the oldest tracing event will be removed.
  However, if you specify a size of 0, the buffer size isn't limited.
  Notice that, for example, in the case of an instructions trace,
  all executed instructions could be logged, which would quickly fill
  up the memory!

Trace file

  If a filename is specified, all future traced events will be appended to it.

Trace directory

  The directory were trace files for the current database will be saved. If not
  specified, the IDB directory will be used.

Stop condition This IDC expression will be evaluated before the execution of each instruction. If the expression returns true, the debugger will suspend the execution. Please note that you can use register names in the condition. Tracing

  - Trace over debugger segments

      If selected, the debugger will not go step by step in debugger segments
      (segments not available in the database).

  - Trace over library functions

      If selected, the debugger will not go step by step in library functions.

Enabling these options will speed up the execution, as many instructions (from debugger segments and/or library functions) will not be traced. Disabling these options can quickly fill the Tracing window, as all instructions in DLLs and system functions will be executed step by step. Notice that both options influence the way instruction and function tracings will work. Internally, the debugger proceeds like this:

• memorize the return address associated with the last executed call instruction in database segments (the previously saved one is overwritten).

• setup a temporary breakpoint on this address once the IP is in a debugger segment or library function, disable step by step, and run the thread.

• reenable step by step once this temporary breakpoint is reached.

  Copy

  - Do not log already logged IP
  
      If selected, already executed instructions will not be logged if
      they are executed again.
  
  - Skip loops
  
      If selected, tracing will be temporarily disabled for some loops
      constructs.

Highlight

  - Highlight instructions in IDA views

    If selected, recorded instructions will be displayed in IDA views (disassembly
    views) with a different background color.

  - Main color

    The main background color for traced instructions.

  - Diff color

    The background color for the instructions recorded and being diffed against the
    currently loaded trace.

Instruction tracing

  - Log if same IP

    If selected, the debugger will also log all register modifications occurring
    during the execution of prefixed instructions like REP MOVSB, ...

Function tracing

  - Log return instructions

      If selected, the debugger will also log function returns.
      If disabled, only function calls are logged.

Basic block tracing

  - Log basic block instructions

      If selected, all instructions from the current basic block will be logged
      and displayed in the 'Tracing' window, instead of only the last instruction of
      the basic block.

In this window the user can view values of selected variables.

Global variables (data item names) as well as variables that are local to the current function can be added by pressing Ins.

Expressions can be added to the view as well, they will be considered as IDC expressions.

Expressions may have a type cast at the beginning. For example

(int)0x12345678

means that the contents of the memory at the address 0x12345678 should be displayed as an integer. Note: to display strings use "char[]" as the typo.

See also Source code view

 Action    name: TakeSnapshot
 

This command copies the contents of the process memory to the database. It is available during a debugging session.

The memory contents will be copied to the database. The user may specify that only the segments with the 'loader' attribute will be saved in the database.

The segments with the loader attribute are created by the input file loader and usually contain information from the input file. However, in some cases (like attaching to an existing process), there will not be any loader segments because the input file was not loaded by IDA.

To be able to make a partial snapshot in this case and other similar cases, the user can set or clear the 'loader' attribute of the desired segments using the edit segment command.

After applying this command, the user can terminate the debugging process and continue to analyze the program in the database.

Please note that it is possible to save the database without taking a memory snapshot. Such a database might be used to keep global information about the program like the breakpoint information, notes, etc. However, we recommend to take a memory snapshot of at least the 'loader' segments because it will allow to save also information about the program functions, names, comments, etc.

See also Debugger submenu.

 Action    name: ManualRegions
 

This command open a window with manual memory regions. In this window the user can manipulate memory region definitions: add or delete them.

Some debugger backends (e.g. the gdb backend) do not provide memory layout information. IDA needs this information in order to show the memory contents. When this information is not available, the user must specify it.

The defined memory regions will be accessible when the debugger is active. The user will be able to see the memory contents in the disassembly windows.

If no memory information is provided by the user nor by the debugger backend, IDA will assume that entire memory space is accessible. However, it is better to specify memory layout more precisely.

See also Debugger submenu.

 Action    name: Modules
 

Opens the modules window.

This window lists all the modules loaded by the debugged process. Double click on a module to see the list of its exported names.

The right click menu allows for loading debug information for the current module. For that, select the "Load debug symbols" command from the popup menu. If IDA manages to find and load the corresponding debug information file, it will import all symbols from it into the database. Currently, only PDB files are supported. The operation result is displayed in the message window. See also Debugger submenu. Load PDB files command.

 Action    name: StackTrace
 

Opens the stack trace window.

This window displays the function calls that brought the current instruction.

The top of the Stack Trace window lists the last function called by the program. Below this is the listing for the previously called functions. Each line indicates the name of the function which called the function represented by the previous line.

Double clicking on a line jumps to the exact address of the instruction realizing this call.

Currently, IDA uses the EBP frame pointer values to gather the stack trace information. It will fail for functions using other methods for the frame.

 Action    name: SetupDebugger
 

This dialog box allows to specify different settings related to the debugger.

Events

  - Suspend on debugging start

      If selected, the debugger will suspend directly once the debugging
      starts.

  - Evaluate event condition on exit

      If selected, the debugger will evaluate the event condition immediately
      before closing the debugging session (once we receive PROCESS_EXITED or
      PROCESS_DETACHED event)

  - Suspend on process entry point

      If selected, the debugger will insert a temporary breakpoint
      at the main entry point of the debugged application.

  - Suspend on thread start/exit

      If selected, the debugger will suspend if a new thread starts
      or if an existing thread terminates.

  - Suspend on library load/unload

      If selected, the debugger will suspend if a new library is
      loaded or if a previously loaded library is unloaded.

  - Suspend on debugging message

      If selected, the debugger will suspend if the debugged application
      generates a message destined to the debugger.

Event condition

      When one or more debug events (see above) are checked then this
      option is used to specify a condition. In the following example,
      the debugger will suspend the process whenever a module with the
      name test.dll is loaded:

 get_event_id() == LIB_LOADED && strstr(get_event_module_name(), "test.dll") != -1

Log

  - Segment modifications

      If selected, the debugger will print information regarding
      segment modifications (creation, deletion, or resizing of
      segments) since the last event. Note that the debugger
      doesn't continuously track segment modifications, but detects
      those only if a debugging event occurs.

  - Thread start/exit

      If selected, the debugger will print a message if a new thread
      starts or if an existing thread terminates.

  - Library load/unload

      if Selected, the debugger will print a message if a new library is
      loaded or if a previously loaded library is unloaded.

  - Breakpoint

      If selected, the debugger will print a message if the debugged process
      reaches a breakpoint.

  - Debugging message

      If selected, the debugger will print debugging messages from
      the application.

Options

  - Reconstruct the stack

If selected, the debugger will try to reconstruct the chain of stack frames, based on information available on the stack and in the function stack variables.

  - Show debugger breakpoint instructions

      If selected, the debugger will show breakpoint instructions inserted
      by the debugger itself. This function is mainly useful if the user
      wants to see the real content of the memory.

  - Use hardware temporary breakpoints

      If selected, IDA will try to use hardware breakpoints for the temporary
      breakpoints used to implement the "step over" and "run to" functionality.
      This feature is useful when debugging read-only or self-modifying code,
      since it does not change the contents of the memory.
      IDA will fall back to software breakpoints if the attempt to set a
      hardware breakpoint fails.

  - Autoload PDB files

      If selected, IDA will invoke the PDB plugin to try to load PDB symbols
      for every new module loaded into process.

  - Set as just-in-time debugger

      If changed from off to on, IDA will try to register itself as a
      just-in-time debugger (invoked by the system in case of application
      crashes) on dialog close.

Edit exceptions This button allows the user to setup how the debugger will react to specific exceptions. Reload exceptions

      This button reloads the exception table from the exceptions.cfg
      file.

See also Debugger submenu.

This window shows the contents of a source code file. IDA automatically opens source views provided that proper mapping of the source code paths is specified in "Options, Source paths".

This window may also display a decompilation result because it is considered as a source code. This can be useful if the source files are not available.

Watch view (source level)

In this window the user can view values of selected variables.

Global variables (data item names) as well as variables that are local to the current function can be added by pressing Ins.

Expressions can be added to the view as well, they will be considered as IDC expressions.

Expressions may have a type cast at the beginning. For example

(int)0x12345678

means that the contents of the memory at the address 0x12345678 should be displayed as an integer. Note: to display strings use "char[]" as the typo.

Locals view (source level)

This window displays the values of the variables that are local to the current functions (register and stack based).

Here are the commands to use the debugger breakpoints.

• Breakpoints list

• Add breakpoint

• Edit breakpoint

• Delete breakpoint

Related topics:

• Page breakpoints

• Find breakpoint

• Breakpoint conditions

• Low level breakpoint conditions

See also Debugger submenu.

Breakpoints list

Action    name: Breakpoints
 

Opens the breakpoints window.

In this window, you can view information related to existing breakpoints. Breakpoints are saved in the database, and restored as soon as possible (once the memory becomes writeable).

The 'Pass count' column indicates how many times the program needs to hit the breakpoint before being suspended (0 means "always suspend").

Add breakpoint

Action    name: BreakpointAdd
 

This command adds a breakpoint at the current address. If an instruction exists at this address, an instruction breakpoint is created. Otherwise, IDA offers to create a hardware breakpoint and allows the user to edit breakpoint settings. Hardware breakpoints can be either real hardware breakpoints or page breakpoints.

Edit breakpoint

Action    name: BreakpointEdit
 

This command opens a dialog box to edit an existing breakpoint.

Location

  The breakpoint location: either an absolute address, a symbol name,
  a module+offset combination, or a source file name and a line number.
  The exact location syntax depends on the breakpoint kind: absolute, module
  relative, symbolic, or source code.

Condition This IDC expression will be evaluated each time the breakpoint is reached. If the expression returns true (non-zero), the debugger will execute the selected actions. Please note that you can use the register names in the IDC scripts when the debugger is active. Tests like this are allowed, for example: EAX == EBX+5 or get_wide_dword(ESP+0x10) == 34 You can also use the "..." button to enter a multiline condition, or specify another scripting language to use. See here for more info.

Settings

  Enabled:
        If the breakpoint is enabled or disabled. Disabled breakpoints
        are not written to the debugged process.

  Hardware:
        If enabled, IDA will use a hardware breakpoint. The breakpoint
        mode and size must be specified for them (see below).

  Module relative:
        The breakpoint location is stored as a combination of a module
        name and an offset. This kind of breakpoint is useful for
        DLLs that are loaded to various addresses because their addresses
        cannot be calculated in advance. Example: kernel32+0x1234

  Symbolic:
        The breakpoint location is stored as a combination of a symbol
        name and a possible offset. This kind of breakpoint is useful for
        symbols that can be imported from different DLLs because their addresses
        cannot be calculated in advance. Example: myfunc+44

  Source code:
        The breakpoint location is stored as a combination of a source file
        name and a line number. Can be used only if the source code of the
        debugged application is available. Example: myfile.cpp:55

Low level condition: Evaluate the condition on the remote computer. Such conditions are faster, especially during remote debugging, because there is no network traffic between IDA and the remote computer on each breakpoint hit. More details

Actions

  Break:
        Suspend the debugged application

  Trace:
        Add a new entry to the trace log

Refresh debugger memory: By default IDA does not refresh the memory config before evaluating a breakpoint condition. This option enables the refresh. To refresh it manually, call refresh_debugger_memory

  Enable tracing:
        Enable tracing when the breakpoint hits. This is different from trace
        breakpoints (where only a new entry is added to the trace log).

  Disable tracing:
        Disable tracing when the breakpoint fires.

Tracing type: Instruction, Function and Basic block level tracing types can be selected for breakpoints where enable/disable tracing have been selected. Hardware breakpoint size Number of bytes to watch: 1, 2 or 4 bytes for normal hardware breakpoints. Any size for page breakpoints. Hardware breakpoint mode

        The access type the breakpoint will react: read/write, write, execute.

In the case of Intel hardware breakpoints, some limitations are enforced (in contrast with page breakpoints). It is impossible to create more than 4 hardware breakpoints. The address of the breakpoint must be aligned appropriately:

  - 2-byte breakpoints must be word-aligned.
  - 4-byte breakpoints must be dword-aligned.

Please note that hardware breakpoints occur AFTER the instruction execution while software breakpoints occur BEFORE the instruction.

Usually, it is easier to use software breakpoints, except if:

  - we want to be sure the memory is not modified by the debugger
  (instruction breakpoints modify the debugged process memory).

  - we want to detect accesses to data bytes.

  - the specified address is write protected (really rare!).

See also

• Index of IDC functions

Delete breakpoint

Action    name: BreakpointDel
 

This command deletes an existing breakpoint at the current address.

Page breakpoints

Page breakpoints are memory access breakpoints that can be set to detect when the application reads, writes, or executes code/data in a specific memory range. Page breakpoints are very similar to hardware breakpoints but there is no limitation on the number of page breakpoints that can be set or their size, in contrast with normal hardware breakpoints.

Memory access breakpoints are implemented by removing page permissions according to the specified type of the page breakpoint to be added (for example, for a write page breakpoint, the write permission will be removed from the page). When the access violation exception occurs because the application tries to access the specific memory region, IDA reports a breakpoint hit.

As page breakpoints can be set for a small part of a memory page but the permissions of the whole page must be changed, page breakpoints can slow down the debugger because many access violation exceptions may be generated. If the application accesses memory outside of the desired range but on the same page, the generated exception must be silently handled and the application resumed. Specifically, page breakpoints in the code segment can slow down the debugger very much.

Memory access breakpoints are supported since IDA version 6.3 for the following debuggers:

Win32

  Page breakpoints are supported for both local and remote debugging
  of 32 and 64bit applications.

WinDbg

  Page breakpoints are supported only for local debugging of 32-bit applications.

Bochs

  Page breakpoints are supported for both of 32 and 64bit applications.
  Page breakpoints in the bochs debugger are just like normal hardware
  breakpoints but with no limit on the number of breakpoints or their size.
  Please note that hardware breakpoints in the bochs debugger occur AFTER the
  instruction is executed while regular page breakpoints occur BEFORE the
  instruction is actually executed.

Find breakpoint

Action    name: BreakpointFind
 

Open the breakpoints window if needed, then find current breakpoint in it.

Breakpoint conditions

You can use the "Condition" field of the breakpoint properties to enter an expression which is evaluated when the breakpoint is hit. It can be either an actual condition or just any valid code in IDC or another supported scripting language syntax. By using the "..." button, you can open a multi-line editor for the condition and switch the scripting language used for evaluating it.

Expressions

  If you enter an expression, the result will be used to determine whether
  the selected actions are executed. Some examples of IDC expressions:

  Check if EAX is equal to 5:

    EAX==5

  Check if the first argument to the function is 1:

    get_wide_dword(ESP)==1

  Interpret the second argument to the function as a pointer to Unicode string, print it,
  and return 0 (so that the execution continues immediately):

    msg("Filename: %s\n", get_strlit_contents(get_wide_dword(ESP+4), -1, STRTYPE_UNICODE)), 0

  Set EAX to 0 and continue:

    EAX=0,0

Statements

  You can enter several statements in the multi-line editor. If the last one is a 'return' statement,
  it is used as the result of the condition. Otherwise the condition is assumed to return 0.

See also

• Index of IDC functions

Low level breakpoint conditions

Low level breakpoint conditions can be used to speed up the debugger. They are evaluated like this:

  - in case of remote debugging, the condition is evaluated on the remote
    computer. The following actions are bypassed:
      - sending of the breakpoint event to the local computer
      - switching from debthread to the main thread
      - updating internal IDA structures and caches
      - updating the screen

  - in case of local debugging, the condition is evaluated at low level.
    The following actions are bypassed:
      - switching from debthread to the main thread
      - updating internal IDA structures and caches
      - updating the screen

In both cases, there is a significant speed up. This improvement imposes some limitations on the breakpoint condition:

• only IDC expressions can be used for low level conditions

• only functions marked as 'thread-safe' may be called

• only entire registers can be accessed (e.g. EAX is ok but AL is not) Essentially this means that the only available functions are:

  Copy

  - read/write process registers
  - read/write process memory
  - file i/o
  - auxiliary string and object functions
  - msg() function (for debugging the breakpoint conditions)

Low level breakpoint conditions are available only for Win32, Linux, Mac, and Android debuggers.

 Action    name: SwitchDebugger
 

This command allows the user to select a debugger if there are several debuggers available for the current database. For example, Window32 program can be debugged with a remote or a local debugger.

 Action    name: Threads
 

Opens the threads window.

In this window, you can view all the threads of the debugged process. Double clicking on a thread jumps to its current instruction (available only if the process has been suspended). Double clicking also changes the current thread for the hlpHelpDebugger[CPU] window.

The right click brings a popup menu, where you can suspend or resume threads. The following thread states are possible:

  - Running: the thread is running
  - Ready: the thread is ready to run but the application has been suspended
  - Suspended: the thread has been suspended by the user

See also Debugger submenu.

This dialog box allows to setup how the debugger will react to specific exceptions. For each exception, two settings can be specified, simply by selecting the desired exception, and clicking the 'Edit' button in the popup menu.

Suspend program

        Specify whether the debugger will suspend when the exception occurs.
        If 'Passed to' == application and the application handles
        the exception successfully, the execution will not be suspended
        regardless of the 'Suspend' value.

Passed to

        Specify whether the exception will be passed to the application itself
        or handled by the debugger. If the debugged program contains exception
        handling code, it is better to select 'Application'.

Report

  Warn

        Show a warning message with the exception information.

  Log

        Instead of displaying a warning message, log to the output window the exception
        information.

  Silent

        Do not show a warning message nor log to the output window.

For new exceptions being added by the "Insert" command, you have to specify the exception name and code. These values must be unique, the name cannot be empty, and the code cannot be zero. See also Debugger submenu.

 Action    name: RefreshMemcfg
 

This command refreshes the segments and memory contents in IDA. It is available only during a debugging session. NOTE: this command is currently hidden from the user interface because IDA does synchronize with the process memory automatically.

Please note that IDA itself tries to keep the program segments in sync with the debugged process. However, in order to accelerate the debugger, the synchronization is done only at major events, for example when dynamic library gets loaded or unloaded or a thread is created or deleted. If the memory configuration is changed because of a simple system call (think of VirtualAlloc), IDA might miss it. Use the "refresh memory" command in these cases.

Note2: when IDA detects a discrepancy in the segments, it will automatically synchronize with the process.

See also Debugger submenu.