All pages
Powered by GitBook
3 of 30

Debugger

Here are the debugger commands:

See also

Debugger window

 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.

Process Control

Start process

 Action    name: ProcessStart

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

Process options

 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

Pause process

 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

Terminate process

 Action    name: ProcessTerminate

This command terminates the debugged process. See also

Step into

 Action    name: ThreadStepInto

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

Step over

 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

Run to cursor

 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.

Run until return

 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

Attach to process

 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

Detach from process

 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

Set current ip

 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.

Show application screen

 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.

Breakpoints

Here are the commands to use the debugger breakpoints.

Related topics:

See also Debugger submenu.

Breakpoints list

Action    name: Breakpoints

Opens the breakpoints window.

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

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

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:

    - 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.

Watches

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

See also

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.

Tracing

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

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.

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

Action    name: SetupTracing

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.

    - 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.

Source code view

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).

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.

See also Source code view

Process Memory

Take memory snapshot

 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.

Manual memory regions

 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.

Refresh memory

 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.

Thread list

 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.

Module list

 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.

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. See also Tracing submenu.

Exceptions

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.

Debugger options

 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

  • 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.

  • Optimize single-stepping

    Prevent debugger memory refreshes when single-stepping. See debugger_t::DBG_FLAG_FAST_STEP

  • Disable ASLR

    Disable Address space layout randomization (ASLR). Optional, valid if debugger declares this option is supported, see debugger_t::DBG_FLAG_DISABLE_ASLR

  • 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. Optional, valid only for Windows OS.

Buttons

  • 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.

  • Set specific options

    Set debugger options (parameters that are specific to the debugger module). Optional, valid if debugger has the additional specific options. See debugger_t::ev_set_dbg_options

See also Debugger submenu.

Switch debugger

 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.