Programmatic data breakpoint in Visual Studio 2010

Question

I've been trying to use programmatic data breakpoints, à la the CBreakpoint example, by using SetThreadContext to set the debug register directly. Most references that I can find indicate the Visual Studio will still break whenever it encounters a data breakpoint, even if it didn't set that data breakpoint itself. However, this doesn't appear to be how Visual Studio 2010 works.

I'm in a situation where my data breakpoint works perfectly when the program is not being debugged (it crashes with STATUS_SINGLE_STEP, which is the exception raised by a data breakpoint). It also breaks properly if I'm debugging with WinDbg. But when debugging it under either Visual Studio 2010, it seems to just keep trucking and ignore the breakpoint. Does anyone have any experience with using a programmatically-set data breakpoint under Visual Studio 2010, under Windows 7? Is there something that I need to do to it them to break? (I tried adding STATUS_SINGLE_STEP to the 'first-chance exceptions' list, with no change in behavior.)

Alternately, is there anything that I might be doing to swallow the STATUS_SINGLE_STEP exception in the debugger? Would a structured exception handler eat the exception before the debugger can see it? Is anything affected by the fact that this is a x86_64 program? Is there some dance I need to do in the Visual Studio 2010 settings?

Biparous

VS might only monitor debug interrupts from software sources, aka INT 2C, which you need to set via WriteProcessMemory (idk if __debugbreak will work for your usecases). – Gasworks

@Gasworks I'm doing this all from my own process. And I'm not trying to stop on a specific instruction… – Biparous

Answer 1

Did a little testing, got VS 2010 SP1 Ultimate on win7 x64, using a 32bit binary to break correctly on HW breakpoints (both with and without SEH). When using a 64 bit binary however, it doesn't trap the single step (and I had to alter a few types just to get it to compile).

Digging a little deeper, it seems to be VS acting weird, cause although it doesn't trap the single step, I can't get it to correctly step over a section of code that will trigger a HW breakpoint.

I have a feeling that the library isn't correctly setting the DR registers under x64, this may be to do changes in SetThreadContext for x64.

Update

Fiddling around a little more, I noticed that the library you are using doesn't suspend the thread before setting or getting the thread context, MSDN says this is a big NO-NO:

You cannot get a valid context for a running thread. Use the SuspendThread function to suspend the thread before calling GetThreadContext.

However, even using another library that does correctly suspend the target thread and executes all its calls without error still doesn't let VS trap the BP, which makes me think that not only is the library you are using buggy, but VS' x64 debugger is buggy as well.

Gasworks

I have verified that the code is properly setting the DR registers—or at least I assume it is, because it traps properly both without a debugger and under WinDbg. Under WinDbg, I see the DR registers change properly. But I should look at the registers pane in VS to see if they take, or if VS is resetting them… – Biparous

I've also seen the warning that you shouldn't get/set the context of the running thread, which makes complete sense. However, it's working fine, and I saw at least one person speculate that it isn't a problem if you use CONTEXT_DEBUG_REGISTERS. (Which makes sense to me: normally you'd smash the instruction pointer and everything, but the only thing that would otherwise mess with the debug registers is, well, a debugger.) – Biparous

Answer 2

Have you enabled mixed (native & managed) debugging for your project? I went to project properties->configuration properties->debugger->debug type set to "mixed"

Found this answer here.

Droughty

Answer 3

There is a function named DebugBreak() that you can use to programmatically break your execution under MSVC 2010 but it stop inside of DebugBreak( disassembly code ). So if you want to break just in your code use __asm int 3 this is very simple and work in all intel compatible CPUs.

And one other note use IsDebuggerPresent() before either of DebugBreak() or __asm int 3 to avoid error in runtime( of course you already know that! :) )

Venlo

This question is about data breakpoints, not code breakpoints. – Biparous