Add support for "Just My Code" debugging

Visual Studio debugger supports skipping source files during Step In operations by reading the non-user code filters from *.natjmc and *.natstepfilter files under C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Packages\Debugger\Visualizers folder when Just My Code is enabled in VS settings. The debugger bundled with the VSCode extension comes with a similar folder, but there is no option to turn on the Just My Code option in the extension.

Related issues: #514 #3725

Hi,

I am a member of the Visual C++ compiler team and I use VSCode as my primary editor/debugging experience with the C++ extension. Due to the fact that our project involves a lot of std::variant visitor code, not having support for JMC is a real productivity blocker. Is there a possibility of adding priority to this feature?

Andrew Wang (@WardenGnaw)

It does not look like this is a priority issue which is a bummer because without JMC the debugging experience really sucks on those projects that are bigger than just simple "hello world" application.

Andrew Wang (@WardenGnaw) Is this just a matter of getting more people to vote on this issue?

Konstantin Kutsner (@kkutsner)

Konstantin Kutsner (@kkutsner)

Yes, that appears. Andrew Wang (@WardenGnaw) mentioned this here:
#6668 (comment)

Please vote on #5763 by adding a 👍 to help us prioritize our features.

Anyway, I voted. I am curious to know what threshold must be met for this to be prioritized. To Konstantin Kutsner (@kkutsner)'s point, debugging on any large project becomes clumsy rather quickly.

BradyDonovan

BradyDonovan

It looks like we may need a lot of votes: https://github.com/microsoft/vscode/issues/21839 (I pasted link as a code so this issue should not reference the other issue). That issue over 700 votes and still it is not on its way...

I'm curious, this extenstion has so many user installations, but it looks like no one really uses VSCode for debugging C++ code...

Konstantin Kutsner (@kkutsner)

Konstantin Kutsner (@kkutsner) The vote count of the VS Code issue you referenced is not relevant, since it's managed by another team and they have a larger user base (all of VS Code instead of just C/C++ users). Our highest upvoted issue is #206 .

Lots of people use our extension for debugging C++. You can use Go to Definition and set a breakpoint in the definition you want to step into to get around the issue.

Sean McManus (@sean-mcmanus)

Sean McManus (@sean-mcmanus)

Konstantin Kutsner (@kkutsner) The vote count of the VS Code issue you referenced is not relevant, since it's managed by another team and they have a larger user base (all of VS Code instead of just C/C++ users). Our highest upvoted issue is #206 .

Fair point! Sorry for mentioning not quite relevant issue.

Lots of people use our extension for debugging C++. You can use Go to Definition and set a breakpoint in the definition you want to step into to get around the issue.

Yeah, that workaround may work sometimes, but such workaround is a productivity killer like Cameron DaCamara (@cdacamar) mentioned already. Let's consider a test code below:

I need to step through lines 46 to 52 and I want to step into line 49 for every element. In VisualStudio, I only need 4+n keyboard clicks to do that, where n is the number of elements in the vector. With "Go to Definition" workaround that is a lot more, even for such artifical code example. It is because every time I need to "Step Into" I may need to do "go to definition" then put a breakpoint (or "Run to Cursor" that sets temprorary breakpoint automatically). Also, I need to put a breakpoint after the statement before doing "Step Into" in the case something goes wrong and I did the previous breakpoint on a wrong line. After all I need to cleanup any of those breakpoints...Those extra actions take additional time and patience and that is adding up quickly.

For your sample code, can't you just set a breakpoint on line 49? Go to Definition isn't needed because the definition is on line 49.

I agree that doing the Go to Definition and setting the breakpoint (or doing multiple step in/outs) is annoying, although with debugging our code base I haven't found it a productivity killer enough to switch to VS debugging. I think the intent initially was for VS to be the "premier" debugging experience (paid/licensed product) so they didn't want to move too many debugging features into VS Code, but I don't know how much that reasoning applies to this particular issues versus other factors, such as team resources (I don't work on the debugger).

For your sample code, can't you just set a breakpoint on line 49? Go to Definition isn't needed because the definition is on line 49.

Yep, I can.

I think the intent initially was for VS to be the "premier" debugging experience (paid/licensed product) so they didn't want to move too many debugging features into VS Code, but I don't know how much that reasoning applies to this particular issues versus other factors, such as team resources (I don't work on the debugger).

Every dev on our team has paid VS licenses. But I found that a lot of my workflows I can do using VSCode much faster: it is keyboard centric, minimalistic, mostly runs much faster than VS....

Interestingly, that Microsoft is releasing a standalone debugger application https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugging-using-windbg-preview that has even more features that VS can provide as a debugging experience, for example, use JS scripting to to script the debugger - mind blowing (Something similar that GDB also can do using Python for a while)!

For your sample code, can't you just set a breakpoint on line 49? Go to Definition isn't needed because the definition is on line 49.

I agree that doing the Go to Definition and setting the breakpoint (or doing multiple step in/outs) is annoying, although with debugging our code base I haven't found it a productivity killer enough to switch to VS debugging. I think the intent initially was for VS to be the "premier" debugging experience (paid/licensed product) so they didn't want to move too many debugging features into VS Code, but I don't know how much that reasoning applies to this particular issues versus other factors, such as team resources (I don't work on the debugger).

With smart pointers use everywhere, this is definitely a productivity killer!
There are trivial function calls everywhere.

std::shared_ptr<Image> image = std::make_shared<Image>(10, 20);
createNewImage(Size(image->width(), image->height()));

Step on line 2 will go into : shared_ptr::operator->(), image::width(), shared_tr::operator->(), image::height(), Size::Size(int, int). And then into createNewImage.

With Visual Studio's *.natstepfilter. All this will not happen.

I'm wondering if I should just switch to Visual Studio proper. Since vector-of-bool is not in charge of the extension anymore it seems its not really being developed anymore. My suspicion is also that VS Code is deprioritized to get people to move to Visual Studio.

maartennauta

maartennauta vector-of-bool worked on the CMake Tools extension -- our team is still developing that extension. This debugging issue is not related to the CMake Tools extension. Were you hitting some other issue?

Sean McManus (@sean-mcmanus)

Sean McManus (@sean-mcmanus) No, my mistake probably was to assume he also worked on the cpptools extension. It seems this is the issue im also hitting (just wanting to step through my own code in the project directory when debugging C++ in VS Code, ignoring std internals and boost libraries etc) and have voted accordingly. I guess a similar request applies to "stop on exception" where I would want to only stop on all exceptions in my own code, I dont know if that is a separate issue. I have not used Just-My-Code in Visual Studio in a while so I do not know if it provides that functionality for exceptions.

This is absolutely necessary. When debugging and stepping in/through my code I always end up stepping into a bunch of std code. It would be great to just step through and not have worry about code other than my own when debugging an issue

Please react to the top post with a +1 to vote on this feature.

How many votes do we need? This is such a productivity killer, I'm really surprised this isn't prioritized. The workaround works for simple cases, but C++ has a ton of hidden function calls everywhere so it's really annoying.

Nick (@quyykk)

Nick (@quyykk) I don't know exactly how many votes are needed, but more than 100 would help (there are 2 other debugger features with more up votes).

我不知道确切需要多少票，但超过 100 票会有所帮助（还有 2 个其他调试器功能具有更多的赞成票）。

There are now 101 tickets available. Will this feature be added?

Is there an alternative solution?

This is a practical feature, please add it

Voted: +1, closing: #11417

Debugging doesn't seem to be getting much attention.
There are a few outstanding issues:

/JMC support on Windows
Debugger driver llvm-mi memory leak on macOS
No support for debugging as root

Andrew Wang (@WardenGnaw)

I voted too. Andrew Wang (@WardenGnaw) How many more votes are needed? It's currently at 122, seems pretty substantial at this point. :)

Upvoted too. This is a must have feature.

Is there at least a janky sometimes-working proof of concept extension that does this to install?

If I add "justMyCode": true to the lauch.json, it shows me a warning, that justMyCode is not allowed, but it actually works with cppvsdbg.
Maybe not finalized yet, since if I step into the function it does nothing, I have to press F11 many times until it skips all external calls.

For gdb see suggested solution at the end #3725

As a workaround, once the debugger is attached, I can execute this command in the debugger:

-exec skip -gfile /usr/include/c++/11/bits/*.h

I figured out that I can get that to be automatically added if I put it into launch.json like this:

      "setupCommands": [
        {
          "description": "Enable skipping built-in libraries when single stepping code",
          "text": "-interpreter-exec console \"skip -gfi /usr/include/c++/11/bits/*.h\"",
          "ignoreFailures": true
        }
      ]

This feature would be incredibly helpful for C++ debugging in VSCode. It would be great if the dev team considered implementing it - skipping over standard library files would make the debugging process much less frustrating as we wouldn't have to manually step out each time a standard library function runs. Thanks for considering!

Navigation Menu

Repository navigation

Add support for "Just My Code" debugging #5763

10 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add support for "Just My Code" debugging #5763

Description

Activity

cdacamar commented on Dec 16, 2020

kkutsner commented on Feb 26, 2021

BradyDonovan commented on Mar 1, 2021

kkutsner commented on Mar 1, 2021

sean-mcmanus commented on Mar 1, 2021

kkutsner commented on Mar 1, 2021

sean-mcmanus commented on Mar 2, 2021

kkutsner commented on Mar 2, 2021

kingsimba commented on Apr 3, 2021

maartennauta commented on Oct 6, 2022

sean-mcmanus commented on Oct 6, 2022

maartennauta commented on Oct 6, 2022

Rhahkeem commented on Oct 8, 2022

10 remaining items

quyykk commented on Jan 5, 2023

sean-mcmanus commented on Jan 5, 2023

ChenLI00 commented on Jul 5, 2023

jing-pei commented on Aug 25, 2023

lowmee commented on Sep 1, 2023

Zingam commented on Sep 8, 2023

Zingam commented on Sep 8, 2023

cyraid commented on Jan 4, 2024

tonyriviere88 commented on Apr 30, 2024

ahcox commented on May 21, 2024

csorvagep commented on Jul 10, 2024

mrx23dot commented on Jul 11, 2024

StephenApptronik commented on Feb 13, 2025

arcanelab commented on Apr 17, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions