gpt4 book ai didi

.net - 定位托管 .NET 应用程序中的 native 内存泄漏,DebugDiag 缺少堆栈跟踪

转载 作者:行者123 更新时间:2023-12-02 15:02:16 25 4
gpt4 key购买 nike

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小时,并没有设置为“立即开始录制”。同样的消息。

enter image description here

enter image description here

这是来自 9GB procdump 的虚拟内存摘要(没有运行泄漏检测)

enter image description here

那么我需要做什么才能从 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/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com