Learn to use Visual Studio, Visual Studio Online, Application Insights and Team Foundation Server to decrease rework, increase transparency into your application and increase the rate at which you can ship high quality software throughout the application lifecycle
This blog post is part of a series on breakpoints in the Visual Studio debugger
Data breakpoints are a powerful feature that is currently available to C++ developers. Data breakpoints allow you to stop execution when a particular piece of memory has changed. This can be very useful for solving corruption issues.
To demonstrate this feature, we will use our C++ example. Looking at our code we’ve noticed that the Result of PrintObject is not correct. It is giving us a result of 27, but we believe that the result should be 32.
To investigate this, we set a breakpoint in the PrintObject function and inspect the values that it is summing.
When we inspect this we can see that the value of pObj1->getMyInt() is 5, but it was 10 when we created the object. When did this change? We can set a data breakpoint to find out.
To do this, first we will set a breakpoint in the constructor of the object to get the location of m_myint.
At this point we can see that the value is still 10. We can also look at the address. Next in the Breakpoints windows, we click on New->New Data Breakpoint…
Then in the resulting dialog, we enter the address of the m_myint since it is the variable we want to watch. We select the byte count to be 4 since we are looking at a 4-byte integer.
Then you can see the new data breakpoint in the Breakpoints window.
When I continue the execution of the program, I see the following dialog.
And I am taken to the source code so that I can see where m_myint has changed.
Over the past week, we have posted about all the kinds of breakpoints that you can use in Visual Studio and how they are helpful.
We would love to hear your feedback about the breakpoints experience in Visual Studio. How else do you use breakpoints? What other breakpoint functionality would you like to see in the future? Please tell us more in the comments below, on our MSDN forum, or on our User Voice Site.
How about data breakpoints for managed code? They're not quite as essential in managed code, due to greatly reduced (or eliminated) aliasing, but they'd still be a big help in some scenarios. I would imagine that interaction with the managed heap is the significant complication that's prevented managed data breakpoints heretofore.
@Carl – Currently data breakpoints are not supported for managed code, but if you would like to see them added in a future release please create an item for it on the Visual Studio UserVoice site at visualstudio.uservoice.com
There is an idea related to managed code data breakpoints: visualstudio.uservoice.com/.../2333859-allow-right-click-on-variable-to-add-new-data-brea
It sure would be nice if there was an automatic way to un-grey this feature. I've selected everything I can find into "Native" mode, then stopped execution at a breakpoint, just to find "New Data Breakpoint..." to not be selectable. If a feature isn't available because of X, Y, and Z, why not "Fix" it for the developer so he/she doesn't have to dork around with infinite menus for four hours.
@Alexey - The UserVoice item you pointed to isn't related to managed code
@ Mike S -
If this is a suggestion, would you mind opening an item on visualstudio.uservoice.com?
If you believe this is a bug (the feature should be available, but is not), you can log it on connect.microsoft.com/VisualStudio