3

我使用以下命令在服务器上创建了 ASP.NET 进程的内存转储：.dump /ma mydump.dmp。我正在尝试识别内存泄漏。

我想在我的本地开发 PC 上更详细地查看转储文件。我在某处读到建议在创建转储文件的同一台机器上进行调试。但是，我也读到一些开发人员确实分析了他们本地开发 PC 上的转储文件。最好的方法是什么？

我注意到当我使用上面的命令创建转储文件时，W3WP 进程内存增加了大约 1.5 倍。这是为什么？我想这应该在实时服务器上避免。

4

3 回答 3

1

我不是 WinDBG 方面的专家，但我曾经不得不分析我的 ASP.NET 站点上的转储文件以找到一个StackOverflowException.

虽然我得到了我的实时站点的转储文件（我别无选择，因为那是失败的原因），最初我试图在我的本地开发 PC 上分析该转储文件，但在尝试从中加载 CLR 数据时遇到了问题。原因是我的开发 PC 和服务器之间的 .NET 框架的确切版本不同 - 两者都是 .NET 4，但我想我的开发 PC 安装了一些服务器没有安装的累积更新。由于这种差异， SOS 模块只是拒绝加载。我实际上写了一篇关于我的发现的博客文章。

因此，要回答您的部分问题，您可能别无选择，只能从您的服务器运行 WinDBG，至少您可以确定转储文件将与您的环境匹配。

于 2012-07-15T20:13:40.943 回答
1

在同一台机器上进行分析可以使您免于之后的 SOS 加载问题。除非您熟悉 WinDbg 和 SOS，否则您会发现它令人困惑和沮丧。

如果您必须使用另一台机器进行分析，请务必仔细阅读这篇博文，http://blogs.msdn.com/b/dougste/archive/2009/02/18/failed-to-load-data-access -dll-0x80004005-or-what-is-mscordacwks-dll.aspx，因为它向您展示了如何将必要的文件从源计算机（捕获转储的位置）复制到目标计算机（启动 WinDbg 的计算机）。

对于您的第二个问题，当您使用 WinDbg 直接附加到进程并使用 .dump 命令捕获转储时，不幸的是目标进程被修改了。不容易用几句话来解释。推荐的方法是使用 ADPlus.exe 或 Debug Diag。甚至来自 SysInternals 的 procdump 也更好。这些工具专为转储捕获而设计，它们对目标进程的影响最小。

For memory leak from unmanaged libraries, you should use memory leak rule of Debug Diag. for managed memory leak, you can simply capture hang dumps when memory usage is high.

于 2012-07-16T03:00:41.777 回答
0

除非问题很难在您的开发机器上表现出来，否则无需在实际机器上进行调试。

只要您拥有带有私有符号的 pdb，那么应该解析这些符号并正确显示调用堆栈并安装正确版本的 .NET。

在查看内存泄漏方面，您应该启用 Gflags 用户堆栈跟踪并以 2 个间隔进行内存转储，以便您可以比较引起内存泄漏的操作之前和之后的内存使用情况，记住之后禁用 gflags！

您还可以在具有自动内存压力分析脚本的服务器上运行 DebugDiag，该脚本将与 .Net 泄漏一起使用。

于 2012-07-15T20:55:07.737 回答