问题标签 [debugdiag]

是否可以让 DebugDiag 分析提供堆栈跟踪信息，如 windbg 'kp' 命令？即“kp”具有源文件路径、行号和参数值（我已经确认，对于有效的 DMP，我们的符号服务器正确地检测了 windbg 中的 DMP）

谢谢

我有正在使用 DebugDiag 工具 2.0 分析的内存泄漏，并且报告指向“按分配计数排列的前 5 个函数”和“按分配大小排列的前 5 个函数”都指向以下函数 MyModule!SomeClassName::Operator=+ 10f564

我的目标是从上面的神秘代码中了解真正的功能，实际上该类没有任何重载运算符 = 或 =+ 的实现

我已经在 WinDbg 中打开了转储，配置了符号和源文件。任何人都可以向我指出任何可以帮助我跳转到 DebugDiag 报告中标识的源代码或函数行的命令。

对于 .Net 4.6.x，我非常依赖DebugDiag 2

任何时候生产应用程序出现高 CPU 问题、死锁等问题，我都会使用该工具来捕获 w3svc 的转储，它会打印出一份关于所有线程正在做什么的漂亮报告。他们可能正在等待 3rd 方 API、数据库等。

我想迁移到 asp.net 核心，但如果我有一个 100% CPU 的生产服务器或上面提到的问题，我找不到任何方法可以转储进程中的所有线程并查看它们的堆栈跟踪。

人们如何在没有这种可见性的情况下四处走动？我错过了什么吗？我正在寻找同样适用于 Linux 的解决方案。

我有一个读取特定文件格式的 C++ dll。如果我使用 WPF 应用程序使用这个 dll，它会消耗 1Gb 的内存，但如果我使用 MFC 应用程序使用相同的 dll，它会使用 200Mb 的数据。

我最初的猜测是它在动态内存分配时占用了一些内存，尽管我不确定。我知道没有代码很难猜出可能的罪魁祸首。我只想做任何检查，以确保我没有遗漏任何我应该使用的设置或任何可能有帮助的建议。

是的，我确实尝试了各种配置文件，但没有一个显示任何内存泄漏。

更新：使用 procdump 我可以了解有关内存消耗的更多详细信息。下面是 DebugDiag 分析报告输出的快照。它显示具有 C++ dll 的 WPF 应用程序的虚拟内存消耗为 2.23 GB，而具有 C++ dll 的 MFC 应用程序显示为 60MB。

我正在寻找分析部署在 azure 中的 Web 应用程序的内存泄漏。

参考以下网址

• https://blogs.msdn.microsoft.com/kaushal/2017/05/04/azure-app-service-manually-collect-memory-dumps/
• https://blogs.msdn.microsoft.com/kaushal/2017/05/04/azure-app-service-manually-collect-memory-dumps/

我们能够提取内存转储并分析它们。但由于在收集转储时我们无法注入 LeakTrack dll / 启用内存泄漏跟踪，因此我们收到消息称由于在执行内存分析时未注入 dll 而未执行泄漏分析。

请建议如何在这种情况下通过分析转储找出内存泄漏。

我正在调查我的应用程序中的“访问冲突”异常（c++ native & CLI and .net)。我们在生产中安装了DebugDiag 工具来捕获转储文件，但问题是生成的文件很大（30Gb+）。我们在传输这些文件时遇到了问题生产服务器和工程团队之间（经常损坏）。另外，在生产服务器上消耗大量磁盘空间并不是一个好主意。

我正在寻找一种在不丢失有意义信息的情况下减小转储文件大小的方法（基本上我需要一个准确的调用堆栈，理想情况下是局部变量的值。我需要知道损坏的对象然后我可以调查它是如何发生的被破坏）。

谢谢。

我得到了我的应用程序进程的转储文件。我用 debugdiag 2.0 和 windbg 处理它。但是，我得到了一个不同的线程调用堆栈。所以，我很困惑。

谁能告诉我为什么会这样？

下面是windbg的线程调用栈

下面是debugdiag的线程调用栈

线程 0 - 系统 ID 5984

入口点 IMCM+1e05f 创建时间 2018-04-24 AM 10:54:21 在用户模式下花费的时间 0 天 00:00:00.125 在内核模式下花费的时间 0 天 00:00:00.046

该线程尚未完全解决，可能是也可能不是问题。可能需要对这些线程进行进一步分析。

我们的生产应用程序池（IIS 8.0-8-5、.Net 4.5 集成管道）设置为每天回收，这在短期内不太可能改变。

有没有办法防止 DebugDiag (2.2.0.14) 此时创建转储并耗尽我们的磁盘存储？

我最近第一次开始使用 .NET，并负责在基于 Web 的程序中定位内存泄漏。在尝试了各种不同的方法并使用了许多工具后，我发现了 Debugdiag，它看起来很有希望。当我在程序的转储上运行它时，我得到了很多难以破译的信息，但吸引我眼球的是如下示例所示的片段：

特别是，“泄漏概率”听起来与我的搜索相关。但是，我无法在任何地方找到它的确切定义，以知道我是否走在正确的轨道上。

这是否意味着这个函数极有可能导致内存泄漏，因为它的泄漏概率如此之高？如果是这样，我如何确认它以及如何追踪它发生的位置？

任何帮助或方向将不胜感激！

我有一个已经存在多年的 .NET Framework 4 ASP.NET 应用程序（WebForms 和 MVC 的组合）。在过去的几个月里，应用程序会突然停止响应，应用程序池将开始使用 99% 的 CPU 和 3gb（！）的 RAM。这种情况大约每 2 周发生一次，尽管今天发生了两次。

通常我们会终止进程并重新启动可以运行的应用程序池，但是我们现在已经使用 DebugDiag 进行了转储以尝试找出问题的根源。但是我无法找出问题所在 - 主要原因是垃圾收集器似乎正在运行或处于异常状态 - '！dumpheap'给了我以下信息

我已经运行了 ~*e !clrstack 并得到了很多输出，几乎每个线程都显示“System.Threading.Monitor.ReliableEnter”......这是正常的吗？

我只是想知道是否有人知道基于上述内容，或者有任何关于分析这个转储文件的提示？转储是一个完整的转储，所以它大约 3gb

我在下面粘贴了我的 clrstack 输出，以防万一有人看中！

https://pastebin.com/dBE5VAYJ