我使用以下命令在服务器上创建了 ASP.NET 进程的内存转储：.dump /ma mydump.dmp。我正在尝试识别内存泄漏。
我想在我的本地开发 PC 上更详细地查看转储文件。我在某处读到建议在创建转储文件的同一台机器上进行调试。但是，我也读到一些开发人员确实分析了他们本地开发 PC 上的转储文件。最好的方法是什么？
我注意到，当我使用上面的命令创建转储文件时，W3WP 进程内存增加了大约 1.5 倍。这是为什么？我想这应该在实时服务器上避免。
【问题讨论】：
在同一台机器上进行分析可以使您免于之后出现 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 也更好。这些工具专为转储捕获而设计，它们对目标进程的影响最小。
对于非托管库的内存泄漏，您应该使用 Debug Diag 的内存泄漏规则。对于托管内存泄漏，您可以在内存使用率高时简单地捕获挂起转储。
【讨论】：
我不是 WinDBG 方面的专家，但我曾经不得不分析我的 ASP.NET 站点上的转储文件以找到 StackOverflowException。
虽然我获得了实时站点的转储文件（我别无选择，因为那是失败的原因），最初我尝试在本地开发 PC 上分析该转储文件，但在尝试加载 CLR 数据时遇到了问题从中。原因是我的开发 PC 和服务器之间的 .NET 框架的确切版本不同 - 两者都是 .NET 4，但我想我的开发 PC 安装了一些服务器没有的累积更新。由于这种差异，SOS module 只是拒绝加载。实际上，我写了一封 blog post 来讲述我的发现。
所以要回答您的部分问题，您可能别无选择，只能从您的服务器运行 WinDBG，至少您可以确定转储文件将匹配您的环境。
【讨论】：
StackOverflowExceptions，所以必须尽快找到它。据我回忆，虽然附加到 w3wp.exe 进程并没有在网站上造成太多性能问题，但据我所知，这是你的电话。
除非问题难以在您的开发机器上体现出来，否则无需在实际机器上进行调试。
只要您拥有带有私有符号的 pdb，那么应该解析这些符号并正确显示调用堆栈并安装正确版本的 .NET。
在查看内存泄漏方面，您应该启用 Gflags 用户堆栈跟踪并以 2 个间隔进行内存转储，以便您可以比较引起内存泄漏的操作之前和之后的内存使用情况，记得在之后禁用 gflags！
您还可以在具有自动内存压力分析脚本的服务器上运行 DebugDiag，该脚本可以处理 .Net 泄漏。
【讨论】：