DebugDiag 中的 LeakTrack 未捕获堆栈跟踪，因此不确定从这里开始。
我有一个 .NET 应用程序(作为 Windows 服务运行的 NServiceBus 进程)存在内存泄漏。在 5-6 天内增长到约 10GB。
我在 WinDbg 中使用 !address –summary 进行了 procdump 和基本分析。我看到堆提交大小为 8.6GB。
接下来，我在托管内存的转储上运行 DebugDiag。托管内存中根本没有危险信号，因此我尝试查看 native 分配。
所以我调试Diag(2.1.0.7)，并选择
Record call stacks immediately when monitoring for leaks (AKA "FastTrack") NOTE: not recommended when monitoring longer than 15 minutes)
然后我运行了 30 分钟(与警告相反)。运行分析时，我收到一条消息，指出它无法获取调用堆栈，因为我运行时间没有超过 15 分钟(我做了)，或者我需要设置“立即开始记录调用堆栈”(我做了) )。
所以，我决定再试一次。我这次设置的是运行2小时，并没有设置为“立即开始录制”。同样的消息。
这是来自 9GB procdump 的虚拟内存摘要(没有运行泄漏检测)
那么我需要做什么才能从 DebugDiag 获取调用堆栈？我的罪魁祸首似乎是在提交的内存中(我不确定我是否真的理解在这种情况下保留与提交)。但不知道如何确定罪魁祸首是什么。
也不确定为什么 DebugDiag 认为有 8TB 内存(这是在虚拟机上运行，不确定是否相关)。
最佳答案
您可以使用WPA(Windows性能分析器)通过使用虚拟分配配置文件可以获得VirtualAlloc跟踪，这是一个9分钟的视频，解释了VirtualAlloc相关问题的分析示例
使用 Windows 性能分析器了解 VirtualAlloc 的使用情况 http://channel9.msdn.com/events/Build/BUILD2011/HW-977P
关于.net - 定位托管 .NET 应用程序中的 native 内存泄漏，DebugDiag 缺少堆栈跟踪，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27712912/