WSL: cppdbg debugger never starts after build (F5 does nothing)

[chasaba]

Environment

• OS and version: Windows 11 24H2 (Build 26200)
• VS Code: 1.129.1
• C/C++ extension: ms-vscode.cpptools 1.32.2
• OS and version of remote machine (if applicable): WSL2 Ubuntu, Linux 6.18.33.2-microsoft-standard-WSL2
• GDB / LLDB version: GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git

Bug Summary and Steps to Reproduce

Bug Summary:
In WSL2, the C/C++ debugger (cppdbg) no longer starts after pressing F5.

The build succeeds, but the debugger never launches. The debug toolbar remains disabled (gray), no debug session starts, and the program is never executed.

This previously worked in the same environment. Running the executable manually and running it under GDB from the terminal both work correctly, so the problem appears to be between VS Code and the C/C++ debug adapter.

Steps to reproduce:

1. Open a C++ source file in VS Code connected to WSL2 (Ubuntu).
2. Use the following launch.json:

{
"version": "0.2.0",
"configurations": [
{
"name": "Debug active file",
"type": "cppdbg",
"request": "launch",
"program": "${fileDirname}/${fileBasenameNoExtension}",
"cwd": "${fileDirname}",
"MIMode": "gdb",
"miDebuggerPath": "/usr/bin/gdb",
"stopAtEntry": true,
"preLaunchTask": "C/C++: g++ active file build"
}
]
}

3. Press F5.
4. The build completes successfully.
5. The debugger never starts. The debug toolbar stays gray and the program is never launched.
6. No error dialog is shown. Earlier, the Debug Console displayed:
   warning: GDB: Failed to set controlling terminal: Operation not permitted
   After reinstalling the extension and VS Code Server, that warning disappeared, but the debugger still never starts.
   GDB works correctly when launched manually from the WSL terminal.

Debugger Configurations

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug active file",
            "type": "cppdbg",
            "request": "launch",
            "program": "${fileDirname}/${fileBasenameNoExtension}",
            "cwd": "${fileDirname}",
            "args": [],
            "stopAtEntry": true,
            "externalConsole": true,
            "MIMode": "gdb",
            "miDebuggerPath": "/usr/bin/gdb",
            "preLaunchTask": "C/C++: g++ アクティブなファイルのビルド"
        }
    ]
}

Debugger Logs

GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git

Warning: Debuggee TargetArchitecture not detected, assuming x86_64.

Downloading separate debug info for system-supplied DSO...

Other Extensions

ms-ceintl.vscode-language-pack-ja
ms-vscode.cmake-tools
ms-vscode.cpp-devtools
ms-vscode.cpptools
ms-vscode.cpptools-extension-pack
ms-vscode.cpptools-themes

Additional Information

I have already tried the following without success:

• Reinstalled the C/C++ extension.
• Removed and reinstalled the VS Code Server.
• Deleted and recreated launch.json.
• Reinstalled the extension in WSL.
• Verified that GDB works correctly from the WSL terminal.
• Verified that the executable runs normally outside VS Code.
• Verified that gdb ./program can launch the program manually.
• Verified that OpenDebugAD7 exists.
• C/C++: Log Diagnostics reports no obvious problems.
• The build task completes successfully before debugging.

The problem started recently. Debugging worked previously in the same WSL environment.

After pressing F5, the build succeeds, but the debugger never starts. The debug toolbar remains gray, no debug session is created, and no error message is shown.
The problem also occurs with a minimal "Hello, World!" C++ program.

[ZippyNeuron]

It looks like you beat me to this particular report as I was experiencing the exact same issue. I had to roll the extension back to version 1.29.3 for the debugger to begin working again. I hope this helps.

[sean-mcmanus]

It sounds like you're hitting #14458 due to "Downloading separate debug info for system-supplied DSO..."? We have a fix in 1.33.4 pre-release. Does it work with that?

Also, FYI, our extension is intended to target Ubuntu 16+, so the intention is for 1.32.x+ to not be available for that OS, but it appears like VS Code is allowing that because your host OS of Windows 11 is supported, i.e. were you to use a non-remote Ubuntu 15 it should only show the versions of the extension that are intended to be supported for that. I'm not sure who is at fault for this (I would guess it's some issue with the VS Code remote support regarding extensions, but I could look more into where to file a complaint later...we set our minimum version to 1.77 for VS Code, which doesn't work on Ubuntu 15).