views:

1140

answers:

2

I'm running into an odd problem with Visual Studio 2005: I have a data breakpoint that's set to run a macro and continue (that is, I select a macro and check Continue Execution.)

Now, instead of silently running the macro when the value in the data breakpoint (tracepoint, really) changes, I first get a message box informing me that the breakpoint was hit, and the macro runs only after I hit OK.

The code I'm debugging is timing sensitive, so this makes it impossible to debug. Is there a way to disable the message box that pops up?

In response to comments: The macro itself can be empty, or it can be any of the Microsoft provided sample macros - it doesn't make a difference.

A: 

I do not have vs.net 2005 on my machine.
So, I am speculating here.

What is the line of execution?

Is it trying to evaluate a property?
Is a conditional breakpoint set when the property is read? (i.e. break when property is read?)

Try removing other breakpoints related to the current line of execution and add tracepoint again.

shahkalpesh
It's a data breakpoint - it breaks when a memory location is written to from anywhere in the code, so it's not really associated with a line of code. This is native C++ code - I'm not sure what you mean by "property" but I feel that's irrelevant. Removing the breakpoint doesn't make a difference.
Ori Pessach
Is there a breakpoint set (inside the native instructions window that appears when you debug the code)?There is an option to see what is the native instructions being executed and I guess one can set breakpoint there as well.Is that the case?
shahkalpesh
No. And this is a data breakpoint, so it is not associated with a specific instruction - there's nowhere for the debugger to put an int 3 instruction. Data breakpoints are typically implemented using the CPU's debug registers (DR0-DR3.)
Ori Pessach
+1  A: 

It does this for me as well. The behavior does seem somewhat different based on how you set the "Continue execution" option, so my suspicion is that this behavior (painful as it is) may be by design. Or it may be a bug, but in either case you may be stuck.

An alternative might be to use windbg or one of the other Windows debugging tools, which also support data breakpoints. They take a bit of getting used to and are not nearly as user-friendly as the Visual Studio debugger, but they're pretty powerful. The "ba" command creates a data breakpoint, and you can program the debugger to perform a particular command when the breakpoint is hit. This article has some good introductory information about these debuggers, and the Q & A section near the end has an example of how to perform an action when a breadpoint is hit.

Charlie