Debugger not starting

Bug type: Debugger

• OS and Version: Windows 10 Build 19042.985
• VS Code Version: 1.56.2
• C/C++ Extension Version: v1.4.0-insiders
• other extensions: remote-ssh

I've been working with remote-ssh and c/c++ without any issue, all of a sudden I cannot start the debugger. Nothing changed, configuration files are the same as before but now when I start the debugger, I see for a couple of seconds the top debugging bar and then it disappears. No message on the console, nothing.

For this purpose, I created a simple project from scratch, and even there, the same issue appears.

To Reproduce
launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/a.out",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "logging": { "engineLogging": true },
            "externalConsole": true,
            "MIMode": "gdb",
            "miDebuggerPath": "/usr/bin/gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": false
                }
            ]
        }
    ]
}

main.c

#include <stdio.h>
int main(){
	printf("ciao\n");
	return 1;
}

Compile with gcc -g main.c

As I stated before, this workflow worked for me, from one second to another it stopped working as intended and I have no idea why and how to fix it, any help is appreciated.

What I tried

• reinstall vscode
• reinstall the c/c++ extension and delete by hand the extension folder
• numerous reboots

Updates

I have tried with the wsl-remote extension and it is working as expected.

Start by reproducing the failure with the provided launch.json and main.c using VS Code 1.56.2, the C/C++ extension v1.4.0-insiders, and the listed remote-ssh setup. Inspect the engineLogging output and compare the behavior with the reported WSL-remote case; done means the debugger starts and remains available for the sample program.