Vscode-cpptools: Unable to start debugging. Program path "C:\Users\me\Repositories\cppplayground\first.exe" is missing or invalid.

[Addie2595]

This is my first.cpp:

#include <iostream>

int main() {
    std::cout << "Hello world!"<< std::endl;
    return 0;
}

c_cpp_properties.json:

{
    "configurations": [
        {
            "name": "Win32",
            "intelliSenseMode": "clang-x64",
            "includePath": [
                "${workspaceRoot}",
                "C:/MinGW/lib/gcc/mingw32/6.3.0/include/c++",
                "C:/MinGW/lib/gcc/mingw32/6.3.0/include/c++/mingw32",
                "C:/MinGW/lib/gcc/mingw32/6.3.0/include/c++/backward",
                "C:/MinGW/lib/gcc/mingw32/6.3.0/include",
                "C:/MinGW/include",
                "C:/MinGW/lib/gcc/mingw32/6.3.0/include-fixed"
            ],
            "defines": [
                "_DEBUG",
                "UNICODE",
                "__GNUC__=6",
                "__cdecl=__attribute__((__cdecl__))"
            ],
            "browse": {
                "path": [
                    "C:/MinGW/lib/gcc/mingw32/6.3.0/include",
                    "C:/MinGW/lib/gcc/mingw32/6.3.0/include-fixed",
                    "C:/MinGW/include/*"
                ],
                "limitSymbolsToIncludedHeaders": true,
                "databaseFilename": ""
            }
        }
    ],
    "version": 3
}

tasks.json:

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "build first",
            "isShellCommand": true,
            "command": "g++",
            "args": [
                "-o", "${fileBasenameNoExtension}", "${file}"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            }
        }
    ]
}

launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "C:\\Users\\me\\Repositories\\cppplayground\\first.exe",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": true,
            "MIMode": "gdb",
            "miDebuggerPath": "C:/MinGW/bin/gdb.exe",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ]
        }
    ]
}

I don't see why it should not work.

EDIT: Before someone asks, yes, I googled, I know there are similar issues, they're not helpful.

[bobbrow]

can you try adding "-g" to your task "args"? You need to output symbol information in order for debugging to work.

[pieandcakes]

@Addie2595 Also, if you use "${fileBasenameNoExtension}" in your task.json, are you actually getting a first.exe or are you only seeing a first file ? you can change your task.json to say:

 "args": [
               "-g", "-o", "${fileBasenameNoExtension}.exe", "${file}"
            ],

and that might fix the problem. Also, added -g or else the compiler doesn't include debug symbols and the debugger won't know what to do.

[markeissler]

I'm getting the same error on macOS when trying to connect to a remote gdbserver (running in a docker container). If I use the Native Debug extension I don't have this problem.

[pieandcakes]

@markeissler you can enable "logging": { "engineLogging": true } and see what we send to gdb. If you are getting the same error, my assumption is that gdb or gdbserver is unable to locate the file based on the parameters you provided in the program field.

[markeissler]

@pieandcakes Thanks for the tip! After doing that I also did this:

prompt> file project/target
project/targer: Bourne-Again shell script text executable, ASCII text, with very long lines

Embarrassing. New third-party project...didn't think to look that target was a wrapper intended to check that all runtime shared libs were available before launching the actual target binary stuffed in a separate .lib directory. Sigh.

Remote connections work for me now. :)

[pieandcakes]

@markeissler What does that block do?

[markeissler]

@pieandcakes Block? I just ran the file command on the actual file I was trying to debug, which I had thought was the built binary but ended up being a wrapper around the compiled binary (they both had the same name). Point being: make sure you're not trying to run gdb on a script!

[pieandcakes]

@markeissler Ah that makes more sense. Sorry, I was trying to see if file project/target was something special that we needed to run :)

[pieandcakes]

@Addie2595 if this is still a problem, please update the issue and reopen. Thanks