Windows11下VS Code结合MSYS2的GDB调试CMake项目失败：启动调试时出现GDB异常输出与0xc0000135错误

看起来你遇到的是MSYS2环境和VS Code调试环境不兼容的典型问题，我之前折腾MinGW+VS Code调试时也踩过几乎一样的坑，给你拆解一下问题根源和解决办法：

问题本质分析 #

首先，错误码0xc0000135是Windows平台非常明确的信号——程序启动时找不到依赖的动态链接库（DLL）。你的程序是用MSYS2 UCRT64分支的GCC编译的，它依赖UCRT64环境下的运行时库（比如libgcc_s_seh-1.dll、libstdc++-6.dll这些），但VS Code默认的调试环境是Windows原生环境，没有加载MSYS2 UCRT64的环境变量，导致程序启动时找不到这些DLL，直接闪退。

另外你用的GDB是MSYS2原生分支的（c:/msys64/usr/bin/gdb.exe），而不是UCRT64 MinGW分支的GDB，两者的目标程序兼容性存在细微差异，这也是为什么你手动在MSYS2 shell里运行GDB没问题（shell已经帮你配好了所有环境变量），但VS Code里调试就炸。

具体解决办法 #

方案1：修正launch.json的核心配置（最直接）

直接修改你的launch.json，确保使用UCRT64分支的GDB，并把UCRT64的bin目录优先加入调试环境的PATH：

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug (UCRT64)",
      "type": "cppdbg",
      "request": "launch",
      "program": "${command:cmake.launchTargetPath}",
      "args": [],
      "stopAtEntry": false,
      "cwd": "${command:cmake.launchTargetDirectory}", // 改为程序输出目录，避免路径混乱
      "environment": [
        {
          "name": "PATH",
          "value": "C:/msys64/ucrt64/bin;${env:PATH}" // 优先加载UCRT64的运行时库
        }
      ],
      "externalConsole": true,
      "MIMode": "gdb",
      "miDebuggerPath": "C:/msys64/ucrt64/bin/gdb.exe", // 改用UCRT64分支的GDB
      "preLaunchTask": "CMake: build",
      "setupCommands": [
        {
          "description": "启用GDB美化输出",
          "text": "-enable-pretty-printing",
          "ignoreFailures": true
        },
        {
          "description": "强制指定目标架构为x86_64",
          "text": "set architecture i386:x86-64:intel",
          "ignoreFailures": true
        }
      ]
    }
  ]
}

这里几个关键修改点：

• 把GDB路径换成UCRT64分支的（ucrt64/bin/gdb.exe），和你的编译器环境完全匹配
• 调试环境的PATH强制优先加载UCRT64的bin目录，确保程序能找到依赖DLL
• 把工作目录改成程序的输出目录，避免相对路径导致的加载问题

方案2：让VS Code默认使用MSYS2 UCRT64终端（更彻底）

如果方案1还是有隐藏的环境变量问题，可以直接让VS Code的终端和调试环境都用MSYS2 UCRT64的shell：

1. 打开VS Code设置（快捷键Ctrl+,），搜索Terminal > External: Windows Exec，设置为：

   C:\msys64\ucrt64.exe
   

2. 再搜索Terminal > External: Windows Args，设置为：

   -c "bash -l"
   

3. 重启VS Code后，调试时会自动在MSYS2 UCRT64的shell环境下启动GDB，所有环境变量都会自动配置好，和你手动运行的环境完全一致。

方案3：静态编译程序（应急小技巧）

如果你只是想快速验证程序功能，不想折腾环境，可以修改CMakeLists.txt让GCC静态链接所有依赖库，生成独立的可执行文件：

# 在CMakeLists.txt里添加这行，放在add_executable之后或者项目根配置里
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static -static-libgcc -static-libstdc++")

重新构建后，程序就不需要依赖外部DLL了，直接双击也能运行，调试时自然也不会有找不到DLL的问题。

验证步骤 #

1. 保存修改后的配置文件
2. 执行Ctrl+Shift+B重新构建项目
3. 按F5启动调试，观察是否能正常进入调试状态，程序窗口是否能稳定显示

为什么手动运行GDB没问题？ #

你在MSYS2 shell里手动启动GDB时，shell已经自动执行了UCRT64的环境初始化脚本，把所有必要的路径、变量都配置好了，程序自然能找到依赖；但VS Code的调试环境是独立的Windows原生进程，默认没有这些配置，所以必须手动指定才能正常工作。

内容来源于stack exchange