PAYATHON 2026

VS Code 更新后 C/C++ 调试器无法启动，如何排查？

数据小许

现有日志还不能确定根因。可以确认的是，CMake 构建已经成功，故障出现在后续的调试启动过程中。gdb --version 本身不是异常，可以先检查两套配置使用的可执行文件路径，以及 cppdbg 调试会话是否真正启动。

debugTarget Canceled: Canceled {} 表示相关操作被取消，但没有说明原因。仅凭这条信息，无法认定是 GDB 故障或某个版本的已知问题。

为什么会执行 gdb --version？

/usr/bin/gdb --version 用于查询版本，执行后就会退出。调试工具在准备启动会话时，通常会用这类命令探测调试器，再通过后续步骤启动真正的调试进程。

你提供的日志在这条命令之后，还输出了 Debug configuration from cache 和 Starting debugger with following configuration，说明日志没有停在版本查询这一步。

不过，Starting debugger 只说明 CMake Tools 已走到发起调试的阶段，不能证明调试适配器已经成功启动，也不能证明 GDB 已经加载目标程序。

先核对两套配置的程序路径

手写配置中的目标是：

${workspaceFolder}/projectXY

CMake Tools 生成的目标是：

/home/rasmus/Code/C++/projectXY/out/build/projectXY/projectXY

这两个路径不同。除非构建流程另外把程序复制到了工作区根目录，否则按 F5 使用手写配置时，可能会指向不存在或过期的文件。

在与 VS Code 调试扩展相同的环境中检查：

ls -l /home/rasmus/Code/C++/projectXY/projectXY
ls -l /home/rasmus/Code/C++/projectXY/out/build/projectXY/projectXY
file /home/rasmus/Code/C++/projectXY/out/build/projectXY/projectXY

即使手写配置确实有路径问题，也不能据此解释 CMake 调试按钮的全部故障。日志显示，CMake Tools 已经选择了构建目录里的目标，因此需要分别验证两个入口。

用最小配置直接启动 cppdbg

先完成一次构建，再在 .vscode/launch.json 中添加下面的配置。配置使用日志中的程序路径，并暂时移除 preLaunchTask，以便单独检查调试启动过程。

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "GDB direct diagnostic",
      "type": "cppdbg",
      "request": "launch",
      "program": "${workspaceFolder}/out/build/projectXY/projectXY",
      "cwd": "${workspaceFolder}/out/build/projectXY",
      "args": [],
      "stopAtEntry": true,
      "externalConsole": false,
      "MIMode": "gdb",
      "miDebuggerPath": "/usr/bin/gdb",
      "logging": {
        "engineLogging": true,
        "trace": true,
        "traceResponse": true
      }
    }
  ]
}

在“运行和调试”下拉框中明确选择 GDB direct diagnostic，然后按 F5，暂时不要使用 CMake Tools 的调试按钮。

  • 如果能启动，说明这套直接调用 GDB 的调试链路能够工作。接下来分别恢复 preLaunchTask 和原有设置，检查是哪一步重新触发故障，并继续核对 CMake Tools 生成的配置。
  • 如果仍然无响应，查看“调试控制台”和扩展日志，确认是否有调试适配器启动、GDB 启动或目标程序加载的错误。
  • 如果提示无法识别 cppdbg，优先检查提供该调试类型的 Microsoft C/C++ 扩展是否已启用，或是否激活失败。

stopAtEntry: true 有助于观察会话是否启动，减少程序立即退出造成的误判。诊断结束后，可以恢复原来的值并移除详细日志配置。

确认扩展运行环境一致

检查 Microsoft C/C++ 扩展和 CMake Tools 的启用状态，并查看“输出”面板中的相关日志。必要时运行 Developer: Show Logs...，查看 Extension Host 日志中是否存在扩展激活失败或异常。

如果使用 SSH、WSL 或 Dev Container，应在相应的远程环境中检查。终端能运行 /usr/bin/gdb，只有在终端与调试扩展处于同一环境时，才有直接参考价值。

保留同一次启动尝试中取消异常之前的错误和调用栈。单独一条 debugTarget Canceled 通常不足以定位责任环节。

在终端验证 GDB 能否加载目标程序

能打开 GDB，不代表它能通过 VS Code 使用的 MI 接口加载并运行这个程序。可以执行：

/usr/bin/gdb --quiet --interpreter=mi2 /home/rasmus/Code/C++/projectXY/out/build/projectXY/projectXY

进入 GDB 后，输入：

-exec-run

观察目标程序是否开始运行，以及是否出现加载失败、权限限制或其他明确错误。程序退出或停止后，可用以下命令结束 GDB：

-gdb-exit

如果这里也失败，应优先处理 GDB 给出的具体错误。如果这里能运行，而最小 cppdbg 配置失败，则重点检查 C/C++ 扩展、调试适配器及其运行环境。

如何判断是否与更新有关？

“更新后出现”是一条线索，但不足以确认 VS Code 1.112.0 存在回归。建议记录 VS Code、C/C++ 扩展、CMake Tools 和 GDB 的实际版本，并在保留同一份最小配置的前提下进行比较。

如果需要验证回归，可以一次只将一个组件切换到已知可工作的版本，再重复同样的启动操作。不要同时修改多个版本和多项配置，否则很难判断是哪项变化影响了结果。

建议先修正并确认 program 路径，再使用带日志的最小 cppdbg 配置直接启动。这两步有助于区分 F5 配置问题与 CMake Tools 调试入口的问题；最终原因仍需结合调试适配器日志确认。

备注：内容仅供参考。