[Windows][Visual C++] Debugger hangs after launch

[floooh]

Hello, I'm trying to integrate my own cmake build wrapper with the C/C++ extension (https://github.com/floooh/fips), this calls "cmake --build" to build executable targets (which on Windows calls the Visual Studio build system). I have the Visual Studio 2015 Community Edition installed which provides the compiler.

When trying to debug the executable targets which have been built like this, I get the message:

--------------------------------------------------------------------------------
You may only use the C/C++ Extension for Visual Studio Code with Visual Studio
Code, Visual Studio or Xamarin Studio software to help you develop and test your
applications.
--------------------------------------------------------------------------------

...and the debugger appears to hang. The launch.json config looks good to me (the executable path is alright, the executable exists at that location (along with an .ilk and .pdb file), and the executable is also working when starting it manually, also if I intentionally put a non-existing exe into the launch.json config I explicitly get an error message about a missing file, so I guess it's not just a simple typo.

One launch.json entry looks like this (I generate the launch.json and tasks.json files from information provided by cmake):

  {
   "name":"Triangle",
   "type":"cppvsdbg",
   "request":"launch",
   "program":"C:/projects/fips-deploy/oryol/win64-vscode-debug/Triangle.exe",
   "stopAtEntry":true,
   "cwd":"C:/projects/fips-deploy/oryol/win64-vscode-debug",
   "environment":[],
   "externalConsole":false
  },

What am I doing wrong? Is there a way to get better logging output or is there another way to get to the bottom of the problem?

Debugging works fine on Linux (via gdb) and OSX (via lldb), only Windows is causing me trouble :)

Thanks!

[floooh]

PS: I should also mention that executables are built into a separate output directory, outside of the usual Visual Studio or cmake build directories. So if the debug adapter tries to look for typical Visual Studio files (like .vcxproj or .sln) it will not find them if it starts walking up the directory hierarchy from the executables (I'm assuming here that you are trying to find out if the executables have been built with VS tools by finding associated build files, complete guess if this is really the case if course)

[pieandcakes]

@floooh the debug adapter is expecting the code files to be in the same space as listed in the .pdb files. If you enable `"logging": { "engineLogging": true } do you see that it is running? Also, is the pause button enabled in the debug toolbar at the top?

[floooh]

Thanks for the reply. I can open and debug the executable in standard Visual Studio, so I think the PDB contains the right paths to the sources.

Enabling logging doesn't seem to help (see screenshot). The pause button is enabled, but pressing it, or the restart button doesn't do anything. Pressing the red stop button makes the debug button overlay disappear, but other then that nothing else of interest happens.

Here's a screenshot what I'm seeing (not much unfortunately, even with the logging enabled):

When I'm debugging on OSX (lldb) or Linux (gdb), VSCode is in the same state as above for one or two seconds, but then the source code with the entry function is loaded, the debugger stops at the entry, the paused button changes to a green arrow and the other step buttons are enabled.

Is the warning I'm seeing in the debugger console normal, or does the debugger think that I haven't created the executable with Visual Studio?

[pieandcakes]

@floooh Sorry. I gave you the wrong tag for logging. It should be "logging": { "trace": true }.

Its interesting that its just sitting there and not pausing. I'd be interested to see what the log shows.

The warning is for licensing to state the Visual C++ debugger can only be used with the supported products.

[floooh]

This is the output I'm seeing with tracing on:

--------------------------------------------------------------------------------
You may only use the C/C++ Extension for Visual Studio Code with Visual Studio
Code, Visual Studio or Xamarin Studio software to help you develop and test your
applications.
--------------------------------------------------------------------------------
<- (Event) {"seq":2,"type":"event","event":"initialized"}
<- (Response) {"seq":4,"type":"response","request_seq":2,"success":true,"command":"launch"}
-> (Request) {"command":"setBreakpoints","arguments":{"source":{"path":"c:\\projects\\oryol\\code\\Samples\\Triangle\\Triangle.cc","name":"Triangle.cc"},"lines":[39,26,20],"breakpoints":[{"line":39},{"line":26},{"line":20}],"sourceModified":false},"type":"request","seq":3}
<- (Response) {"seq":7,"type":"response","request_seq":3,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":1,"verified":false,"message":"The breakpoint is pending and will be resolved when debugging starts."},{"id":2,"verified":false,"message":"The breakpoint is pending and will be resolved when debugging starts."},{"id":3,"verified":false,"message":"The breakpoint is pending and will be resolved when debugging starts."}]}}
-> (Request) {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":4}
<- (Response) {"seq":10,"type":"response","request_seq":4,"success":true,"command":"setFunctionBreakpoints","body":{"breakpoints":[]}}
-> (Request) {"command":"setExceptionBreakpoints","arguments":{"filters":[]},"type":"request","seq":5}

...that's all, nothing coming after that setExceptionBreakpoints.

And I managed to debug a separate standard Hello World program (Win32 Console Application) compiled in Visual Studio 2015, the first few lines logging lines look slightly different (there's no setExceptionBreakpoint cmd as far as I can see):

<- (Event) {"seq":2,"type":"event","event":"initialized"}
<- (Response) {"seq":4,"type":"response","request_seq":2,"success":true,"command":"launch"}
-> (Request) {"command":"setBreakpoints","arguments":{"source":{"path":"c:\\Users\\floh\\Documents\\Visual Studio 2015\\Projects\\ConsoleApplication1\\ConsoleApplication1\\ConsoleApplication1.cpp","name":"ConsoleApplication1.cpp"},"lines":[9],"breakpoints":[{"line":9}],"sourceModified":false},"type":"request","seq":3}
<- (Response) {"seq":7,"type":"response","request_seq":3,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"id":1,"verified":false,"message":"The breakpoint is pending and will be resolved when debugging starts."}]}}
-> (Request) {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":4}
<- (Response) {"seq":10,"type":"response","request_seq":4,"success":true,"command":"setFunctionBreakpoints","body":{"breakpoints":[]}}
-> (Request) {"command":"configurationDone","type":"request","seq":5}
<- (Event) {"seq":13,"type":"event","event":"output","body":{"category":"telemetry","output":"VS/Diagnostics/Debugger/clrdbg/ProcessCreate","data":{}}}
<- (Event) {"seq":15,"type":"event","event":"breakpoint","body":{"reason":"new","breakpoint":{"id":1,"verified":false,"message":"No symbols have been loaded for this document."}}}
<- (Event) {"seq":17,"type":"event","event":"output","body":{"category":"telemetry","output":"VS/Diagnostics/Debugger/Launch","data":{"VS.Diagnostics.Debugger.VisualizerFileUsed":false,"VS.Diagnostics.Debugger.SourceFileMappings":0,"VS.Diagnostics.Debugger.Launch.Duration":141,"VS.Diagnostics.Debugger.ImplementationName":"vsdbg","VS.Diagnostics.Debugger.AdapterId":"cppvsdbg","VS.Diagnostics.Debugger.EngineVersion":"15.0.26109.1 built by: PREVIEW.DBG1"}}}
...

...but since I have now a working and non-working case which I can compare I think this makes it easier for me to investigate why my own version isn't working...

[pieandcakes]

You may be running into: https://github.com/Microsoft/vscode-cpptools/issues/484 if you have accidently compiled against a version of Visual Studio 2017.

[floooh]

Further investigation: I'm definitely compiling against VS2015 (Community Edition). But the VSCode debugger seems to depend on the path where VSCode is started.

I have the following directory structure (it's a cmake out-of-source build, with another separate directory for the executables):

project:
  - .vscode
  - CMakeLists.txt
  - src...
build: (cmake-generated files)
  - project.sln
  - CMakeCache.txt
  - ...
deploy: (exe, pdb,):
  - project.exe
  - project.pdb

When I'm starting VSCode from inside project, debugging hangs, but when I start VSCode from the directory where the .sln file is located, debugging works with exactly the same launch.json file it works!

...it also works when I'm starting VSCode from the directory where the executable is located and create a launch.json in there.

...and it also seems to work from any other location in the filesystem (e.g. c:/temp). The problem only seems to happen when starting VSCode from the actual project directory (even when deleting all files in .vscode and creating a new launch.json manually).

I'm a bit baffled right now, I don't know why the project directory is special. I'll continue to investigate in the next few days. If I find the culprit I'll add more info to this ticket, unless it's some stupid error on my side that I'm currently not seeing.

Thanks again for the help!

[pieandcakes]

Ok thanks! Please let me know what you find. I'm wondering if the source in the PDB is more relative. I know VSCode has a notion of ${workspaceRoot} which is the folder which is opened in VSCode but I don't see anything in your launch.json that points to that.

[floooh]

Minor new piece of information: on my Windows7/VS2015-Professional-box at work everything works out of the box. My home config where the problem happens is Win10/VS2015-Community-Edition. Investigation intensifies...

[fpascutti]

I am also experiencing this issue: debugging hangs when run from the project directory but works from another directory.

I compared the ProcessMonitor logs focusing on clrdbg.exe.

I found out that for the freezing case, the last events are CreateFile, QueryBasicInformation and CloseFile on the debugged process. They have the following callstack:

20  libclrdbg.dll   CClrDbg::SetLaunchFile + 0x1f5  0xf0b8e55   %USERPROFILE%\.vscode\extensions\ms-vscode.cpptools-0.10.2\debugAdapters\vsdbg\bin\libclrdbg.dll
21  clrdbg.exe  clrdbg.exe + 0x24ea0    0x2a4ea0    %USERPROFILE%\.vscode\extensions\ms-vscode.cpptools-0.10.2\debugAdapters\vsdbg\bin\clrdbg.exe
22  clrdbg.exe  clrdbg.exe + 0x23fb1    0x2a3fb1    %USERPROFILE%\.vscode\extensions\ms-vscode.cpptools-0.10.2\debugAdapters\vsdbg\bin\clrdbg.exe
23  clrdbg.exe  clrdbg.exe + 0x8241 0x288241    %USERPROFILE%\.vscode\extensions\ms-vscode.cpptools-0.10.2\debugAdapters\vsdbg\bin\clrdbg.exe
24  clrdbg.exe  clrdbg.exe + 0x7e35 0x287e35    %USERPROFILE%\.vscode\extensions\ms-vscode.cpptools-0.10.2\debugAdapters\vsdbg\bin\clrdbg.exe
25  clrdbg.exe  clrdbg.exe + 0x6bc9 0x286bc9    %USERPROFILE%\.vscode\extensions\ms-vscode.cpptools-0.10.2\debugAdapters\vsdbg\bin\clrdbg.exe
26  clrdbg.exe  clrdbg.exe + 0x37040    0x2b7040    %USERPROFILE%\.vscode\extensions\ms-vscode.cpptools-0.10.2\debugAdapters\vsdbg\bin\clrdbg.exe

For the working case, the event following those ones is a Thread Create event with the following callstack:

14  KernelBase.dll  CreateRemoteThreadEx + 0x161    0x77034140  C:\Windows\SysWOW64\KernelBase.dll
15  kernel32.dll    CreateThreadStub + 0x20 0x76e53495  C:\Windows\SysWOW64\kernel32.dll
16  libclrdbg.dll   DllGetClassObject + 0x995   0xf0bdb31   %USERPROFILE%\.vscode\extensions\ms-vscode.cpptools-0.10.2\debugAdapters\vsdbg\bin\libclrdbg.dll
17  libclrdbg.dll   DllGetClassObject + 0x891   0xf0bda2d   %USERPROFILE%\.vscode\extensions\ms-vscode.cpptools-0.10.2\debugAdapters\vsdbg\bin\libclrdbg.dll
18  libclrdbg.dll   CClrDbg::LaunchProcess + 0x1db  0xf0b6cf1   %USERPROFILE%\.vscode\extensions\ms-vscode.cpptools-0.10.2\debugAdapters\vsdbg\bin\libclrdbg.dll
19  clrdbg.exe  clrdbg.exe + 0x24a78    0x2a4a78    %USERPROFILE%\.vscode\extensions\ms-vscode.cpptools-0.10.2\debugAdapters\vsdbg\bin\clrdbg.exe
20  clrdbg.exe  clrdbg.exe + 0x23f7a    0x2a3f7a    %USERPROFILE%\.vscode\extensions\ms-vscode.cpptools-0.10.2\debugAdapters\vsdbg\bin\clrdbg.exe
21  clrdbg.exe  clrdbg.exe + 0x8241 0x288241    %USERPROFILE%\.vscode\extensions\ms-vscode.cpptools-0.10.2\debugAdapters\vsdbg\bin\clrdbg.exe
22  clrdbg.exe  clrdbg.exe + 0x7e35 0x287e35    %USERPROFILE%\.vscode\extensions\ms-vscode.cpptools-0.10.2\debugAdapters\vsdbg\bin\clrdbg.exe
23  clrdbg.exe  clrdbg.exe + 0x6bc9 0x286bc9    %USERPROFILE%\.vscode\extensions\ms-vscode.cpptools-0.10.2\debugAdapters\vsdbg\bin\clrdbg.exe
24  clrdbg.exe  clrdbg.exe + 0x37040    0x2b7040    %USERPROFILE%\.vscode\extensions\ms-vscode.cpptools-0.10.2\debugAdapters\vsdbg\bin\clrdbg.exe

Unfortunately I do not have any symbols for clrdbg.exe or libclrdbg.dll. Hopefully it will help.

[fpascutti]

It seems that, if I let the debugger running (frozen), I eventually get an error message in Visual Studio Code:

Error Invalid target, create a target using the file-exec-and-args command.

[pieandcakes]

@fpascutti Can you enable "logging": { "trace": true } and send me your output? I'm interested to see if it isn't able to find the executable that you are trying to debug.

@floooh if you can send me the entire trace for a working and not working case, I'd appreciate it.

If either of you don't want to post it here, you can email me (email address is in my profile) and reference this issue.

[fpascutti]

Note that I just upgraded the extension to 0.10.3 but it does not seem to change anything.

Here are the traces for the freezing case:

--------------------------------------------------------------------------------
You may only use the C/C++ Extension for Visual Studio Code with Visual Studio
Code, Visual Studio or Xamarin Studio software to help you develop and test your
applications.
--------------------------------------------------------------------------------
<- (Event) {"seq":2,"type":"event","event":"initialized"}
<- (Response) {"seq":4,"type":"response","request_seq":2,"success":true,"command":"launch"}
-> (Request) {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":3}
<- (Response) {"seq":7,"type":"response","request_seq":3,"success":true,"command":"setFunctionBreakpoints","body":{"breakpoints":[]}}
-> (Request) {"command":"setExceptionBreakpoints","arguments":{"filters":["uncaught"]},"type":"request","seq":4}

And the following are the traces for a working case (initial ones):

--------------------------------------------------------------------------------
You may only use the C/C++ Extension for Visual Studio Code with Visual Studio
Code, Visual Studio or Xamarin Studio software to help you develop and test your
applications.
--------------------------------------------------------------------------------
<- (Event) {"seq":2,"type":"event","event":"initialized"}
<- (Response) {"seq":4,"type":"response","request_seq":2,"success":true,"command":"launch"}
-> (Request) {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":3}
<- (Response) {"seq":7,"type":"response","request_seq":3,"success":true,"command":"setFunctionBreakpoints","body":{"breakpoints":[]}}
-> (Request) {"command":"configurationDone","type":"request","seq":4}
<- (Event) {"seq":10,"type":"event","event":"output","body":{"category":"telemetry","output":"VS/Diagnostics/Debugger/clrdbg/ProcessCreate","data":{}}}
<- (Event) {"seq":12,"type":"event","event":"output","body":{"category":"telemetry","output":"VS/Diagnostics/Debugger/Launch","data":{"VS.Diagnostics.Debugger.VisualizerFileUsed":false,"VS.Diagnostics.Debugger.SourceFileMappings":0,"VS.Diagnostics.Debugger.Launch.Duration":78,"VS.Diagnostics.Debugger.ImplementationName":"vsdbg","VS.Diagnostics.Debugger.AdapterId":"cppvsdbg","VS.Diagnostics.Debugger.EngineVersion":"15.0.26109.1 built by: PREVIEW.DBG1"}}}
<- (Response) {"seq":14,"type":"response","request_seq":4,"success":true,"command":"configurationDone"}
-> (Request) {"command":"threads","type":"request","seq":5}
<- (Response) {"seq":17,"type":"response","request_seq":5,"success":true,"command":"threads","body":{"threads":[]}}

[fpascutti]

While testing and trying to gather some useful logs I managed to have it work and I believe I found the root cause of the issue.

I made it work by deleting all files from the %APPDATA%\Code\Local Storage directory (*.localstorage and *.localstorage-journal files).

I believe that the root cause of the issue is that VSCode tries to set exception-related breakpoints that are not supported by the C++ debugger.

These kind of breakpoints (All Exceptions and Uncaught Exceptions) are automatically added when launching another debugging configuration of type node. If they are available (even disabled) then VSCode tries to set them even for the cppvsdbg debugger and this causes the freeze.

By clearing the content of my %APPDATA%\Code directory I cleared the breakpoint cache for my project directory. This means that the exception-related breakpoints are not available and I can successfully launch the cppvsdbg debugger. However they get added again as soon as I launch the node debugger.

[fpascutti]

I confirmed that the root cause (in my case) are the Exception Breakpoints set by TypeScript/JavaScript debugging. If there are any the debugger freezes. If I clear them from the %APPDATA%\Code\Local Storage\file__0.localstorage database then no freeze occurs.

I created a small script that clears the debug.exceptionbreakpoint entry for my project (from the Local Storage SQLite database) and it fixes the issue (once I restart VSCode).

For information, here is the data created by VSCode in the debug.exceptionbreakpoint:

[
  {
    "filter": "all",
    "label": "All Exceptions",
    "enabled": false,
    "id": "f2067640-b60e-4770-bc6d-1f56d29ecbbb"
  },
  {
    "filter": "uncaught",
    "label": "Uncaught Exceptions",
    "enabled": true,
    "id": "6b232c06-da77-45a1-a63a-8e96a5c041dc"
  }
]

[floooh]

I can confirm the behaviour reported by @fpascutti , deleting the *localstorage files makes debugging work for me. I guess it worked on my Win7 machine because I never did any Javascript debugging there.

[pieandcakes]

@floooh @fpascutti Thanks for the troubleshooting. I'll see if I can reproduce this on my side. We shouldn't be hanging if we get parameters we don't know about. We should just be ignoring them and continuing.

Just so I understand, if I create a JS project, set the breakpoint settings and then open a C++ project and debug it, it will reproduce?

[floooh]

Just so I understand, if I create a JS project, set the breakpoint settings and then open a C++ project and debug it, it will reproduce?

@pieandcakes at least for me it doesn't seem to be that simple :/ debugging a small hello-world JS file via node and then going back to C++ debugging does not bring the startup hanging back. may be @fpascutti has a better repro.

[fpascutti]

@pieandcakes, I believe you can reproduce with my gluino project.

1. clone the repository
2. launch npm update --dev
3. open the folder in VSCode
4. launch the test task (to make sure everything is built)
5. debug the test:typescript configuration
6. debug the test:c++.win configuration => Freeze

At least that is how I could reproduce the freeze on another machine.

[eshadd]

Running into same problem but neither "logging": {"trace": true}, nor "logging": {"engineLogging": true}, give me any information in the DEBUG CONSOLE. The only thing that happens when I launch the debugger is that a an LXTerminal window opens up and all the debug controls are dimmed out except Stop. "stopAtEntry": true, does nothing.

Please help.

task.json:

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

launch.json:

{
    // 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": "${fileDirname}/${fileBasenameNoExtension}.out",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": true,
            "MIMode": "gdb",
            "preLaunchTask": "gpp_build",
            "logging": {"engineLogging": true},
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ]
        }
    ]
}

c_cpp_properties.json:

{
    "configurations": [
        {
            "name": "Linux",
            "includePath": [
                "${workspaceFolder}/**", 
                "/usr/include/c++/4.8",
                "/usr/include/x86_64-linux-gnu/c++/4.8",
                "/usr/include/c++/4.8/backward",
                "/usr/lib/gcc/x86_64-linux-gnu/4.8/include",
                "/usr/local/include",
                "/usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed",
                "/usr/include/x86_64-linux-gnu",
                "/usr/include"
            ],
            "defines": [],
            "compilerPath": "/usr/bin/gcc",
            "cStandard": "c11",
            "cppStandard": "c++14",
            "intelliSenseMode": "clang-x64"
        }
    ],
    "version": 4
}

screenshot:

[pieandcakes]

@eshadd The issue you have is not related to Visual C++. you are using GNU C++. Please check and see if your task is completing and the .out file exists. If it is there, please open a new issue.

[eshadd]

The task is completing. VS Code compiles and creates the .out (see above screenshot). I went ahead and took out "externalConsole": true and it works fine. I'm OK with this but still am not sure why the launched terminal window didn't have the program running.

[pieandcakes]

@eshadd Sounds like a compatibility with the terminal app you are using. If you have clear repro steps including distro and packages installed, please file another issue.

[focusunsink]

Try "code --verbose"