【发布时间】：2015-02-27 01:24:19
【问题描述】：
DebugDiag 中的 LeakTrack 未捕获堆栈跟踪，因此不知道从哪里开始。
我有一个内存泄漏的 .NET 应用程序（作为 Windows 服务运行的 NServiceBus 进程）。在 5-6 天的过程中增长到大约 10GB。
我在 WinDbg 中使用 !address –summary 进行了 procdump 和基本分析。我看到堆提交大小为 8.6GB。
接下来，我对托管内存的转储运行了 DebugDiag。托管内存中根本没有危险信号，所以我尝试查看本机分配。
所以我DebugDiag（2.1.0.7），并选择了
监控泄漏时立即记录调用堆栈（又名“FastTrack”）注意：不建议监控超过 15 分钟）
然后我运行了 30 分钟（与警告相反）。运行分析时，我收到一条消息，它无法获取调用堆栈，因为我运行它的时间不超过 15 分钟（我做了）或者我需要设置“立即开始记录调用堆栈”（我做了)。
所以，我决定再试一次。我这次设置为运行2小时，并没有设置为“立即开始录制”。相同的消息。
这是来自 9GB procdump 的虚拟内存摘要（没有运行泄漏检测）
那么我需要做什么才能从 DebugDiag 获取调用堆栈？我的罪魁祸首似乎是在提交的内存中（我不确定我是否真的理解在这种情况下保留与提交）。但是不知道如何确定罪魁祸首。
也不确定为什么 DebugDiag 认为有 8TB 内存（这是在虚拟机上运行，不确定是否相关）。
【问题讨论】：
-
至于为什么您会看到 8TB 空闲空间，这是 64 位进程可用的虚拟地址空间。它可能没有（并且几乎可以肯定没有）由物理内存支持。
-
您使用了错误的工具，Umdh.exe 是诊断非托管内存泄漏的工具。首先查找位图上缺少的 Dispose() 调用。测试 32 位版本也无妨。
-
使用 WPRUI/experf 监控/分析内存使用情况：channel9.msdn.com/Shows/Defrag-Tools/…
-
@HansPassant 谢谢，没听说过 Umdh。会试一试。另外 - 此应用程序中没有位图。
-
@HansPassant 来自 umdh 的堆栈跟踪没有显示来自我的应用程序 dll 的单个条目。我可以在输出顶部的日志中看到符号实际上是为我的应用程序加载的。所以不确定那里发生了什么。
标签： .net memory memory-leaks windbg debugdiag