查看.NET应用程序中的异常(下)

为什么要使用内存转储进行调试？

在两种主要情况下，您可能需要使用内存转储进行调试。第一种情况是应用程序有一个未处理的异常并崩溃，而您只有一个内存转储。第二种情况是，在生产环境中出现异常或特定行为，并且在排除故障时不能将调试器保留在附件中，因为调试器可能会中断用户服务。相反，您可以附加cdb，在正确的位置创建转储文件，然后分离调试器，这意味着应用程序只在服务中有一个小的中断时继续运行。当然，取决于你的环境，这并不总是可能的，但有时可能是你唯一的选择。让我们来看看如何在cdb和Visual Studio中使用内存转储进行调试。这来自本文附带的example2.exe应用程序。它有很多选项，但我们将要讨论的是为什么cdb比Visual Studio更快。首先，您应该启动一个命令提示符并使用调试工具切换到目录，然后运行“doDebug.cmd”文件，如前一篇文章所述（也附在zip文件中）。然后是“cdb-z c:\pathToDumpFile\stackOverflow.dmp”。应按照以下要求打开：

这表明我们有一个内存充足的小型转储，所以我们有我们需要的部分。我们有一个异常，在这种情况下是“堆栈溢出”异常。 我们知道存在堆栈溢出，但不知道这是托管还是非托管问题，所以让我们获取本机堆栈跟踪“kf”

这显示了mscorwks!CallDescrWorker调用了未知的方法。未知的原因是调试器使用模块列表来确定模块的名称（从“lm”获取模块列表），因为CLR JIT的MSIL进入程序集，所以当前模块中存在，因为它挂在进程中的某个位置。

因为mscorwks调用了未知函数，所以这很可能是一个托管问题。在上面的堆栈跟踪中，我使用了kf，因为这些显示了每个堆栈帧使用了多少内存。它实际上计算出了两帧之间的距离，因此第一帧没有内存使用。内存之所以重要，是因为有两种类型的堆栈溢出：第一种是在堆栈上创建太多或太大的对象；第二种是函数递归并耗尽所有内存。

那我们在哪？我们知道这可能是托管代码问题，所以让我们加载so s.dll，'loadby sos mscorwks'并获取堆栈跟踪。注意，因为这是递归的问题，如果你做了！CLRStack“调试器将在cdb中显示一帧又一帧。从Ctrl+C停止它，它将中断跟踪。使用cdb的一个技巧是，如果你需要做一些能输出大量数据的事情，那么就把窗口降到最低，这样就可以让整个团队受益。

所以我们现在有一个显示导致堆栈溢出的函数名的堆栈跟踪：如果我们有源代码，我们可以检查它并查看可能发生的情况，但是让我们快速查看一下MSIL。 和往常一样，我们需要获得helper方法的方法描述；所以我们通过执行“!Name2EE * example2.StackOverflow“。然后我们从“MethodTable:”中获取值并执行“!DumpMT -md 019631a4“。

那么，要得到MSIL，就做“!DumpIL 001963190“我们得到：

所以这很有趣，“ldarg.1”抓取第一个参数，“ldc.i4.1”抓取值1，“add”将它们相加；所以它递增某种类型的计数器，然后它根据_max_RecurseLevel检查结果，如果它大于或等于它，则它退出函数（“bge.s IL_0016”）。这是一个相当简单的例子，但是现在我们需要做的只是看看maxRecurseLevel和传入的值，看看我们在哪里。

顺便说一句，这些是msil文档的链接，当您不了解msil正在做什么时，使用msdn查看每个操作员的操作相当简单：

Ldarg.1 http://msdn.microsoft.com/en-us/library/system.reflection.emit.opcodes.ldarg_1.aspx

Ldc.i4.1 http://msdn.microsoft.com/en-us/library/system.reflection.emit.opcodes.ldc_i4_1.aspx

Bge_s http://msdn.microsoft.com/en-us/library/system.reflection.emit.opcodes.bge_s.aspx

Add http://msdn.microsoft.com/en-us/library/system.reflection.emit.opcodes.add.aspx

标签: none