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
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:
extern "C" __declspec(dllexport) TCHAR* test(TCHAR** strarr)
// set the data breakpoint for both reading and writing
// 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
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.