Improvement to Debugging C++ Access Violations in Visual Studio 2015 Update 1

Aaron Hallberg

In this blog post I will introduce a small but useful Visual Studio 2015 Update 1 improvement for debugging C/C++ code.

When writing C/C++ code it is common to deal with complex lines that utilize multiple pointers, for example dereferencing multiple pointers on a single line. However, it can be difficult to decipher which part of that line of code is the problem when an access violation occurs. You may have previously broken up the line of code into multiple lines in order to debug this problem, but no longer. When this happens while using Visual Studio 2015 Update 1, you can easily see which pointer caused this exception. We now show a message directly in the Exception Dialog that informs you which variable was the nullptr.

Currently this capability is only available while debugging C/C++ code, but we are working toward applying the experience to .NET debugging in the future. If you’d like to see this feature for managed code, please continue to add votes and comments to this UserVoice item detailing the request.

Example

Let’s take a look at the small C++ code sample below (the full source is attached). In this example we have a series of classes, each of which contains a pointer to another class, and one function named GetHelloWorld(). In the main()method we dereference all of the pointers in order to print “Hello World”.

int main() {    ClassA* A = new ClassA();    printf(A-> B-> C-> D-> GetHelloWorld());    return 0; }

When I run this simple demo I get an exception for an access violation on the line printf(A-> B-> C-> D-> GetHelloWorld()); I know that something on this line must be causing the access violation. But what? With prior versions of Visual Studio, I would have to investigate further into the code to figure that out. Now with VS 2015 Update 1, all I have to do is look at the message in the Exception Dialog that pops up. The debugger tells me that a read access violation occurred and that A->B was nullptr.

NullReference

Now I can break into my code knowing exactly what part of the chained line caused the access violation and can fix the issue.

Wrap up

Install Visual Studio 2015 Update 1 RC today, and try out this new feature. We are aware this functionality is highly desirable for .NET debugging as well. We’re working on it, but can’t promise when it will be available. Please vote for and comment on this UserVoice item and provide your feedback. As always, we welcome feedback with open ears so please let me know what you think in the comments section below, through Visual Studio’s Send a Smile tool, or via Twitter.

NativeAccessViolationDemo.zip

0 comments

Discussion is closed.

Feedback usabilla icon