检查 Visual C++ 断点（不停止）答案

【问题标题】：checking Visual C++ breakpoints (not stopping)检查 Visual C++ 断点（不停止）
【发布时间】：2018-02-26 14:36:33
【问题描述】：

我正在使用安装在 Windows 虚拟机 (VMWare) 上的 Visual C++。由于无法让调试器在断点处停止，我想知道断点机制本身是否存在问题，可能是因为我在 VM 中工作（？）。 ___asm int 3 工作正常，我可以通过代码和反汇编窗口进行调试，到达我的断点。有没有办法检查它们是否正确插入？

这里是调试时的源代码窗口

这里是反汇编窗口

它在__asm int 3; 中断，但它没有在。 double myDouble=6;。有没有办法了解断点是否真的放在那里？

【问题讨论】：

您是否处于调试模式？
是的。我处于调试模式。

标签： assembly visual-c++ virtual-machine breakpoints

【解决方案1】：

如果您只想检查断点是否在预期的位置，您可以使用 DebugBreak and __debugbreak.

您可以在代码中的任何位置调用 DebugBreak Win32 函数或 __debugbreak 内部函数。 DebugBreak 和 __debugbreak 与在该位置设置断点的效果相同。

回答您的评论：

__asm int 3 现在会为函数生成本机代码。如果您希望某个函数在您的代码中产生断点，并且您希望将该函数编译为 MSIL，请使用__debugbreak。

因此，这可能取决于您编写的是托管代码还是非托管代码。

【讨论】：

嗨 Yola，它与 __asm 有什么不同吗？我的问题是调试器不会在断点处停止。我怀疑断点并没有真正添加。
这是一个 C++ 问题。 MSVC 是否甚至让您可以选择将 C++ 编译为托管/非本机代码？
@PeterCordes 好吧，我从来没有写过一行托管 C++，但我看到很多关于这个主题的讨论，比如Difference between managed c++ and c++
好吧，根据这一点，“托管 C++”是一种不同的语言，除非有人明确说他们正在编写“托管 C++”，否则您应该假设它是编译为机器代码的常规 C++。我仍然建议使用 __debugbreak 内在而不是内联 asm，因为它可能编译成相同的东西。
我解决了这个问题。这是由于一个错误，但正如您猜到的那样，不是在 VS 中，而是在调用 DLL 的框架中。它创建了一个干扰调试的 DLL 进程的副本（如果我从这次冒险中学到了很多，很可能是通过创建歧义）。不过，我很乐意理解为什么 DebugBreak() 和 ___asm 没有受到影响。 @Yola，您提到它们就像断点。到底有什么区别？