The Linux debugger has the following particularities and limitations:

- The debugger server can handle only one IDA client at a time

- By default, the 64-bits debugger will try to load "libunwind-x86_64.so.8" and "libunwind-ptrace.so.0" in order to help with stack recovery.

- ARMLinux: hardware breakpoints are not supported

- ARMLinux: The THUMB mode is not supported

- Configure the debugger specific options (for 64 bits only) in Debugger Options, Set specific options.

  - Path to libunwind:
    - "libunwind-x64_64.so.8" (the default): the debugger will try to load
      libunwind "libunwind-x86_64.so.8" + "libunwind-ptrace.so.0" pair
      using the regular 'ld' search path.
    - "libunwind-x64_64.so" (note the lack of ".8" at the end): like the
      default, except the debugger will look for "libunwind-x86_64.so"
      and "libunwind-ptrace.so" (this is particularly useful for working
      with libunwind "dev" packages)
    - absolute path to libunwind-x64_64.so.8 or libunwind-x64_64.so: Linux debugger
      will try to load libunwind only from the provided path.
    - absolute path to "libunwind-x64_64.so[.8]": the debugger will try
      to load the two libraries from there (the absolute path to
      "libunwind-ptrace.so[.0]" will be derived from that of
      "libunwind-x64_64.so[.8]")
    - left blank: don't use libunwind to collect stack traces.

  By default this is set to libunwind-x86_64.so meaning the default
  path will be used to load libunwind-x86_64.so(.8) and libunwind-ptrace.so(.0). If an absolute
  path is provided, both libraries will be loaded from this path. If left emtpy, the call
  stack will be analyzed by Ida and not libunwind.

See also

• Start process

• Debugger submenu

• How to launch remote debugging

The WinDbg debugger plugin uses Microsoft's Debugging Engine COM interfaces from the Debugging Tools package.

To use the WinDbg debugger plugin, the following steps must be carried out:

• Please download the latest debugging tools from http://www.microsoft.com/whdc/devtools/debugging/default.mspx

  Copy

  - Configure the debugger specific options in
        Debugger Options, Set specific options.
  
  Windbg debugger plugin has the following configuration options:
  
  - The Debugging Tools folder: This should be configured to point to the same
  folder where Microsoft Debugging Tools are installed. The plugin will try to
  guess where the tools are, but if it fails, a manual intervention will be required.
  If this option is not set, then the plugin will try to use dbgeng.dll from
  MS Windows system folder, while normal debug operations will work, extensions will not.
  
  - Kernel mode debugging: Check this option when debugging the kernel.
  
  - User-mode debugging: Check this option to debug MS Windows applications.
  
  - Non-Invasive debugging: Check this option to enable attaching to user-mode
  processes non-invasively
  
  - Kernel mode debugging with reconnect and initial break: Select this option
  when debugging a kernel and when the connection string contains 'reconnect'. This option
  will assure that the debugger breaks as soon as possible after a reconnect.
  
  - Output flags: These flags tell the debugging engine which kind of output
  messages to display and which to omit

The WinDbg debugger plugins has the following features:

  - Send commands to the debugger engine when the debugging session starts.
  Use the "." key to switch to the command line and start typing commands.
  Please note that while it is possible to send any command to the engine, only the
  commands that change the execution status should not be used:
  go ("g"), step ("t"), step into ("p"), etc...

- Symbol information: If the symbol path is configured properly, then the debugger engine will fetch debug symbols from the appropriate location (symbol server, cache, etc...) For example, setting the following environment variable before starting IDA: _NT_SYMBOL_PATH=srv*c:\pdb_cache*http://msdl.microsoft.com/download/symbols

  - Multi-processor support: Debugger Engine will create a virtual thread for
  each processor that it finds. Similarly, IDA will present these processors as threads.

  - Remote debugging support: It is possible to use the process server "dbgsrv.exe"
  to enable remote debugging. For example:

    1. Run "dbgsrv -t tcp:port=PORT_NUM,server=HOST_NAME"

    2. Verify that the server is correctly running by listing all process
    servers on the given HOST_NAME:

      cdb -QR \\HOST_NAME

    3. Finally, run IDA and specify the following connection string:
      tcp:port=PORT_NUM,server=HOST_NAME

  - Use WinDbg extensions: it is possible to use the extension commands that
  usually work with WinDbg. Make sure that the "Debugging Tools folder" setting
  is properly set so that this feature works.

  - Kernel Debugging: It is possible to debug the kernel the same way as it is
  done with WinDbg. Simply setup the target kernel and configure the WinDbg
  plugin by checking the "kernel mode debugging" option and by typing a correct
  connection string. If the user detaches from a kernel session (using Debugger/Detach Process),
  the debugged kernel will resume. However, if the user selects Debugger/Terminate Process,
  the kernel will be suspended (it will wait until another client attaches to it).

- Dump files support: It is possible to load into IDA dump files generated either manually (using the ".dump" command) or crash dumps generated from a crashed process or kernel. Please refer check the windmp file loader reference.

  After the dump has been loaded, it is possible to run the debugger and investigate about
  the crash by typing Windbg commands into the command line window.
  For example, one could check the call-stack or use any other Windbg extension.

  - External breakpoints: it is possible to use the command line to create breakpoints
  that are not supported by IDA but supported by the debugging engine: in that
  case, all unknown (external) breakpoints will suspend IDA when they trigger.

The WinDbg debugger can be used to debug local programs as well as remote programs. This is controlled via the connection string in the "Process Option" dialog. If it is left blank,it means that a local debugging is in effect. Otherwise, a debug engine compatible connection string is expected. IDA will display an error message if the connection string could not be accepted: in that case, try using the same connection string with "cdb", or "windbg" and see if it works.

The WinDbg debugger module adds a new menu item: Debugger, WinDbg command. It can be used to send arbitrary commands to the debugger engine. The command output is displayed in the message window.

Additional IDC functions provided by the WinDbg debugger

On macOS, the suggested approach is to use with one of the mac_server* binaries that are shipped with IDA - even when debugging apps on your local machine.

Using a standalone debug server application makes it easier to get around the codesigning and debugging restrictions that are built into macOS. Note that this is also the approach used by lldb. Internally lldb uses a dedicated debugserver that implements the core debugger engine - so IDA does the same.

It is possible to use the Local Mac OS X Debugger in ida.app, but you must run IDA as root.

For a deeper dive into macOS debugging, see our tutorial:

See also