Site icon Tomato Soup

Prevent debugger from stepping into unwanted functions in Visual Studio

Bartlomiej Filipek

When you’re in a debugging session, sometimes the debugger can visit a lot of trivial functions or code from third-party libraries. In Visual Studio and also in Visual Assist, there are ways to filter out call stack events so that you can focus just on the critical code path.

Read on to find out how.

Background

As you may already know, step into, step over, and step out functions are essential while debugging. However, it would be very time consuming to visit all of the functions. Sometimes debugger might lead you to methods that are not important from your perspective.

Let’s see an example:

#include <iostream>
#include <string>

class Param {
public:
    Param(const std::string& str, int val) : mStr(str), mVal(val) { }

    std::string GetStrVal() const {
        return mStr + "..." + std::to_string(mVal);
    }

private:
    std::string mStr;
    int mVal;
};

void CallBackFunction(Param p1, Param p2) {
    std::cout << p1.GetStrVal() << "\n";
    std::cout << p2.GetStrVal() << "\n";
}

int main() {
    CallBackFunction({ "Hello", 1 }, { "World", 2 });
}

In the above example you can find a simple code that creates a named integer parameter into a separate type: Param. When you run the code, it should output the following:

Hello...1
World...2

The problem is that we have an ellipsis ... rather than the colon : that we wanted in the first place. You can run the debugger and see where this output comes from.

Set a breakpoint at the line where CallBackFunction is called and then press F11 to try to step into the function. Since the code is relatively simple, we can just step into every procedure and investigate the program flow. Where will the debugger go at the start? I see something like this (assuming you have “Just My Code” disabled):

(Just My Code is available for C++ since Visual Studio 2017 15.8. See this post for more information: Announcing C++ Just My Code Stepping in Visual Studio | C++ Team Blog.)

In the above example, debugger goes to the next instruction after the breakpoint. In our case, it’s a constructor of std::string!

While sometimes it might be interesting to look into the internals of the Standard Library, it’s probably not the best place to look for the solution to our problem with the string output.

Imagine what happens if you have several parameters. When you want to step into a method, you’ll first need to visit all code related to the creation of the parameters. The whole process might be frustrating, and you would lose a lot of time before going into the target function. Of course, you might just set a breakpoint at the beginning of the destination code; this will skip all of the unwanted behavior. But there is a better option.

What if you could control and filter out unwanted functions?

Filtering in Visual Studio

Before VS 2012 it was relatively tricky to filter out the code. Usually, it involved playing with some registry values. Fortunately, since Visual Studio 2012, this useful feature has been much improved.

All you need to do is edit the default.natstepfilter XML file. It’s usually located in:

// VS 2015
Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Packages\Debugger\Visualizers

// VS 2019:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Packages\Debugger\Visualizers

This is the same for VS 2015, and for VS 2013 and VS 2012.

To add more functions that will be filtered out, you can use regex expressions:

In our example, when we want to skip all the functions from the std:: namespace, we can write the following:

std\:\:.*

and add this line to default.natstepfilter:

<Function>
    <Name>std\:\:.* </Name>
    <Action>NoStepInto</Action>
</Function>

Please note that the file might be blocked for writing. The file default.natstepfilter is loaded each time a debugger session starts.

You can now set up the most common functions in your project that you don’t want to visit during debugging. Usually, those are trivial functions or from third-party code (std, boost?). Remember not to filter out too much!

In the latest versions of Visual Studio, you can also benefit from “Just My Code”, which won’t enter code that is not “your” module. That means system calls, the Standard Library, ATL, MFC, and others. You can even set your third-party libraries.

While each revision of Visual Studio makes it easier and easier to control the debugging flow, there’s an even faster and more straightforward solution.

See below:

Even more with Visual Assist

In Visual Assist, you have a separate window that allows you to see all debugger events and filter them during the debugging session!

You can show it from Visual Assist -> Debug -> VA Step Filter. You also have to have debugger integration enabled (turned on by default).

For our example, the first time I run a debugger and press F11, it will still step into the constructor of std::string. But the VA Step Filter window will show the following output:

As you can see in the Debug Events section, Visual Assist lists: breakpoints, step into, step out, and step over actions.

I can now click on std::string::basic_string... and then the next time debugger enters the same event, it will skip it and move forward. In our case, it will step into the constructor of our Param class.

By default, VA has several predefined filters for the shared Windows libraries. You can also control the filters on a global level (all projects) or per solution.

What are the main advantages?

Try it out and see more information on the separate page: VA Step Filter

References

Exit mobile version