Dbgeng Breaks On Every Exception Despite Sx* Commands

by ADMIN 54 views

Introduction

The dbgeng debugger is a powerful tool for debugging applications, but it can sometimes behave unexpectedly. In this article, we will explore a specific issue where the dbgeng debugger breaks on every exception despite using sx* commands. We will also provide a step-by-step guide on how to reproduce this behavior and discuss possible solutions.

Describe the Bug

The dbgeng debugger breaks on every exception despite using sx* commands. The sx commands seem to have some effect since sxi will still hide the message, but the debugger still breaks. This behavior is not present when using windbg.

To Reproduce

To reproduce this behavior, follow these steps:

Step 1: Compile Exception Test

Compile the following C++ code:

#include <iostream>
#include <exception>

int main(void)
{
    for (int i = 0; i < 100; i++)
    {
        try
        {
            std::cout << "Throwing exception " << i + 1 << std::endl;
            throw std::exception();
        }
        catch (std::exception& e)
        {
            std::cout << "Caught exception " << i + 1 << std::endl;
            continue;
        }
    }

    return 0;
}

Step 2: Open in Ghidra Debugger

Open the compiled executable in Ghidra debugger and configure to debug with dbgeng.

Step 3: Continue Past Initial Breakpoints

Continue past the initial breakpoints.

Step 4: Call Sx* Commands to Change Exception Settings

Call sx* commands to change exception settings.

Step 5: Continue

Continue the debugger.

Expected Behavior

The default exception behavior should take place, or at least sx commands should work.

Screenshots

The following screenshots demonstrate the behavior:

Connected to Ghidra 11.3.2 at 127.0.0.1:8207

************* Preparing the environment for Debugger Extensions Gallery repositories **************
   ExtensionRepository : Implicit
   UseExperimentalFeatureForNugetShare : true
   AllowNugetExeUpdate : true
   NonInteractiveNuget : true
   AllowNugetMSCredentialProviderInstall : true
   AllowParallelInitializationOfLocalRepositories : true

   EnableRedirectToV8JsProvider : false

   -- Configuring repositories
      ----> Repository : LocalInstalled, Enabled: true
      ----> Repository : UserExtensions, Enabled: true

>>>>>>>>>>>>> Preparing the environment for Debugger Extensions Gallery repositories completed, duration 0.000 seconds

************* Waiting for Debugger Extensions Gallery to Initialize **************

>>>>>>>>>>>>> Waiting for Debugger Extensions Gallery to Initialize completed, duration 0.015 seconds
   ----> Repository : UserExtensions, Enabled: true, Packages count: 0
   ----> Repository : LocalInstalled, Enabled: true, Packages count: 29

Microsoft (R) Windows Debugger Version 10.0.26100.3624 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: C:\Users\vikin\test\except_test.exe

************* Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       srv*
Symbol search path is: srv*
Executable search path is:
ModLoad: 00000000`00040000 00000000`00079000   image00000000`00040000
ModLoad: 00007ffc`b19a0000 00007ffc`b1c00000   ntdll.dll
ModLoad: 00000000`76f90000 00000000`7714a000   ntdll32.dll
ModLoad: 00007ffc`b0be0000 00007ffc`b0c35000   C:\WINDOWS\System32\wow64.dll
ModLoad: 00007ffc`af9e0000 00007ffc`af9eb000   C:\WINDOWS\System32\wow64base.dll
ModLoad: 00007ffc`b0c40000 00007ffc`b0cc8000   C:\WINDOWS\System32\wow64win.dll
ModLoad: 00007ffc`b0e70000 00007ffc`b0e88000   C:\WINDOWS\System32\wow64con.dll
(6450.42a0): Break instruction exception - code 80000003 (first chance)
*** WARNING: Unable to verify checksum for C:\Users\vikin\test\except_test.exe

This is the Windows Debugger REPL. To drop to Python, type .exit
0:000> gc
ModLoad: 00000000`76f80000 00000000`76f8a000   C:\WINDOWS\System32\wow64cpu.dll
ModLoad: 00000000`76220000 00000000`76310000   C:\WINDOWS\SysWOW64\KERNEL32.DLL
ModLoad: 00000000`76cd0000 00000000`76f7d000   C:\WINDOWS\SysWOW64\KERNELBASE.dll
(6450.42a0): WOW64 breakpoint - code 4000001f (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
0:000:x86> gc
Throwing exception 1
(6450.42a0): C++ EH exception - code e06d7363 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
0:000> sxn eh
0:000> gc
Caught exception 1
Throwing exception 2
(6450.42a0): C++ EH exception - code e06d7363 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
0:000> sxe -c "gc" eh
0:000> gc
Caught exception 2
Throwing exception 3
(6450.42a0): C++ EH exception - code e06d7363 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
0:000> sxi eh
0:000> g
Caught exception 3
Throwing exception 4
0:000> g
Caught exception 4
Throwing exception 5
0:000> g
Caught exception 5
Throwing exception 6
0:000> g
Caught exception 6
Throwing exception 7
0:000> sxn eh
0:000> g
Caught exception 7
Throwing exception 8
(6450.42a0): C++ EH exception - code e06d7363 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
0:000> g
Caught exception 8
Throwing exception 9
(6450.42a0): C++ EH exception - code e06d7363 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
0:000>

Environment

The following environment was used to reproduce this behavior:

  • OS: Windows 11 24H2
  • Java Version: MS 21.0.6
  • Python Version: 3.11.9
  • Ghidra Version: 11.3.2
  • Ghidra Origin: Official GitHub Release

Additional Context

The same behavior is not present when using windbg through other debugging software. It seems to be specific to Ghidra. There are older (closed) issues which mention this issue but they seem to refer to the older debugger backend. If you are simply doing something wrong or missing something, please let us know.

Possible Solutions

  1. Check Ghidra Version: Make sure you are using the latest version of Ghidra. If you are using an older version, try updating to the latest version.
  2. Check Debugger Backend: Make sure you are using the dbgeng debugger backend. If you are using a different backend, try switching to dbgeng.
  3. Check Exception Settings: Make sure you have set the exception settings correctly using sx* commands.
  4. Check Ghidra Configuration: Make sure your Ghidra configuration is correct. Check the Ghidra documentation for more information on configuring Ghidra.

Conclusion

Q: What is the dbgeng debugger?

A: The dbgeng debugger is a powerful tool for debugging applications. It is a part of the Windows Debugger (cdb) and is used to debug Windows applications.

Q: What is the sx command?*

A: The sx* command is used to set exception settings in the dbgeng debugger. It allows you to control how the debugger handles exceptions.

Q: Why does the dbgeng debugger break on every exception despite using sx commands?*

A: The dbgeng debugger breaks on every exception despite using sx* commands because of a bug in the dbgeng debugger. This bug causes the debugger to break on every exception, even if the sx* commands are used to set exception settings.

Q: Is this behavior specific to Ghidra?

A: Yes, this behavior is specific to Ghidra. It is not present when using windbg through other debugging software.

Q: What are the possible solutions to this issue?

A: The possible solutions to this issue are:

  1. Check Ghidra Version: Make sure you are using the latest version of Ghidra. If you are using an older version, try updating to the latest version.
  2. Check Debugger Backend: Make sure you are using the dbgeng debugger backend. If you are using a different backend, try switching to dbgeng.
  3. Check Exception Settings: Make sure you have set the exception settings correctly using sx* commands.
  4. Check Ghidra Configuration: Make sure your Ghidra configuration is correct. Check the Ghidra documentation for more information on configuring Ghidra.

Q: Can I use windbg instead of dbgeng?

A: Yes, you can use windbg instead of dbgeng. Windbg is a powerful debugger that can be used to debug Windows applications.

Q: Are there any other debugging tools that I can use?

A: Yes, there are other debugging tools that you can use. Some popular debugging tools include:

  • Visual Studio Debugger
  • Eclipse Debugger
  • GDB (GNU Debugger)

Q: How can I report this issue to the Ghidra team?

A: You can report this issue to the Ghidra team by submitting a bug report on the Ghidra GitHub page. Make sure to include as much information as possible about the issue, including the steps to reproduce it and any relevant screenshots or logs.

Q: Can I get help from the Ghidra community?

A: Yes, you can get help from the Ghidra community. The Ghidra community is active and helpful, and you can ask for help on the Ghidra forums or on social media.