Programmatically setting data breakpoints
(too old to reply)
2009-02-14 11:40:57 UTC

I would like to know if there is any way to set a data breakpoint in my
application, using some Win32 programming API for setting this breakpoint ?

I mean, if I want to set a code breakpoint in my code, I know that I just
have to include "DebugBreak()" or "__asm int 3" at the point I want my code
to stop.

I would like to do the same for data, for having my program to stop if some
data variables are modified by any mean.

The reason for that is that I want to be able to detect the source of very
intermittent data corruptions in memory, and I expect to be able to generate
post-mortem dumps that way for analyzing these corruptions.

I cannot set them in Visual Studio because (1) the problem appears too much
rarely, (2) it is likely that it appears only in Release code, not in Debug
code, and (3) I would like to catch them in more real usage than the one I
can expect in debugging mode.

Also, data breakpoints are disabled on each new run whereas, if I could set
them by program, I could even be able to enable and disable them at some
points of the code, for example by disabling them at the very point I really
need to write something in these variables and reenabling them just after.

2009-02-15 06:27:34 UTC
Post by Gingko
I would like to know if there is any way to set a data breakpoint in my
application, using some Win32 programming API for setting this breakpoint
I'm sorry, I think I should have searched a little more before asking.

I found this project that looks like exactly what I need :


P.S.: Anyway, if ever you know about any other things on this kind, I will
still always be happy to read about them.
Jialiang Ge [MSFT]
2009-02-16 02:46:32 UTC
Hello Gingko
Post by Gingko
P.S.: Anyway, if ever you know about any other things on this kind, I
will still always be happy to read about them.
I'd like to share more readings of data breakpoints in Visual Studio. They
may not be directly related to the issue on this thread, but they provide
more backgrounds of data breakpoints in Visual Studio.

A. Data breakpoints in Visual Studio 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.

There is no way to break into the Visual Studio debugger when the CPU reads
at the specified address. This feature will not be included in Visual
Studio 2010, which is the last release for our current architecture. The
product group is working on a re-architecture of the backend, and the
support for this may be included for the releases after. At present, the
only thing we could do is to have the program set the data breakpoint by
itself. The x86/x64 architecture contains a set of debug registers, named
DR0, DR1, DR2, DR3, DR6, and DR7, which are intended for debugging use
only. By storing special values into these registers, a program can ask the
CPU to execute an INT 1 instruction (trigger a Single Step Exception)
immediately whenever a specified memory location is read from or written
to. See the article

Hardware breakpoints

or the codeproject article

Toggle hardware data/read/execute breakpoints programmatically

for an example. With the trick, we are able to work around the Visual
Studio limitation like this:

#include "hwbrk.h"

extern "C" __declspec(dllexport) TCHAR* test(TCHAR** strarr)
// set the data breakpoint for both reading and writing

return strarr[0];

// I do not remove the hardware breakpoint because
// I need to perform the trace after the function returns.

The ba command in Windbg directly supports all the break conditions. The
above efforts are not necessary if we use Windbg. For example, ba r4 myVar
sets a breakpoint for read (including write) access on 4 bytes of the
variable myVar.

B. Data breakpoints only apply to native debugging.


There are majorly three debugger types in Visual Studio: Managed Only,
Mixed, and Native Only. Managed Only is for code that runs under the common
language runtime (managed code). It is the default debugger type if we
start debugging from a .NET project. Mixed invokes debuggers for both
managed and unmanaged code. Native Only is for unmanaged C++ code. It is
the only debugger type that supports data breakpoints in Visual Studio.

As Steven J Steiner [MSFT] said in his blog entry Unmanaged Debugging vs.
Managed Debugging vs. Mixed Debugging
http://blogs.msdn.com/stevejs/archive/2004/05/05/126497.aspx, C# and VB
projects do not have a way to turn off managed debugging. In other words,
they have no built-in supports for the debugger type: Native Only. Data
breakpoints are disabled in this kind of projects, e.g. the C# Console
project. If you want to native debug an application that starts from a
managed exe, Steven J Steiner's suggestion is to leave the original project
as managed only, and create an additional VC++ project (e.g. an empty VC++
makefile project) to do your native debugging.

Windbg is a native debugger. It always initiates the debugging as Native
Only, thus, the above-mentioned limitation does not apply to Windbg.

Jialiang Ge (***@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:

Get notification to my posts through email? Please refer to

MSDN Managed Newsgroup support offering is for non-urgent issues where an
initial response from the community or a Microsoft Support Engineer within
2 business day is acceptable. Please note that each follow up response may
take approximately 2 business days as the support professional working with
you may need further investigation to reach the most efficient resolution.
The offering is not appropriate for situations that require urgent,
real-time or phone-based interactions. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
This posting is provided "AS IS" with no warranties, and confers no rights.
Continue reading on narkive: