vscode-cpptools 🚀 - Launch bash failed when debugging bash on Windows!

@bigtang5 did you install gdb in bash on windows?

pieandcakes on 12 Jul 2017

Thanks, sure I installed gdb, run gdb in bash: the first line is:
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1

All the Win10 PC have the same bug in my office.

When I input this in CMD window : bash "/usr/bin/gdb --interpreter=mi"
and click, it shows: /bin/bash: /usr/bin/gdb --interpreter=mi: No such file or directory

but list /usr/bin/gdb in bash: ls /usr/bin/gdb
It did exist.

bigtang5 on 13 Jul 2017

@bigtang5 Sounds like an issue with Bash on Windows? Can you tell me which version you have there so I can try and repro it?

pieandcakes on 13 Jul 2017

Thanks @pieandcakes , my notebook installed the Windows 10,
in bash window:
$ cat /etc/issue
Ubuntu 14.04.5 LTS \n \l

$ sudo lsb_release -a
[sudo] password for tap:
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty

in CMD window:

c:>bash -version
GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

bigtang5 on 14 Jul 2017

Same problem here, with the same configuration on launch.json, and gdb installed on bash.

Console output :

Starting: "C:\Windows\sysnative\bash.exe" "/usr/bin/gdb --interpreter=mi"
/bin/bash: /usr/bin/gdb --interpreter=mi: No such file or directory
"C:\Windows\sysnative\bash.exe" exited with code 127 (0x7F).

mahdibx on 16 Jul 2017

Hi @bigtang5 @mahdibx,

Per our documentation, it looks like at least @bigtang5 is missing "-c" in the pipeArgs field. Can you try and update that and see if that fixes your problem?

pieandcakes on 17 Jul 2017

@bigtang5 I've already tried this, there is no output in the debugger console though, the debugger doesn't crash, but no debugging is going on either, an the program doesn't seem to run at all.
Here is what I tried earlier:

"pipeTransport": {
                "debuggerPath": "",
                "pipeProgram": "C:\\Windows\\sysnative\\bash.exe",
                "pipeArgs": ["-c", "\"/usr/bin/gdb --interpreter=mi\""],
                "pipeCwd": ""
            },

And I tried your solution, but the debugger returns an error:
Unable to start debugging. Unexpected GDB output from command "-environment-cd c:/master". c:/master: No such file or directory.

mahdibx on 18 Jul 2017

@mahdibx You shouldn't need to specify "/usr/bin/gdb --interpreter=mi" in your args field. It should be

"pipeTransport": {                 "debuggerPath": "/usr/bin/gdb",                 "pipeProgram": "C:\\Windows\\sysnative\\bash.exe",                 "pipeArgs": [ "-c" ],                 "pipeCwd": ""             },

And I tried your solution, but the debugger returns an error:Unable to start debugging. Unexpected GDB output from command "-environment-cd c:/master". c:/master: No such file or directory.

There is an issue that should be fixed in the next drop with the -envinronment-cd step.

pieandcakes on 18 Jul 2017

@pieandcakes cool thanks for the answers, do you have any idea when the next drop is coming?

mahdibx on 18 Jul 2017

@mahdibx Should be today.

sean-mcmanus on 18 Jul 2017

Hi.

I used two ways in order to make it work (Which is displayed here as a tutorial and the OP's trying by add the "-c" args into the array), but the result was the same as usual.

Starting: "C:/Windows/sysnative/bash.exe" -c "/usr/bin/gdb --interpreter=mi"
Error: 0x80070057

"C:/Windows/sysnative/bash.exe" exited with code -1 (0xFFFFFFFF).

That's the only output when I try to debug executable (The path is fine). So, I'm with tight hands with nothing to do. Any helps? Very grateful :3.

Greetings from Chile.

@pieandcakes

xLobito on 1 Aug 2017

hi @Sean McManus:

I have updated to the newest Code version, the bug was still there:

Starting: "C:\Windowssysnativebash.exe" -c "/usr/bin/gdb --interpreter=mi"
0x80070057
"C:\Windowssysnativebash.exe" exited with code -1 (0xFFFFFFFF).

bigtang5 on 21 Aug 2017

@bigtang5 @xLobito Can both of you try and run "C:/Windows/sysnative/bash.exe" -c "/usr/bin/gdb --interpreter=mi" from a command line window and see if gdb runs?

pieandcakes on 21 Aug 2017

@pieandcakes

Indeed. From Windows command line works running gdb Linux bash as expected. That's why this is strange.

Thanks in advance.

xLobito on 21 Aug 2017

@xLobito Can you share your entire launch.json block? Also, can you tell me which Windows 10 version you are running and if you have recently upgraded WSL to the latest version using sudo apt update / sudo apt upgrade ?

I just updated everything and setup a new project and I can't duplicate it.

pieandcakes on 22 Aug 2017

in my win10 CMD window， run "C:/Windows/sysnative/bash.exe" -c "/usr/bin/gdb --interpreter=mi",
echo "system can't find the path"
run bash -c "/usr/bin/gdb --interpreter=mi", gdb loaded ok.

bigtang5 on 22 Aug 2017

@bigtang5 Well, as far as I know, system can't find that folder 'cause sysnative comes to be an alias of System32 folder. If you try to run this with System32, the output should be the same as running bash.

@pieandcakes I upgraded to the latest version available and tried again. Same output.

captura

Edit: The W10 version I'm using is: W10 Pro - Comp. 14393.

Thanks.

xLobito on 22 Aug 2017

@xLobito It looks like you need to update to Creator's Update to have WSL work with the extension. Per the documentation, you need to be on Creator's Update or later. That seems to be build 15063. 14393 is Anniversary Update, which does not contain fixes in WSL that we depend on.

@bigtang5 What @xLobito says is correct. sysnative is converted to the x64's system32 to guarantee that we get the correct folder.

pieandcakes on 22 Aug 2017

Perfect. I didn't find that docs. If I just had seen it...
I'll update to latest build and write what happens next.

Thanks for all you've done.

xLobito on 22 Aug 2017

@xLobito I'll update the documentation to be a bit more clear. Thanks for the heads up

pieandcakes on 22 Aug 2017

My launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Bash on Windows Launch",
"type": "cppdbg",
"request": "launch",
"program": "/mnt/c/Linux/test/a.out",
"args": [],
"stopAtEntry": false,
"cwd": "/mnt/c/Linux/test",
"environment": [],
"externalConsole": true,
"pipeTransport": {
"debuggerPath": "/usr/bin/gdb",
"pipeProgram": "C:\Windows\System32\bash.exe",
"pipeArgs": ["-c"],
"pipeCwd": ""
},
"windows": {
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
},
"sourceFileMap": {
"/mnt/c": "c:\"
}
}
]
}
When starting debug, the message was:
Unable to start debugging. There was an error starting the pipe program 'C:\Windows\System32bash.exe'.

Then I changed 'C:\Windows\System32bash.exe' to 'C:\Windowssysnativebash.exe'.
The message was:
Unable to start debugging. Unable to establish a connection to GDB. Debug output may contain more information.
The ouput was:
Starting: "C:\Windowssysnativebash.exe" -c "/usr/bin/gdb --interpreter=mi"
曪? 0x80070057

"C:\Windowssysnativebash.exe" exited with code -1 (0xFFFFFFFF).

bigtang5 on 29 Aug 2017

@bigtang5 Which version of windows 10 are you running? Are you running the version with Creator's Update? This will show as 15063, Any version before that does not contain the bug fixes in WSL that are necessary for us to communicate with bash.

pieandcakes on 29 Aug 2017

I recently updated to latest W10 build and it's working now.

Thanks a lot for the help @pieandcakes

xLobito on 30 Aug 2017

The bug cleared when my WIN10 upgraded to version 15063. Thanks a lot @pieandcakes!

bigtang5 on 13 Sep 2017

Windows 10 Enterprise (Microsoft Windows [Version 10.0.14393]) has that bug!

ademyankov on 29 Nov 2017

@ademyankov The fix is in Win 10 version 15063 as I posted above. Since the fixes to enable this scenario are in WSL itself, you need to upgrade your Windows 10 version to Creators Update or newer. If not, then it will not work.

pieandcakes on 29 Nov 2017

I am confused about all those versions. What version are you talking about?
I have: Windows 10 Enterprise, Version: 1607, OS Build: 14393.1884. And windows updater doesn't show that there is any updates available. Do I have to install that Creators Update manually?

ademyankov on 29 Nov 2017

@ademyankov You can see the Windows 10 version history here: https://technet.microsoft.com/en-us/windows/release-info.

You are running Version 1607 OS Build 14393 (Anniversary Update). They made fixes within WSL to support debugging from outside of WSL. Those fixes are in Version 1703 OS Build 15063 (Creators Update). Without those fixes, debugging does not work properly, which is why we require Creators Update or newer. You may need to install it manually if you were not updated to it.

pieandcakes on 30 Nov 2017

Oh! Ok, I see. Thanks a lot!

ademyankov on 30 Nov 2017

Hey @pieandcakes , sorry to bring the bad news but, after I installed the update I was able to go through that issue 2 or 3 times. And then, it broke again and now, it doesn't work anymore.

This is the log:

5: (1766004) Starting: "c:\Windows\Sysnative\bash" -c "gdb --interpreter=mi"
5: (1766035) "c:\Windows\Sysnative\bash" exited with code -1 (0xFFFFFFFF).
5: (1766036) <-logout

ademyankov on 30 Nov 2017

@ademyankov did you install gdb ? if you run c:\windows\system32\bash.exe -c "gdb --interpreter=mi" from a command prompt does it work?

pieandcakes on 30 Nov 2017

Yes it does!

C:\Users\ademyankov>c:\Windows\System32\bash -c "gdb --interpreter=mi"
=thread-group-added,id="i1"
~"GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.3) 7.7.1\n"
~"Copyright (C) 2014 Free Software Foundation, Inc.\n"
~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law.  Type \"show copying\"\nand \"show warranty\" for details.\n"
~"This GDB was configured as \"x86_64-linux-gnu\".\nType \"show configuration\" for configuration details."
~"\nFor bug reporting instructions, please see:\n"
~"<http://www.gnu.org/software/gdb/bugs/>.\n"
~"Find the GDB manual and other documentation resources online at:\n<http://www.gnu.org/software/gdb/documentation/>.\n"
~"For help, type \"help\".\n"
~"Type \"apropos word\" to search for commands related to \"word\".\n"
(gdb)

ademyankov on 30 Nov 2017

Whats your launch.json ? Also, please do winver and let me know which version of windows you are on now.

pieandcakes on 30 Nov 2017

{
  "version": "0.2.1",
  "defaults": {},
  "configurations": [
    {
      "type": "cppdbg",
      "name": "aarch64",
      "project": "app.out.exe",
      "cwd": "${workspaceRoot}",
      "program": "${debugInfo.target}",
      "MIMode": "gdb",
      "externalConsole": true,
      "pipeTransport": {
        "pipeProgram": "c:\\Windows\\Sysnative\\bash",
        "pipeArgs": [
          "-c"
        ],
        "debuggerPath": "/usr/bin/gdb"
      },
      "setupCommands": [
        {
          "text": "-enable-pretty-printing",
          "ignoreFailures": true
        }
      ],
      "miDebuggerServerAddress": "localhost:1234",
      "visualizerFile": "${debugInfo.linuxNatvisPath}",
      "showDisplayString": true
    }
  ]
}

ademyankov on 30 Nov 2017

This doesn't look like VSCode's json. What is ${debugInfo.target}, why do you also have "miDebuggerServerAddress" specified? you will need to specify the "cwd" in respect to where the "program" is in WSL.

pieandcakes on 30 Nov 2017

Sorry, probably I had to mention this. It's vs2017. The original issue is started here.
But anyway, the problem has the same roots and I will deal with application folders and cwd later on.

ademyankov on 30 Nov 2017

So after you updated it worked a few times? and you are running VS 2017 15.4.5 ? I'm trying to reproduce this issue. Also, i'm confused with the addition of QEMU in this. If it was directly an app in WSL, does it work?

pieandcakes on 30 Nov 2017

So after you updated it worked a few times?

Yes, a few times and then it stopped working no matter what I tried to do. Restart, reboot, regenerate a new script, whatever.

Yes, VS 2017 15.4.5

Also, i'm confused with the addition of QEMU in this

I am trying to do a remote debugging because code is crosscompiled for aarch64 and launched in arm vm using qemu. Simple command from gdb (in windows bash), like this:
(gdb) target remote 10.1.*.*.100:1234

Connects gdb to qemu and then I can control all I need.

So, the idea was to replicate this behavior using VS2017 debugger.

ademyankov on 30 Nov 2017

Which version of windows are you on now?

pieandcakes on 30 Nov 2017

Windows 10 Enterprise, Version 1709, OS Build 16299.15

ademyankov on 30 Nov 2017

Looks like you updated to Fall Creators Update. I wonder if you are running into: https://github.com/Microsoft/WSL/issues/2592 which we've seen and can't seem to get out of.

pieandcakes on 30 Nov 2017

@pieandcakes
I am on latest stable VS Code + Windows 10.0.15063 but I still get the error mentioned in this thread earlier:

Unable to start debugging. Unexpected GDB output from command "-environment-cd c:/Users

Any ideas? Starting gdb from bash or Windows cmd works.

Launch config is the default "GDB: Bash on Windows Launch" but I had to add "-c" as pipe argument.

cylonid on 30 Nov 2017

@uwe-h You need to change your "cwd" to be the working directory format for WSL. so something like "/mnt/c/......"

pieandcakes on 30 Nov 2017

@ademyankov I'm running VS 2017 15.4.5 with winver 16299.64. The difference I noticed is that I'm running gdb 7.11.1 but I also ran sudo apt update and sudo apt upgrade in WSL recently. I wish I could see if my WSL version is the same as yours but I can't find anything on their page to tell me how to check for that.
My bash.exe file version is 10.0.16299.15 which looks the same as you. Can you try and remove/reinstall WSL and see if that changes anything?

pieandcakes on 1 Dec 2017

@pieandcakes Thanks, gdb starts using the attached launch.json. Still, the debugging does not really work. In my C source, I set a breakpoint on a line with malloc. As soon as I want to go past this breakpoint, I get

malloc.c could not be openend. File not found (file:///build/glibc-bfm8X4/glibc-2.23/malloc/malloc.c).

So I guess there is still something weird going on regarding the path?

{ "version": "0.2.0", "configurations": [{ "name": "(gdb) Bash on Windows Launch", "type": "cppdbg", "request": "launch", "program": "/mnt/c/Users/uw/Code/C-Coding/debugme", "args": [], "stopAtEntry": false, "cwd": "/mnt/c/Users/uw/Code/C-Coding", "environment": [], "externalConsole": true, "pipeTransport": { "debuggerPath": "/usr/bin/gdb", "pipeProgram": "C:\\Windows\\sysnative\\bash.exe", "pipeArgs": ["-c"], "pipeCwd": "" }, "setupCommands": [{ "description": "Enable pretty-printing for gdb", "text": "-enable-pretty-printing", "ignoreFailures": true }] }] }

cylonid on 1 Dec 2017

@uwe-h Nope, that's expected. I assume you don't have the source code file of malloc.c which is where it is trying to break into.

pieandcakes on 1 Dec 2017

👍1

@pieandcakes Ok, I got some progress. Looks like I didn't have to reinstall WSL, reinstalling of Linux components in Visual Studio Installer helped. GDB now launches.

Thanks for the help.

ademyankov on 1 Dec 2017

ok awesome thanks!

pieandcakes on 1 Dec 2017

I found another bug or misbehavior. You get that error:

every time when you have an instance of WLS running.

ademyankov on 2 Dec 2017

What do you mean by 'every time you have an instance of WLS running'?
Are you running gdb in another instance? Can you provide repro steps in a new issue? This sounds like it might be a WSL bug.

pieandcakes on 2 Dec 2017

So, if I have WSL/bash running, even if I don't do there anything in it, when I try to launch my vs2017 debugging it gives that error. When I close WSL then it runs successfully.

ademyankov on 2 Dec 2017

@ademyankov I tried this:

Works fine for me. Is this with your QEMU/gdb-gdbserver/cross compiled setup? Did you ask @paulmaybee if he has seen this before?

pieandcakes on 2 Dec 2017

Yes, I've just tried this. With regular Linux app in vs2017 it works just fine. But, as you can see from my screen shot, I am doing some magic VS using the Open Folder debugging experience, whatever it means. So, I don't know, maybe that particular setup is the problem.

And, no, I have not asked @paulmaybee about that, for now, I have more important things to worry about, I am still not able to run gdb the way I need.

ademyankov on 2 Dec 2017

I am also running open folder in my screenshot. I don't know if this is something with your setup or not.

pieandcakes on 2 Dec 2017

Ok, I am trying to figure out how to run it as open folder and it doesn't work for me.
It just sits there:

7: (1217214) LaunchOptions{
7: (1217214) LaunchOptions  "target": "\\\\10.1.121.87\\projects\\ConsoleApplication1\\bin\\x64\\Debug\\ConsoleApplication1.out.exe",
7: (1217214) LaunchOptions  "type": "cppdbg",
7: (1217214) LaunchOptions  "name": "ConsoleApplication1.out.exe",
7: (1217214) LaunchOptions  "project": "ConsoleApplication1.out.exe",
7: (1217214) LaunchOptions  "cwd": "${debugInfo.remoteWorkspaceRoot}",
7: (1217214) LaunchOptions  "program": "${debugInfo.fullTargetPath}",
7: (1217214) LaunchOptions  "MIMode": "gdb",
7: (1217214) LaunchOptions  "externalConsole": true,
7: (1217214) LaunchOptions  "remoteMachineName": "${debugInfo.remoteMachineName}",
7: (1217214) LaunchOptions  "pipeTransport": {
7: (1217214) LaunchOptions    "pipeProgram": "c:\\Windows\\Sysnative\\bash",
7: (1217214) LaunchOptions    "pipeArgs": [
7: (1217214) LaunchOptions      "/s",
7: (1217214) LaunchOptions      "${debugInfo.remoteMachineId}",
7: (1217214) LaunchOptions      "/p",
7: (1217214) LaunchOptions      "1832",
7: (1217214) LaunchOptions      "/c",
7: (1217214) LaunchOptions      "gdb --interpreter=mi"
7: (1217214) LaunchOptions    ]
7: (1217214) LaunchOptions  }
7: (1217214) LaunchOptions}
7: (1217223) Starting: "c:\Windows\Sysnative\bash" /s ${debugInfo.remoteMachineId} /p 1832 /c "gdb --interpreter=mi" "/usr/bin/gdb --interpreter=mi"
7: (1217266) STDERR: /bin/bash: ${debugInfo.remoteMachineId}: bad substitution
7: (1296650) <-logout

BTW, if I use:
"pipeProgram": "${debugInfo.shellexecPath}",
as it created by default via wizard, than it doesn't start at all:

9: (1430455) Starting: "C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2017\PROFESSIONAL\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\LINUX\..\..\Linux\Linux\shellexec.exe" /s ${debugInfo.remoteMachineId} /p 1832 /c "gdb --interpreter=mi" "/usr/bin/gdb --interpreter=mi"
9: (1430499) ->shellexec 1.0
9: (1430500) ->Copyright (C) 2016 Microsoft Corporation. All rights reserved.
9: (1430500) ->
9: (1430500) ->Invalid value for parameter /s, expected a number ex: shellexec /s 21542213
9: (1430500) ->

ademyankov on 2 Dec 2017

@ademyankov Yea, you are in a place i'm unfamiliar with. You know this forum is for the CPPTools extension for VSCode?

I think you are using configurations created by Paul's team. I don't know what those debugInfo substitutions are or what they give you or if it is part of the problem. I also noticed you are specifying gdb --interpreter=mi in the pipeArgs but that isn't needed (as you can see in the last block it is in there twice in the command. As I mentioned before, there is an issue https://github.com/Microsoft/WSL/issues/2592 that makes it look like bash is hung and not returning data, which is why I think you are getting that Initializing message.

pieandcakes on 2 Dec 2017

You know this forum is for the CPPTools extension for VSCode?

Yes, I do.

I also noticed you are specifying gdb --interpreter=mi in the pipeArgs but that isn't needed

I have to mess around with it, because it doesn't work out of the box. It's the wizard who created that json. I agree, that a regular user shouldn't even look into that let along modify it or mess around with it.

Anyway, I'll keep digging...

ademyankov on 2 Dec 2017

@pieandcakes I figured out why I wasn't able to run vs2017 debugger with another instance of WSL at the same time!

Cannot launch bash because another instance is running elevated. Elevated and un-elevated instances are not permitted to run simultaneously.

My vs2017 was running as admin and WSL as a regular user. So, you just have to make sure that both instances have the same privileges while running simultaneously.

Cheers!

ademyankov on 5 Dec 2017

@ademyankov Awesome! That's good to know. I'll add that to my FAQ.

pieandcakes on 5 Dec 2017

Thanks, gdb starts using the attached launch.json. Still, the debugging does not really work. In my C source, I set a breakpoint on a line with malloc. As soon as I want to go past this breakpoint, I get

malloc.c could not be openend. File not found (file:///build/glibc-bfm8X4/glibc-2.23/malloc/malloc.c).
So I guess there is still something weird going on regarding the path?

@pieandcakes I'm having the same problem @uwe-h described.
Breakpoints can be set.
But when executing the debugger, I got this error:
Unable to open 'main.cpp': File not found (file:///mnt/c/Users/xxx/Project/a/main.cpp).
Vscode is trying to find files in c:\mnt\c...
which doesn't exist in my computer.
How to convert /mnt/c/ to c:\ ?

my config is like below

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "/mnt/c/Users/xx/Project/a/run",
            "args": [],
            "stopAtEntry": true,
            "cwd": "/mnt/c/Users/xx/Project/a",
            "externalConsole": true,
            "pipeTransport": {
                "debuggerPath": "/usr/bin/gdb",
                "pipeProgram": "C:\\Windows\\sysnative\\bash.exe",
                "pipeArgs": ["-c"],
                "pipeCwd": ""
            },
            "windows": {
                "MIMode": "gdb",
                "setupCommands": [
                    {
                        "description": "Enable pretty-printing for gdb",
                        "text": "-enable-pretty-printing",
                        "ignoreFailures": true
                    }
                ]
            },
            "sourceFileMap": {
                "/mnt/z": "z:\\"
            }
        }
    ]
}

cusr on 8 Dec 2017

@cusr you need to setup your "sourceFileMap". I noticed you have it converting paths that are "/mnt/z" to "z:\\". I think you want "/mnt/c": "c:\\" instead ?

pieandcakes on 8 Dec 2017

@pieandcakes Thank you very much!! Change the 'sourceFileMap' property just solve my problem.

cusr on 14 Dec 2017

👍1

I can launch bash when debugging bash on Windows! But how can I input in the debug console? Or can I use a extend Debug terminal like vs2017 in vscode?

GMHDBJD on 2 Jan 2018

@GMHDBJD Please use "externalConsole": true for an external console. It will be a separate window outside of VS Code.

pieandcakes on 2 Jan 2018

I did, but still no window

GMHDBJD on 3 Jan 2018

👍1

@pieandcakes I am having the same problem mentioned by @GMHDBJD . "externalConsole" is set to be true but no window appears.

My config is like below


{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [

        {
            "name": "gdb_WSL",
            "type": "cppdbg",
            "request": "launch",
            "program": "/mnt/d/WSLFiles/cpp/a.out",
            "args": ["-fThreading"],
            "stopAtEntry": false,
            "cwd": "/mnt/d/WSLFiles/cpp",
            "externalConsole": true,
            "windows": {
                "MIMode": "gdb",
                "setupCommands": [
                    {
                        "description": "Enable pretty-printing for gdb",
                        "text": "-enable-pretty-printing",
                        "ignoreFailures": true
                    }
                ]
            },
            "pipeTransport": {
                "pipeCwd": "",
                "pipeProgram": "c:\\windows\\sysnative\\bash.exe",
                "pipeArgs": ["-c"],
                "debuggerPath": "/usr/bin/gdb"
            },
            "sourceFileMap": {
                "/mnt/d": "d:\\"
            }
        }
    ]
}

ghost on 17 Mar 2018

@JCTian Does debugging start? or does it look like it is waiting? If it is waiting, then this is a WSL issue that has been reported and is fixed in an insiders Windows build. Unfortunately it doesn't affect everyone and isn't something we can fix.

pieandcakes on 19 Mar 2018

@pieandcakes I think the program starts debugging and it recognizes the breakpoint I set in the program. I also tried to debug a simple program with no input from cin and it works fine, expect that there is no console appears.

ghost on 20 Mar 2018

@pieandcakes My problem is shown as below:
.
This is my config:

// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "name": "(gdb) Launch",
      "type": "cppdbg",
      "request": "launch",
      "program": "/mnt/c/Users/LTT/AppData/Local/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/home/young666/Ass/DSA172A01-master/dsa172a1",
      "args": [
        "req.txt",
        "vData.dat"
      ],
      "stopAtEntry": false,
      "cwd": "/mnt/c/Users/LTT/AppData/Local/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/home/young666/Ass/DSA172A01-master/",
      "environment": [],
      "externalConsole": true,
      "windows": {
        "MIMode": "gdb",
        "setupCommands": [
          {
            "description": "Enable pretty-printing for gdb",
            "text": "-enable-pretty-printing",
            "ignoreFailures": true
          }
        ]
      },
      "pipeTransport": {
        "pipeCwd": "/",
        "pipeProgram": "c:\\windows\\system32\\bash.exe",
        "pipeArgs": [
          "-c"
        ],
        "debuggerPath": "/usr/bin/gdb"
      },
      "sourceFileMap": {
        "/mnt/c": "C:\\"
      }
    }
  ]

Thanks in advance 😄

young666 on 24 Jul 2018

@young666 Your error tells you whats wrong. It says Permission Denied. Make sure you have the casing correct and you have the correct permissions to the file.

pieandcakes on 24 Jul 2018

I think I hit a related issue: the debugging would start and finish fine but not stop and the breakpoints. I have set a few breakpoints, but they were ignored saying "module containing this breakpoint has not yet loaded..."

In the mean time, if I just run gdb in the shell and set break points there, it would work fine. My launch.json is as follows:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "/mnt/e/libmesh/with_vtk/examples/miscellaneous/ex12-test/example-dbg",
            "args": ["-pc_type", "jacobi", "-ksp_type", "cg"],
            "stopAtEntry": false,
            "cwd": "/mnt/e/libmesh/with_vtk/examples/miscellaneous/ex12-test",
            "environment": [],
            "externalConsole": true,
            "MIMode": "gdb",
            "miDebuggerPath": "usr/bin/gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
            "pipeTransport": {
                "pipeCwd": "",
                "pipeProgram": "C:\\Windows\\Sysnative\\bash.exe",
                "pipeArgs": ["-c"],
                "debuggerPath": "/usr/bin/gdb"
            },
            "sourceFileMap": {
                "/mnt/e": "e:\\"
            }
        }
    ]
}

Could anyone please share a hint?

yw5aj on 23 Oct 2018

@yw5aj Can you add logging and tell me what it says when it tries to set the breakpoint? At first glance, my assumption is that you didn't compile with symbols (-g compilation flag), but I will need more information.

pieandcakes on 23 Oct 2018

@pieandcakes You're totally right! Sorry about bugging with an error on my end. After adding symbols during compilation everything works fine.

yw5aj on 23 Oct 2018

For anyone that has similar issue that is on Windows 10 Pro. Version 1809.
If you have WSL enabled and installed your distro. and you can do a whereis command for bash , I modified my launch config slightly to following and it works

"pipeTransport": {
"pipeCwd": "",
"pipeProgram": "bash.exe",
"pipeArgs": ["-c"],
"debuggerPath": "/usr/bin/gdb"
},

sivum on 24 Jun 2019

👍7 ❤1

@sivum This worked perfectly for me. Thanks!

seanheinrichs on 1 Oct 2019

👍1

The configuration to support debugging WSL without the vscode-wsl extension are also located here.

pieandcakes on 2 Oct 2019

hi, there is a problem with input during debugging, the debugging console does not allow you to enter anything, and no other window opens
launch.json

{ 
    "version": "0.2.0",
    "configurations": [
        {
            "name": "g++ debug active file",
            "type": "cppdbg",
            "request": "launch",
            "program": "${fileDirname}/${fileBasenameNoExtension}.out",
            "args": [],
            "stopAtEntry": true,
            "cwd": "${fileDirname}",
            "environment": [],
            "externalConsole": true,
            "windows": {
                "MIMode": "gdb",
                "miDebuggerPath": "/usr/bin/gdb",
                "setupCommands": [
                    {
                        "description": "Enable pretty-printing for gdb",
                        "text": "-enable-pretty-printing",
                        "ignoreFailures": true
                    }
                ],
            },
            "preLaunchTask": "g++ build active file",
            "pipeTransport": {
                "pipeCwd": "",
                "pipeProgram": "bash.exe",
                "pipeArgs": [
                    "-c"
                ],
                "debuggerPath": "/usr/bin/gdb"
            },
            "sourceFileMap": {
                "/mnt/c": "${env:systemdrive}/",
                "/usr": "C:\\Users\\AdminSystem\\AppData\\Local\\Packages\\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\\LocalState\\rootfs\\usr\\"
            }
        }
    ]
}

laicore on 15 Nov 2019

For anyone that has similar issue that is on Windows 10 Pro. Version 1809.
If you have WSL enabled and installed your distro. and you can do a whereis command for bash , I modified my launch config slightly to following and it works

"pipeTransport": {
"pipeCwd": "",
"pipeProgram": "bash.exe",
"pipeArgs": ["-c"],
"debuggerPath": "/usr/bin/gdb"
},

very good!!!!!!!!it's works for me!!!!!!

DeaglePC on 17 Nov 2019

just set "pipeProgram": "bash.exe", not "pipeProgram": "C:\\Windows\\Sysnative\\bash.exe",

DeaglePC on 17 Nov 2019

Vscode-cpptools: Launch bash failed when debugging bash on Windows!

Most helpful comment

All 79 comments

Related issues