Unable to start debugging. Unexpected GDB output from command "-exec-run"

Question

On a pristine new Windows 11, installed Visual Studio code, MSYS2(ucrt64), and under it: base_devel, gcc, gdb, cmake. In Visual Studio code when first opening a .cpp file I accepted its advice to install the C++ extensions, which turned out to include Cmake Tools. I selected a "kit" involving GCC 13.3.0-pc-msys.

Now I go to build and run my first CMake project, a simple "Hello world" cpp program. Builds okay, but when it comes time to run it, it doesn't. I see a window flash in and out of existence in a split second, and I see the following report in the Debug Console tab. Incidentally, x86_64 is a correct assumption that it makes.

=thread-group-added,id="i1"
GNU gdb (GDB) 14.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Warning: Debuggee TargetArchitecture not detected, assuming x86_64.
=cmd-param-changed,param="pagination",value="off"
[New Thread 28868.0x567c]
[New Thread 28868.0x6c44]
[Thread 28868.0x7360 exited with code 3221225781]
[Thread 28868.0x6c44 exited with code 3221225781]
ERROR: Unable to start debugging. Unexpected GDB output from command "-exec-run". During startup program exited with code 0xc0000135.
The program 'C:\Users\com\Downloads\Prog24\Hello2\build\TestProgram.exe' has exited with code 0 (0x00000000).

Sometimes (same directory, same source program, same launch.json) I see this variation of the last few lines instead:

Warning: Debuggee TargetArchitecture not detected, assuming x86_64.
=cmd-param-changed,param="pagination",value="off"
[Thread 10136.0x710c exited with code 3221225781]
[New Thread 10136.0x3138]
ERROR: Unable to start debugging. GDB exited unexpectedly.
The program 'C:\Users\com\Downloads\Prog24\Hello2\build\TestProgram.exe' has exited with code 0 (0x00000000).

ERROR: During startup program exited with code 0xc0000135.

Okay, unexpected GDB output. Somewhere there is probably a "verbose" flag or variable that I could set to get more details. Is there? (Strongly suspecting that this answer is outdated and no longer relevant.)

Is this a familiar scenario? That I somehow got the wrong flavor of GDB installed? Here is launch.json, and it makes no difference at all whether the miDebuggerPath line is included or omitted. Incidentally, if I invoke gdb on the target manually and then type 'r' to it, the program runs just fine.

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug",
            "type": "cppdbg",
            "request": "launch",
            "program": "${command:cmake.launchTargetPath}",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [
                {
                    "name": "PATH",
                    "value": "$PATH:${command:cmake.launchTargetDirectory}"
                }
            ],
            "externalConsole": true,
            "MIMode": "gdb",
            "miDebuggerPath": "c:/msys64/usr/bin/gdb.exe",
            "preLaunchTask": "CMake: build",
            "postDebugTask": ""
        }
    ]
}

gcc 13.3.0, gdb 14.2

Could be wrong here, but using the cygwin version (This GDB was configured as "x86_64-pc-cygwin".) looks odd. I'd have expected the w64-mingw32 version for UCRT (This GDB was configured as "x86_64-w64-mingw32".). — user4581301
– user4581301, Commented Jun 10 at 0:40
During startup program exited with code 0xc0000135 0xc0000135 is missing DLL, possibly one of the cygwin support DLLs, but whatever the cause, the version of gdb you're trying to run wants a DLL that's not in the path. Odds are you've installed the right stuff if you followed the VSC instructions, but you could have another set of tools earlier in the system path that's wreaking havoc. Open a Msys2 terminal and type pacman -Q mingw-w64-ucrt-x86_64-gdb to confirm you've got the matching gdb installed. — user4581301
– user4581301, Commented Jun 10 at 0:50
If you do, you need to go fishing to see why your computer's hellbent on using the wrong one. — user4581301
– user4581301, Commented Jun 10 at 0:50
Side note: You may have to add some stuff of your own to the system path. You may need C:\msys64\usr\bin and C:\msys64\ucrt64\bin. There is a danger in doing this, though, as many programs use bits of mingw in them and if you allow multiple different versions of stuff in the system path you'll quickly lose control. The most common is a problem called DLL Hell. Program X needs version 1.2 of a library, but it could find version 1.1 first, try to use it, and mysteriously crash because 1.1 and 1.2 are just too different. — user4581301
– user4581301, Commented Jun 10 at 18:54
gdb is starting and we're now sure that the correct gdb is in play. The Sysinternals Process Monitor should be able to tell you what DLL could not be successfully resolved. By default it shows you everything happening on your computer so you'll have to apply a filter that only shows events for the gdb.exe process name. Start procmon, set the filter, run the debugger, wait for the crash. Looks at the logged events for the DLL that the system looked for but could not resolve. — user4581301
– user4581301, Commented Jun 11 at 16:38

Batuhan Yamaner · Accepted Answer · 2025-10-31 12:56:04Z

I was getting a similar error before it’s a different situation, but the error itself was the same, so maybe it’ll help you too.

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug STM8 (stm8-gdb + OpenOCD)",
      "type": "cppdbg",
      "request": "launch",
      "program": "${workspaceFolder}/build/main.elf",
      "cwd": "${workspaceFolder}",
      "stopAtEntry": true,
      "MIMode": "gdb",
      "miDebuggerPath": "/usr/local/bin/stm8-gdb",

      // GDB server (OpenOCD)
      "debugServerPath": "openocd",
      "debugServerArgs": "-f interface/stlink.cfg -f target/stm8s.cfg",
      "serverStarted": "Listening on port 3333",
      "miDebuggerServerAddress": "localhost:3333",

      "filterStderr": true,

      "setupCommands": [
        { "description": "Set breakpoint at main", "text": "break main" }
      ],

      "logging": {
        "moduleLoad": true,
        "trace": true,
        "engineLogging": false,
        "programOutput": true,
        "exceptions": true
      }
    }
  ]
}

I was running OpenOCD with this command, but that was actually the cause of the problem itself.

"debugServerPath": "openocd",
      // "debugServerArgs": "-f interface/stlink.cfg -f target/stm8s.cfg -c \"init\" -c \"reset halt\"",
      "debugServerArgs": "-f interface/stlink.cfg -f target/stm8s.cfg -c \"init\" -c \"sleep 300\" -c \"reset halt\"",
      "serverStarted": "Listening on port 3333",
      "filterStderr": true,

Collectives™ on Stack Overflow

Unable to start debugging. Unexpected GDB output from command "-exec-run"

1 Answer 1

Comments

Your Answer

Linked

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

Comments

Your Answer

Sign up or log in

Post as a guest

Linked

Related