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