c# - StackTrace/StackFrame 不返回生产环境中的预期信息

Question

我在我的 ASP.NET Web 应用程序中使用以下方法来接收异常的堆栈跟踪:

public static void getStackTraceInfo(System.Diagnostics.StackTrace trace)
{
    for (int i = 0; i < trace.FrameCount; i++)
    {
        int nLine = trace.GetFrame(i).GetFileLineNumber();
        int nCol = trace.GetFrame(i).GetFileColumnNumber();
        string methodName = trace.GetFrame(i).GetMethod().Name;
    }
}

try
{
}
catch(Exception ex)
{
    getStackTraceInfo(new System.Diagnostics.StackTrace(ex, true));
}

如果我在 Visual Studio 2010 开发环境中运行它，它会为我提供完整的行/列/方法名称信息，但在 IIS 的生产环境中，它会返回全 0 和方法名称作为空字符串。

我是否需要做任何特别的事情才能使其在 IIS 上也能正常工作？

Answer 1

It gives me full line/column/method name information if I run it in the Visual Studio 2010 dev environment, but in a production environment on the IIS it returns all 0's and the method name as empty string.

正确。仔细阅读类型名称； 诊断 很重要。该命名空间中的类型设计用于在调试环境中诊断问题。

Do I need to do anything special to make it work on IIS as well?

没有；您不需要在生产中使用诊断工具。

如果出于某种原因您想在生产环境中使用诊断工具，您至少需要将 PDB 文件推送到生产环境。正如我们将在下面看到的那样，这可能是一件危险而愚蠢的事情。我建议您不要这样做。

一些你没有问过的问题:

What tool should I be using to get caller information in a production environment?

如果您需要获取方法调用的行号等，您可能应该使用的工具是 C# 5.0 中新的 CallerLineNumber 和相关属性。这是一个关于它们的好博客:

http://blog.slaks.net/2011/10/subtleties-of-c-5s-new-callerlinenumber.html

如果您需要获取有关异常堆栈跟踪的信息，所见即所得。

In a debug environment does the StackTrace object provide a guarantee that the stack trace tells me where the current call came from?

没有。堆栈跟踪不会告诉您您最初来自哪里。堆栈跟踪告诉您下一步要去哪里。这很有用，因为在你来自哪里和你要去哪里之间通常有很强的相关性；通常你会回到你来自的地方。

但这并不总是正确的。 CLR 有时可以在不知道您来自何处的情况下确定下一步要去哪里，在这种情况下，堆栈跟踪不包含您需要的信息。

例如，尾调用优化可以从堆栈中删除帧。内联优化可以使对方法的调用看起来像是调用方法的一部分。 C# 5 中的异步工作流完全脱离了“你来自哪里”和“你下一步要去哪里”；在 await 之后恢复的异步方法的堆栈跟踪告诉您在下一个 await 之后您要去哪里，而不是在第一个 await 之前您是如何进入该方法的。

堆栈跟踪是不可靠的，所以不要依赖它们。仅将它们用作诊断辅助工具。

Why is it particularly dangerous to expose diagnostic information in ASP?

因为攻击者会试图通过向其 throw “异常”输入来导致您的服务器出现故障。如果这导致服务器宕机，那太好了，攻击者会很高兴。如果它保持服务器正常运行但将有关您的源代码的信息泄露给攻击者，那就更好了。现在他们有更多信息可用于发起更复杂的攻击。<​​/p>

ASP 服务器应该在生产环境中提供尽可能少的诊断信息。您在该生产环境中拥有的调试信息越少，您犯错并将您的实现细节暴露给攻击者的可能性就越小。