Visual Studio Debugger
How to: Set a Data Breakpoint (Native Only)

This topic applies to:

Edition

Visual Basic

C#

C++

Web Developer

Express

Topic does not applyTopic does not apply

Native only

Topic does not apply

Standard

Topic does not applyTopic does not apply

Native only

Topic does not apply

Pro and Team

Topic does not applyTopic does not apply

Native only

Topic does not apply

Table legend:

Topic applies

Applies

Topic does not apply

Does not apply

Topic applies but command hidden by default

Command or commands hidden by default.

Data breakpoints break execution when a value that is stored at a specified memory location is written. If the value is read but not written, execution does not break.

Data breakpoints do not work under these conditions: if a process that is not being debugged writes to the memory location or if the memory location is shared between two or more processes. Data breakpoints do not work if the memory location is updated within the kernel. For example, if memory is passed to the 32-bit Windows ReadFile function, the memory will be updated from kernel mode and the debugger does not break on the memory write.

To set data breakpoints, the debugger must be in break mode only.

Addresses of variables change from one debugging session to the next. For this reason, data breakpoints are automatically disabled at the end of each debugging session.

If you set a data breakpoint on a local variable, the data breakpoint remains enabled when the function ends. However, the memory address it is set on no longer has the same meaning. Therefore, the results of such a breakpoint are unpredictable. If you set a data breakpoint on a local variable, the best practice is to remove or disable the breakpoint before the function ends.

Visual Studio supports a maximum of four data breakpoints per solution.

NoteNote:

The dialog boxes and menu commands you see might differ from those described in Help depending on your active settings or edition. To change your settings, choose Import and Export Settings on the Tools menu. For more information, see Visual Studio Settings.

To set a memory change breakpoint

  1. On the Debug Menu, choose New Breakpoint and then click New Data Breakpoint

    —or—

    In the Breakpoints window menu, click New and then choose New Data Breakpoint.

    The New Breakpoint dialog box appears.

  2. In the Address box, type a memory address or expression that evaluates to a memory address. For example, &avar to break when the contents of variable avar change.

  3. In the Byte Count box, type the number of bytes you want the debugger to watch. For example, if you type 4, the debugger will watch the four bytes starting at &myFunction and break if any of those bytes change value.

  4. Click OK.

See Also

Concepts

Tags :


Community Content

Thomas Lee
Set a Data Breakpoint (Mixed Mode)
you can set data breakpoint in mixed mode after some code changes:

if you have got line like following:
public:
int var;

You make follwing code changes to set a data breakpoint:

public:
int GetVar() const
{
return _var;
}
void SetVar(const int p_var)
{
_var = p_var;
}
__declspec(property(get=GetVar,put=SetVar)) int var;
private:
int _var; //private analogue of 'var'-variable

And now you can set a simple breakpoint at '_var = p_var;'-line, in that way you set data breakpoint in mixed mode.

BobConsultant2
Request for consistant variable addresses from one debugging session to the next
Previous Visual Studio versions allowed breaking on a memory address from one debugging session to the next.

The new security practices which randomize the program start address, randomize the base heap address, and
randomize dll placement are excellent for protecting an application from attack. However these practices
now prevent the use of VisualStudio as a tool to quickly answering the question "What code changed this memory location"?

To answer the question quickly, the debugging session must be rerun.

Please implement in VisualStudio an option to turn off all randomization's so that breaking on a memory address from one debugging session to the next works.

Page view tracker