Visual Studio 2010 调试器的一个奇怪的例子（它不能命中断点）

Question

Visual Studio 2010调试器的一个奇怪的例子（它不能打断点）

这是重现问题的代码：

class Program {
  static void Main(string[] args) {
    bool b = false;

    if (b) {
        List<string> list = new List<string>();
        foreach (var item in list) {

        }
    } else {
        Console.WriteLine("1");
    }
    Console.WriteLine("2");//add a break point here in VS2010
  }
  //1. configuration: release
  //2. platform target: x64 or Any Cpu
  //3. debug info: pdb only or full
  //4. OS: Win7 x64
  //5. optimize code: enabled
}

在代码的最后一条语句中添加一个断点，然后在vs2010中调试它，你会看到无法击中断点。

要重现这个奇怪的案例，您需要满足以下条件：

1. 操作系统：windows 7 x64；
2. VS构建配置：发布；
3. VS构建平台目标：x64或Any Cpu；
4. VS 构建调试信息：仅 pdb 或完整；
5. VS构建优化代码：启用；

我不确定这些条件是否足以重现它，但这就是我发现此问题时我的机器的配置方式。

为什么调试器无法命中断点？

提前致谢！

如果您可以重现此问题，请考虑投票 这篇文章。

Answer 1

当提供的示例在发布模式下构建然后 JIT 为 64 位机器代码时，它不包含足够的信息供调试器将断点与任何特定机器指令关联起来。这就是为什么调试器在执行 JIT 机器代码期间永远不会在此断点处停止的原因。它只是不知道在哪里停止。它可能是某种不当行为，甚至是 64 位 CLR 调试器中的错误，因为只有当它被 JIT 编译成 64 位机器代码而不是 32 位机器代码时才可以重现。

当调试器在代码中看到断点时，它会尝试在 JIT 代码中查找与断点标记的位置相对应的机器指令。首先，它需要找到与 C# 代码中的断点位置相对应的 IL 指令。然后它需要找到与IL命令对应的机器指令。然后它在找到的机器指令上设置一个真正的断点并开始执行该方法。在您的情况下，调试器似乎只是忽略断点，因为它无法将其映射到特定的机器指令。

调试器无法找到紧跟在 if...else 语句之后的机器指令的地址。 if...else 语句及其内部的代码以某种方式导致了这种行为。 if...else 之后的语句是什么并不重要。您可以将 Console.WriteLine(“2”) 语句替换为其他语句，您仍然能够重现该问题。

如果您使用 Reflector 反汇编生成的程序集，您将看到 C# 编译器在读取列表的逻辑周围发出一个 try...catch 块。这是 C# 编译器的记录功能。您可以在 foreach 语句

try...catch...finally 块对 JIT 代码具有相当大的侵入性影响。它在底层使用 Windows SEH 机制并严重重写您的代码。我现在找不到一篇好文章的链接，但我相信如果您感兴趣的话，您可以在那里找到一篇文章。

这就是这里发生的事情。 if...else 语句内的 try...finally 块会导致调试器出现问题。您可以使用非常简单的代码重现您的问题。

bool b = false;
if (b)
{
    try
    {
        b = true;
    }
    finally
    {
        b = true;
    }
}
else
{
    b = true;
}
b = true;

此代码不调用任何外部函数（它消除了答案之一提出的方法内联的影响），并且它直接编译为 IL，无需 C# 编译器添加任何额外的代码。

它只能在发布模式下重现，因为在调试模式下，编译器会为 C# 代码的每一行发出 IL NOP 指令。 IL NOP 指令不执行任何操作，并且由也不执行任何操作的 JITer 直接编译为 CPU NOP 指令。该指令的有用之处在于，即使其余代码被 JITer 严重重写，调试器也可以将其用作断点的锚点。

通过在 if...else 后面的语句之前放置一条 NOP 指令，我能够使调试器正常工作。

您可以在此处阅读有关 NOP 操作和调试器映射过程的更多信息 调试IL

您可以尝试使用 WinDbg 和 SOS 扩展来检查该方法的 JIT 版本。您可以尝试检查 JIT-er 生成的机器代码，并尝试理解为什么它无法将该机器代码映射回 C# 的特定行。

这里有几个关于使用 WinDbg 中断托管代码并获取 JIT 方法的内存地址的链接。我相信您应该能够找到一种方法从那里获取方法的 JIT 代码： 在 WinDbg 中为托管代码设置断点，SOS 备忘单 (.NET 2.0/3.0/3.5)。

您还可以尝试向 Microsoft 报告问题。这可能是 CLR 调试器错误。

谢谢你提出这个有趣的问题。

Answer 2

使用VS2010 SP1，如果在发布模式下设置断点，它会停在最后一行。您确实应该安装它，它特别提到它修复了调试器问题，有时它会跳过断点（尽管不是这种特定情况）。

Answer 3

将构建配置更改为“调试”，而不是“发布”。

Answer 4

JIT 编译器使用的优化技术可能会导致这种情况。

其中一种优化称为方法内联，它可能是造成这种行为的原因。

我现在无法准确判断，因为我正在使用另一个人的计算机......但您可以自己测试一下：

1）创建以下方法：

[MethodImpl(MethodImplOptions.NoInlining)]
public static void MyMethod(string str)
{
    str += "-CONCAT-STRING";
}

2）仅用“MyMethod”替换对“Console.WriteLine”的调用

3）设置断点，然后尝试一下。

4) 现在，从方法“MyMethod”中删除“MethodImpl”属性。

//[MethodImpl(MethodImplOptions.NoInlining)]
public static void MyMethod(string str)
{
    str += "-CONCAT-STRING";
}

5) 再次运行，断点在同一位置。

6）如果它在第一次运行时停止，但在第二次运行时没有停止......那么这就是原因。

Answer 5

我认为当您使用发布模式进行调试时，您的断点可能与代码中的实际行不对应，因为机器代码可能已经过优化。在您的代码的情况下，您实际上没有执行打印“1”然后“2”的任何部分，因此可以安全地假设编译器会删除 (b==false) 的代码，因为它永远不会达到了。

Answer 6

构建版本省略了创建调试符号，这本身是显而易见的。

您可以通过转到项目的属性来覆盖它。选择发布配置并点击构建选项卡上的“高级”。将调试信息设置为完整。