Vs code c debug windows

After you have set up the basics of your debugging environment as specified in the configuration tutorials for each target compiler/platform, you can learn more details about debugging C/C++ in this section.

Visual Studio Code supports the following debuggers for C/C++ depending on the operating system you are using:

• Linux: GDB
• macOS: LLDB or GDB
• Windows: the Visual Studio Windows Debugger or GDB (using Cygwin or MinGW)

Windows debugging with GDB

You can debug Windows applications created using Cygwin or MinGW by using VS Code. To use Cygwin or MinGW debugging features, the debugger path must be set manually in the launch configuration (launch.json). To debug your Cygwin or MinGW application, add the miDebuggerPath property and set its value to the location of the corresponding gdb.exe for your Cygwin or MinGW environment.

For example:

    "miDebuggerPath": "c:\\mingw\\bin\\gdb.exe"

Cygwin/MinGW debugging on Windows supports both attach and launch debugging scenarios.

To learn more, see Configure C/C++ debugging.

If you are debugging with GDB on Windows, see Windows Debugging with MinGW64.

Conditional breakpoints

Conditional breakpoints enable you to break execution on a particular line of code only when the value of the condition is true. To set a conditional breakpoint, right-click on an existing breakpoint and select Edit Breakpoint. This opens a small peek window where you can enter the condition that must evaluate to true in order for the breakpoint to be hit during debugging.

In the editor, conditional breakpoints are indicated by a breakpoint symbol that has a black equals sign inside of it. You can place the cursor over a conditional breakpoint to show its condition.

Function breakpoints

Function breakpoints enable you to break execution at the beginning of a function instead of on a particular line of code. To set a function breakpoint, on the Run view right-click inside the Breakpoints section, then choose Add Function Breakpoint and enter the name of the function on which you want to break execution.

Expression evaluation

VS Code supports expression evaluation in several contexts:

• You can type an expression into the Watch section of the Run view and it will be evaluated each time a breakpoint is hit.
• You can type an expression into the Debug Console and it will be evaluated only once.
• You can evaluate any expression that appears in your code while you’re stopped at a breakpoint.

Expressions in the Watch section take effect in the application being debugged; an expression that modifies the value of a variable will modify that variable for the duration of the program.

Multi-threaded debugging

The C/C++ extension for VS Code has the ability to debug multi-threaded programs. All threads and their call stacks appear in the Call Stack section:

Memory dump debugging

The C/C++ extension for VS Code also has the ability to debug memory dumps. To debug a memory dump, open your launch.json file and add the coreDumpPath (for GDB or LLDB) or dumpPath (for the Visual Studio Windows Debugger) property to the C++ Launch configuration, set its value to be a string containing the path to the memory dump. This will even work for x86 programs being debugged on an x64 machine.

Additional symbols

If there are additional directories where the debugger can find symbol files (for example, .pdb files for the Visual Studio Windows Debugger), they can be specified by adding the additionalSOLibSearchPath (for GDB or LLDB) or symbolSearchPath (for the Visual Studio Windows Debugger).

For example:

    "additionalSOLibSearchPath": "/path/to/symbols;/another/path/to/symbols"

or

    "symbolSearchPath": "C:\\path\\to\\symbols;C:\\another\\path\\to\\symbols"

Locate source files

The source file location can be changed if the source files are not located in the compilation location. This is done by simple replacement pairs added in the sourceFileMap section. The first match in this list will be used.

For example:

"sourceFileMap": {
    "/build/gcc-4.8-fNUjSI/gcc-4.8-4.8.4/build/i686-linux-gnu/libstdc++-v3/include/i686-linux-gnu": "/usr/include/i686-linux-gnu/c++/4.8",
    "/build/gcc-4.8-fNUjSI/gcc-4.8-4.8.4/build/i686-linux-gnu/libstdc++-v3/include": "/usr/include/c++/4.8"
}

GDB, LLDB, and LLDB-MI Commands (GDB/LLDB)

For the C++ (GDB/LLDB) debugging environment, you can execute GDB, LLDB and LLDB-MI commands directly through the debug console with the -exec command, but be careful, executing commands directly in the debug console is untested and might crash VS Code in some cases.

Other debugging features

• Unconditional breakpoints
• Watch window
• Call stack
• Stepping

For more information on debugging with VS Code, see this introduction to debugging in VS Code.

For additional ways to configure the launch.json file so that you can debug your C/C++ app, see Configure C/C++ debugging.

Natvis framework

You create custom views of C++ object in the debugger with the Natvis framework. You can read the Custom views for native objects topic for details on using Natvis with the C/C++ extension.

Debug remotely

For information about attaching to a remote process, such as debugging a process in a Docker container, see Pipe transport.

Debug the debugger

If you are experiencing a debugging problem with the extension that we can’t diagnose based on information in your issue report, we might ask you to enable logging and send us your logs. See Enable logging for the debug adapter to learn how to get C/C++ extension logs.

Known limitations

Symbols and code navigation

All platforms:

• Because the extension doesn’t parse function bodies, Peek Definition and Go to Definition don’t work for symbols defined inside the body of a function.

Debugging

Windows:

• GDB on Cygwin and MinGW cannot break a running process. To set a breakpoint when the application is running (not stopped under the debugger), or to pause the application being debugged, press Ctrl-C in the application’s terminal.
• GDB on Cygwin cannot open core dumps.

Linux:

• You may see an error saying: ptrace: Operation not permitted. This is due to GDB needing elevated permissions in order to attach to a process. This can be solved using the solutions below:

  1. When using attach to process, you need to provide your password before the debugging session can begin.

  2. To disable this error temporarily, use the following command:

     echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

  3. To remove the error permanently, add a file called 10-ptrace.conf to /etc/sysctl.d/ and add the following kernel.yama.ptrace_scope = 0.

macOS:

• LLDB:
  • When debugging with LLDB, if the Terminal window is closed while in break mode, debugging does not stop. Debugging can be stopped by pressing the Stop button.
  • When debugging is stopped the Terminal window is not closed.
• GDB:
  • Additional manual install steps are required to use GDB on macOS. See Manual Installation of GDB for OS X in the README.
  • When attaching to a process with GDB, the application being debugged cannot be interrupted. GDB will only bind breakpoints set while the application is not running (either before attaching to the application, or while the application is in a stopped state). This is due to a bug in GDB.
  • Core dumps cannot be loaded when debugging with GDB because GDB does not support the core dump format used in macOS.
  • When attached to a process with GDB, break-all will end the process.

Next steps

Read on to find out about:

• Configure VS Code for Windows Subsystem for Linux
• Configure VS Code for Mingw-w64 and GCC
• Configure VS Code for macOS
• Configure C/C++ debugging — Learn about additional debugger configuration options.
• Basic Editing — Learn about the powerful Visual Studio Code editor.
• Code Navigation — Move quickly through your source code.
• Tasks — use tasks to build your project and more.
• Debugging — find out about the Visual Studio Code debugger.

If you have any other questions or run into any issues, please file an issue on GitHub.

5/21/2020

You can debug C# applications in Visual Studio Code using the Microsoft C# extension.

Run and Debug

The C# extension along with C# Dev Kit provides multiple ways to run and debug your C# application.

To run and debug without C# Dev Kit, see Microsoft C# extension’s GitHub page for documentation.

Debug with F5

With the C# Dev Kit extension installed and no debug configurations available to select in the Debug view, you can start debugging your project by having a .cs file opened and then pressing F5. The debugger will automatically find your project and start debugging. If you have multiple projects, it will prompt for which project you would like to start debugging.

You can also start a debugging session from the Run and Debug view from the side bar of VS Code. See more at Debugging in VS Code.

Debug with Solution Explorer

With the C# Dev Kit extension installed, there is a Debug context menu when you right-click on your project in the Solution Explorer.

There are three options:

• Start New Instance — This starts your project with a debugger attached.
• Start without Debugging — This runs your project without a debugger attached.
• Step into New Instance — This starts your project with a debugger attached but stops at the entrypoint of your code.

Debug with Command Palette

With the C# Dev Kit extension installed, you can also start debugging from the Command Palette ⇧⌘P (Windows, Linux Ctrl+Shift+P) by using the Debug: Select and Start Debugging command.

Note: This adds a launch configuration entry to your debug dropdown list.

Debug with dynamic (in-memory) launch configurations

With the C# Dev Kit extension installed, you can create dynamic launch configurations. How you create them depends if your project has an existing launch.json file.

Existing launch.json

If you have an existing launch.json, you can go to the Debug view, select the dropdown, and select the C# option. This should give you a selection of launch targets that you can add to your dropdown list. After selecting, you can hit F5 or Start Debugging with the newly generated configuration.

No launch.json

If you do not have a launch.json in your project, you can add and access these dynamic configurations in the Show all automatic debug configurations in the Debug view.

Removing dynamic (in-memory) launch configurations

You can remove the generated configurations with Command Palette ⇧⌘P (Windows, Linux Ctrl+Shift+P) and using the command Debug: Select and Start Debugging.

In the dropdown, it lists all your existing debug configurations. If you hover over the dynamic configurations, a clickable trashcan icon appears on the right. You can select that icon to remove the dynamic configuration.

Debug with launch.json

If you are using the C# Dev Kit, we recommend not using this option. However, if you have the need to modify the debug configuration directly, see Configuring launch.json for C# debugging.

Attaching to a process

You can attach to a C# process using with the Command Palette ⇧⌘P (Windows, Linux Ctrl+Shift+P) and running the Debug: Attach to a .NET 5+ or .NET Core process command.

Configuration options

There are many options and settings available to configure the debugger. You can use launchSettings.json, VS Code User Settings to modify your debug options, or directly modify your launch.json.

launchSettings.json

If you have launchSettings.json from Visual Studio, you should see your profiles listed using Run from F5 or Run from Command Palette.

Refer to Configuring C# debugging for more details.

User settings

If you have settings that you wish to change while using the C# debugger, you can find these options under File > Preferences > Settings (⌘, (Windows, Linux Ctrl+,)) and searching for these options.

• csharp.debug.stopAtEntry — If true, the debugger should stop at the entry point of the target. This option defaults to false.
• csharp.debug.console — When launching console projects, indicates which console the target program should be launched into. Note: This option is only used for the ‘dotnet’ debug configuration type.
  • internalConsole — Output to the VS Code Debug Console. This doesn’t support reading console input (ex:Console.ReadLine).
  • integratedTerminal — VS Code’s integrated terminal.
  • externalTerminal — External terminal that can be configured via user settings.
• csharp.debug.sourceFileMap — Maps build-time paths to local source locations. All instances of build-time path will be replaced with the local source path.
    Example:
      {\"<build-path>\":\"<local-source-path>\"}
• csharp.debug.justMyCode — When enabled (the default), the debugger only displays and steps into user code («My Code»), ignoring system code and other code that is optimized or that does not have debugging symbols. More information.
• csharp.debug.requireExactSource — Flag to require current source code to match the pdb. This option defaults to true.
• csharp.debug.enableStepFiltering — Flag to enable stepping over Properties and Operators. This option defaults to true.
• csharp.debug.logging.exceptions — Flag to determine whether exception messages should be logged to the output window. This option defaults to true.
• csharp.debug.logging.moduleLoad — Flag to determine whether module load events should be logged to the output window. This option defaults to true.
• csharp.debug.logging.programOutput — Flag to determine whether program output should be logged to the output window when not using an external console. This option defaults to true.
• csharp.debug.logging.engineLogging — Flag to determine whether diagnostic engine logs should be logged to the output window. This option defaults to false.
• csharp.debug.logging.browserStdOut — Flag to determine if stdout text from the launching the web browser should be logged to the output window. This option defaults to true.
• csharp.debug.logging.elapsedTiming — If true, engine logging includes adapterElapsedTime and engineElapsedTime properties to indicate the amount of time, in microseconds, that a request took. This option defaults to false.
• csharp.debug.logging.threadExit — Controls if a message is logged when a thread in the target process exits. This option defaults to false.
• csharp.debug.logging.processExit — Controls if a message is logged when the target process exits, or debugging is stopped. This option defaults to true.
• csharp.debug.suppressJITOptimizations — If true, when an optimized module (.dll compiled in the Release configuration) loads in the target process, the debugger asks the Just-In-Time compiler to generate code with optimizations disabled. More information
• csharp.debug.symbolOptions.searchPaths — Array of symbol server URLs (example: http://MyExampleSymbolServer) or directories (example: /build/symbols) to search for .pdb files. These directories will be searched in addition to the default locations next to the module and the path where the pdb was originally dropped to.
• csharp.debug.symbolOptions.searchMicrosoftSymbolServer — If true the Microsoft Symbol server (https://msdl.microsoft.com/download/symbols) is added to the symbols search path. If unspecified, this option defaults to false.
• csharp.debug.symbolOptions.searchNuGetOrgSymbolServer — If true the NuGet.org symbol server (https://symbols.nuget.org/download/symbols) is added to the symbols search path. If unspecified, this option defaults to false.
• csharp.debug.symbolOptions.cachePath — Directory where symbols downloaded from symbol servers should be cached. If unspecified, on Windows the debugger defaults to %TEMP%\\SymbolCache, and on Linux and macOS the debugger defaults to ~/.dotnet/symbolcache.
  *- csharp.debug.symbolOptions.moduleFilter.mode — Controls which of the two basic operating modes the module filter operates in.
  • loadAllButExcluded — Load symbols for all modules unless the module is in the excludedModules array.
  • loadOnlyIncluded — Do not attempt to load symbols for ANY module unless it is in the includedModules array, or it is included through the includeSymbolsNextToModules setting.
• csharp.debug.symbolOptions.moduleFilter.excludedModules — Array of modules that the debugger should NOT load symbols for. Wildcards (example: MyCompany.*.dll) are supported. This property is ignored unless mode is set to loadAllButExcluded.
• csharp.debug.symbolOptions.moduleFilter.includedModules — Array of modules that the debugger should load symbols for. Wildcards (example: MyCompany.*.dll) are supported. This property is ignored unless mode is set to loadOnlyIncluded.
• csharp.debug.symbolOptions.moduleFilter.includeSymbolsNextToModules — If true, for any module NOT in the includedModules array, the debugger will still check next to the module itself and the launching executable, but it will not check paths on the symbol search list. This option defaults to true.
  This property is ignored unless mode is set to loadOnlyIncluded
• csharp.debug.allowFastEvaluate — When true (the default state), the debugger will attempt faster evaluation by simulating execution of simple properties and methods.

Breakpoints

The C# Debugger supports various breakpoints, such as source line breakpoints, conditional breakpoints, and logpoints.

Breakpoint — conditional breakpoint

With the help of expression evaluation, the debugger also supports conditional breakpoint. You can set your breakpoint to break when expression evaluates to true.

Breakpoint — Logpoints

Logpoints (also known as Tracepoints in Visual Studio) allow you to send output to Debug Console without editing code. They’re different from breakpoints because they don’t stop the execution flow of your application.

To add a Logpoint, right-click in the far-left margin next to a line of code. Select Add Logpoint and type the message you want to log. Any expression between curly braces (‘{‘ and ‘}’) will be evaluated when the Logpoint is hit.

The following tokens are also supported in the log message:

Token	Description	Example Output
$FILEPOS	Current source file location	C:\sources\repos\Project\Program.cs:4
$FUNCTION	Current function name	Program.<Main>$
$ADDRESS	Current instruction	0x00007FFF83A54001
$TID	Thread ID	20668
$PID	Process ID	10028
$TNAME	Thread name	<No Thread Name>
$PNAME	Process name	C:\sources\repos\Project\bin\Debug\net7.0\console.exe
$CALLER	Calling function name	void console.dll!Program.Foo()
$CALLSTACK	Call stack	void console.dll!Program.Bar() void console.dll!Program.Foo() void console.dll!Program.<Main>$(string[] args) [External Code]
$TICK	Tick count (from Windows GetTickCount)	28194046
$HITCOUNT	Number of times this breakpoint has been hit	5

Expression evaluation

The debugger also lets you evaluate expressions in the WATCH window as well as the Debug Console.

Next steps

Read on to find out about:

• Debugging — Find out how to use the debugger in VS Code with your project for any language.

6/6/2023