Visual Studio 2010 中的编程数据断点 [英] Programmatic data breakpoint in Visual Studio 2010

问题描述

我一直在尝试使用程序化数据断点，就像 CBreakpoint 示例，通过使用 SetThreadContext 直接设置调试寄存器.我能找到的大多数引用都表明 Visual Studio 在遇到数据断点时仍会中断，即使它本身没有设置该数据断点.但是，这似乎不是 Visual Studio 2010 的工作方式.

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.

我的数据断点在程序未被调试时完美运行(它因 STATUS_SINGLE_STEP 而崩溃，这是数据断点引发的异常).如果我使用 WinDbg 进行调试，它也会正常中断.但是在任一 Visual Studio 2010 下调试它时，它似乎只是继续运输并忽略断点.有没有人有在 Windows 7 下的 Visual Studio 2010 下使用以编程方式设置的数据断点的经验?我需要做些什么才能打破它们吗?(我尝试将 STATUS_SINGLE_STEP 添加到第一次机会例外"列表中，行为没有改变.)

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.)

或者，我是否可以采取任何措施来吞下调试器中的 STATUS_SINGLE_STEP 异常?结构化异常处理程序会在调试器看到异常之前吃掉它吗?这是一个 x86_64 程序这一事实有什么影响吗?我需要在 Visual Studio 2010 设置中做些什么吗?

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?

推荐答案

做了一点测试，在 win7 x64 上获得了 VS 2010 SP1 Ultimate，使用 32 位二进制文​​件在硬件断点(有和没有 SEH)上正确中断.但是，当使用 64 位二进制文​​件时，它不会捕获单个步骤(我不得不更改一些类型才能使其编译).

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).

再深入一点，似乎 VS 的行为很奇怪，因为虽然它没有捕获单步，但我无法让它正确地跳过一段将触发硬件断点的代码.

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.

我感觉库没有正确设置 x64 下的 DR 寄存器，这可能是在 x64 的 SetThreadContext 中进行更改.

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.

稍微摆弄一下，我注意到您使用的库在设置或获取线程上下文之前不会挂起线程，MSDN 说这是一个很大的禁忌:

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:

您无法获得正在运行的线程的有效上下文.在调用 GetThreadContext 之前使用 SuspendThread 函数挂起线程.

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

然而，即使使用另一个库 正确挂起目标线程并无错误地执行其所有调用仍然不会让 VS 捕获 BP，这让我认为不仅您使用的库有问题，而且 VS 的 x64 调试器也有问题.

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.

这篇关于Visual Studio 2010 中的编程数据断点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！