在 .Net 应用程序中分析极端的私有字节使用，是否存在本机内存泄漏？

Question

我们有一个正在运行的.Net网站，它使用了大量的私有字节：4.45 GBytes及以上。这已经在多个Web服务器上发生过，但似乎没有模式。

借助其他答案和当然是Tess Ferrandez的博客的帮助，我们已经使用DebugDiag和WinDbg（Win8 SDK的一部分）获得了很多信息：

- 我们知道只有一个分配超过3 GBytes： - 我们知道它是本地内存： - 我们知道它是在堆1上分配的：

从这里开始我们陷入了困境。建议使用的命令（!heap -stat -h、!heap -flt s和!heap -p -a），也可以在这里找到，无法为我们提供有关此行为原因的信息。

有人以前见过这种情况吗？有没有其他方法或命令可以查看是什么导致nativerd（IIS的本机代码配置读取器）失控？

- Jacco

Answer 1

在windbg中加载sos dll。

在windbg中尝试使用!dumpheap -stat。这将返回堆中的所有对象。

遍历堆并查看哪个对象创建的数量更多，并分析该对象是否仍需要保留在内存中，或者应该早些时候进行垃圾回收。

收集这样的对象并执行!gcroot，您将能够看到哪个父对象持有您的对象，以防止其被垃圾回收。这将帮助您缩小内存泄漏的范围。

最常见的内存泄漏是由于在.net中使用事件而引起的。类A可能已订阅了类B的事件。除非类B是垃圾回收的对象，否则对象A仍将驻留在内存中。

更新：

对于本机内存泄漏，请在代码库中使用_CrtDumpMemoryLeaks。如果您正在使用Visual Studio，则会在输出窗口中显示泄漏内存的块。 Glowcode还允许您检测本机内存泄漏。

- Rockstart

---

谢谢回答。但我们不是在谈论最常见的托管内存泄漏。对象数量也没有增加，我们只有一个单一的对象，但无法在Windbg中访问它。 - Jacco

谢谢你的更新。但这是一个C++函数吗？我们的应用程序是用C#编写的。它似乎与DebugDiag使用的LeakTrack.dll具有相同的目的。我们之前不知道Glowcode，可以试一下。 - Jacco

Answer 2

由于这是一个巨大的分配，您可以使用Windbg设置断点并检查调用堆栈。请参见我的回答 here ，了解如何设置此类断点。请注意，这适用于32位，您可能需要将其调整为64位。

- Kjell Gunnar

Answer 3

我是一个DebugDiag新手，但我认为下一步应该看看由DebugDiag提供的模块报告中提供的调用堆栈样本，以查看是什么导致了这些分配。根据你的屏幕截图，似乎你已经点击了那个有问题的功能。在DebugDiag报告的那个部分显示了什么？ 此外，你怎么知道它是一个单一的分配？

- mrganss