堆栈跟踪中的行号错误

tim*_*oth 21 .net c# asp.net

问题

在我们的ASP .net网站上,我一直在异常的堆栈跟踪中得到错误的行号.我在谈论我们的现场环境.似乎有一种模式:堆栈跟踪将始终指向包含方法的右大括号的行.

例如:

public class Foo
{
    public void Bar()
    {
        object someObject = null;
        someObject.ToString();
     /*
          arbitrarily more lines of code
     */
     } // this line will be the one that the stack trace points to
}
Run Code Online (Sandbox Code Playgroud)

更多细节

  • 需要明确的是:这不仅适用于某些方法,而是发生在我们记录的每个异常中.所以我会在这里排除(JIT)优化,这可能会导致行号看似随机关闭.困扰我的是,错误的行号似乎始终指向包含方法的右大括号.

  • 请注意,在.net 4.6之前,框架中确实存在一个错误,如果您编译了目标x64,那么确实会发生这种情况.但是,微软证实这已得到修复.同时运行一个最小的示例应用程序,重申他们的主张.但由于某种原因,它仍然发生在Web服务器上.

  • 令我更困惑的是,它在我们的测试和开发环境中不会发生.测试和实时系统设置非常相似.唯一真正的区别是我们正在运行Windows Server 2012,而在测试系统上我们仍在使用Windows Server 2008.

我检查了什么

  • pdb文件有效(使用chkmatch测试)
  • 编译时间代码优化不是问题
  • 在4.6之前的.net中提到的错误不能用最小的例子再现
  • .NET版本完全相同
  • Build来自相同的部署脚本

解决这个问题的任何线索都受到高度赞赏.如果您知道我们可以查询的任何内容,请告诉我们.

Lex*_* Li 20

编译优化以及运行时优化可以改变实际执行以及构造的调用堆栈信息.所以你不能认真对待这些数字.

更多信息可以在Scott Hanselman的帖子中找到:Release IS NOT Debug:64位优化和发布构建调用栈中的C#方法内联.

如果不触摸您的位,就很难对特定情况进行故障排除.但是,如果你知道WinDbg,你可能会更深入,通过在发生异常时实时调试应用程序.然后,您可以转储实际的jitted机器代码以及其他运行时信息,以确定如何构造行号.

  • > 所以你不能那么认真地对待这些数字。但这是基本的可调试性。我们需要准确的行号。进行优化的工具必须发出一些映射,以便调试和监视工具可以在给定各种故障转储的情况下找到正确的行号 (4认同)

kop*_*nik 12

谢谢大家的帮助!我们发现在生产中的机器上运行的SCOM APM代理导致我们的应用程序在堆栈跟踪中记录错误的行号.一旦我们停用代理,行号就是正确的.