标签: debugdiag

我正在尝试使用WinDBG来分析我们的一台生产机器的崩溃转储.我的问题的根源似乎是我有一个不同于生产机器的.NET框架版本,只是我不知道如何解决问题.当我转!sym吵闹然后运行!dlk(来自SOSEX)我得到以下错误,因为它试图找到mscordacwks dll

0:000> !dlk
CLRDLL: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscordacwks.dll:2.0.50727.3623 f:0
doesn't match desired version 2.0.50727.3607 f:0
SYMSRV:  c:\mysymbols\mscordacwks_x86_x86_2.0.50727.3607.dll\4ADD5446590000\mscordacwks_x86_x86_2.0.50727.3607.dll not found
SYMSRV:  http://msdl.microsoft.com/download/symbols/mscordacwks_x86_x86_2.0.50727.3607.dll/4ADD5446590000/mscordacwks_x86_x86_2.0.50727.3607.dll not found
SYMSRV:  c:\mysymbols\mscordacwks_x86_x86_2.0.50727.3607.dll\4ADD5446590000\mscordacwks_x86_x86_2.0.50727.3607.dll not found
SYMSRV:  c:\mysymbols\mscordacwks_x86_x86_2.0.50727.3607.dll\4ADD5446590000\mscordacwks_x86_x86_2.0.50727.3607.dll not found
SYMSRV:  http://msdl.microsoft.com/download/symbols/mscordacwks_x86_x86_2.0.50727.3607.dll/4ADD5446590000/mscordacwks_x86_x86_2.0.50727.3607.dll not found
SYMSRV:  c:\mysymbols\mscordacwks_x86_x86_2.0.50727.3607.dll\4ADD5446590000\mscordacwks_x86_x86_2.0.50727.3607.dll not found
CLRDLL: Unable to find mscordacwks_x86_x86_2.0.50727.3607.dll by mscorwks search
CLRDLL: Unable to find 'mscordacwks_x86_x86_2.0.50727.3607.dll' on the path
SYMSRV:  c:\mysymbols\mscorwks.dll\4ADD5446590000\mscorwks.dll not found
SYMSRV:  http://msdl.microsoft.com/download/symbols/mscorwks.dll/4ADD5446590000/mscorwks.dll not found
SYMSRV:  c:\mysymbols\mscorwks.dll\4ADD5446590000\mscorwks.dll not found
DBGHELP: C:\Program Files\Debugging Tools for Windows (x86)\mscorwks.dll - file not found
SYMSRV:  c:\mysymbols\mscorwks.dll\4ADD5446590000\mscorwks.dll not found …

这是我第一次使用.dmp文件调试或执行任何操作.我正在使用Debugdiag.当我运行我的分析时,我得到这个错误 -

Analysis results may be incomplete because an error occurred while initializing the CLR diagnostic runtime for w3wp.DMP.

Dump File:  w3wp.DMP

Type:  DebugDiag.DotNet.DacNotFoundException

Message:  CLR is loaded in the target, but the correct dac file cannot be found. DacFileName: mscordacwks_Amd64_Amd64_10.0.30319.01.dll. DacLocation: 

它说要解决这个问题,我必须这样做:

To fix this problem, you can copy mscordacwks.dll from the server where the dump was taken and rename it to mscordacwks_Amd64_Amd64_10.0.30319.01.dll and add the path of the folder to the Symbol server path by going to Tools-> …

我有一个C++ DLL读取特定的文件格式.如果我使用WPF应用程序使用此DLL它会占用1Gb的内存,但如果我使用相同的dll使用MFC应用程序它使用200Mb的数据.

我最初的猜测是在动态内存分配时需要一些内存,尽管我不确定.我知道很难猜测没有代码可能的罪魁祸首.我想要的是我可以做的任何检查,以确保我没有错过任何我应该使用的设置或任何可能有帮助的建议.

是的,我尝试了各种配置文件,没有一个显示任何内存泄漏.

更新:使用procdump我会了解有关内存消耗的更多细节.以下是DebugDiag分析报告输出的快照.它显示了使用C++ DLL的WPF应用程序的2.23 GB的虚拟内存消耗,而对于使用C++的MFC应用程序,它显示了60MB.

感觉就像这可能是一个简单的答案,但我一直无法找到它.

有问题的场景是C#.NET控制台应用程序.

我通常使用DebugDiag 1.2来检查来自我们经历的挂起的.dmp文件 - 通常是线程锁定问题.它们是使用DebugDiag的"Create Full Userdump"选项创建的.

我最近开始编译面向.NET 4的应用程序,准备开始使用.NET 4的一些功能.但是,我注意到在使用DebugDiag分析这些.dmp文件时,缺少所有.NET堆栈信息.

如果我将CLR目标更改回.NET 3.5,并从新的可执行文件中捕获.dmp,那么.NET调用堆栈信息就在那里.

当我查看DebugDiag的输出时,我看到一条说明:

CLR信息

CLR版本= 4.0.30319.17929 CLR调试器扩展= C:\ Program Files\DebugDiag\Exts\psscor4.dll

.NET线程摘要

无法请求ThreadStore

我认为"无法请求ThreadStore"是问题的关键,因为.NET 3.5 .DMP文件(使用psscor2.dll)报告"Threads Summary"标题下的所有线程信息.

是.dmp缺少信息的问题,还是DebugDiag由于某种原因无法检索它？

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

任何时候生产应用程序有高CPU问题,死锁等,我会使用该工具捕获w3svc的转储,并打印出一个很好的报告,说明所有线程正在做什么.他们可能正在等待第三方api,数据库等.

我想转移到asp.net核心,但如果我有一个生产服务器w/100%cpu或上面提到的问题,我无法找到你可以转储进程中的所有线程并看到他们的堆栈跟踪.

如何让人们无法获得这种可见性？我错过了什么吗？我正在寻找一种适用于Linux的解决方案.

我正在尝试调试 Windows 2012 R2 服务器上的 IIS 应用程序池中的高 CPU 使用率。我已经安装了 DebugDiag v2 Update 3 并在其 CPU 使用率超过指定阈值时收集了 IIS 应用程序池的转储。

我能够生成 11 个转储 - 10 个小型转储和 1 个完整转储。但是，当我打开 DebugDiag 分析工具并加载任何（或所有）转储文件并执行 PerfAnalysis 时，无论我尝试什么，它总是失败并显示错误 System.ArgumentException。我已尝试多次执行此操作，但每次尝试分析文件时仍会遇到相同的错误。

有没有人能够成功地进行性能分析？我尝试了崩溃分析，它似乎工作正常；只有性能分析出错了。

这是我每次尝试进行 PerfAnalysis 时看到的那种错误：

当我尝试使用 DebugDiag 2.1 对转储文件进行性能分析时，我收到 NullReferenceException，报告​​中包含以下堆栈跟踪：

DebugDiag.AnalysisRules.CDumps.DoVersionsMatch(String& v1, String& v2)
DebugDiag.AnalysisRules.CDumps.SomeDotNetImageFilesAreMissingOrMismatched(NetDbgObj debugger)
DebugDiag.AnalysisRules.CDumps.SaveModulesAndAppendExePaths()
DebugDiag.AnalysisRules.PerfAnalysis.VerifyAndSortDumps()
DebugDiag.AnalysisRules.PerfAnalysis.RunAnalysisRule(NetScriptManager manager, NetProgress progress)

正在分析的应用程序正在运行 .Net 4.5.2。有没有人有办法解决吗？

最近我开始面对几个服务器上的问题,其中CPU开始消耗比平常趋势更多的资源.我试图找出这个的根本原因并从任务管理器转移w3wp进程(右键单击进程并进行转储).

现在dmp文件大小是14GB,我试图通过WinDBG分析它,但该工具无法正常工作并获取消息:

我也拿了几个minidumps,但是其中一些打开很好,而很少不是这样,它与32位或64位之间的混淆无关.(收集的转储是64位).我想知道造成这个问题的原因.它是文件大小还是我没有正确地进行转储.
我检查了链接,但没有用.

我不完全确定去哪里寻求帮助，所以我想我会尝试 stackoverflow，因为它通常可以回答我所有编程相关问题的大约 90%。

简而言之，我有一个正在泄漏内存的开源 .NET 应用程序。从某种意义上说，这可能不是真正的内存泄漏，当应用程序关闭时，我怀疑内存被回收，但在它运行时，它不断分配更多内存而不释放它。最终，aSystem.OutOfMemoryException被抛出。

为了调试问题，我按照本文推荐的步骤操作，并生成了下图，其中红色是 .NET/CLR 内存“#Bytes in all Heaps”，绿色是带有 Windows 性能监视器工具的进程“Private Bytes” （请注意，绿线已按比例缩小以更接近红线，因为只有线条的形状对我很重要）：性能监视器输出。

我将图像作为托管内存泄漏的证据，然后使用 Windows 的调试诊断工具来尝试定位泄漏源（如文章中所述）。然而，我从 Debug Diagnostic Tool 得到的报告非常奇特。

基本上，我在应用程序运行时每 5 秒尝试收集一次“完整 UserDump”的每次尝试都被垃圾收集器当时始终处于垃圾收集周期的中间这一事实所挫败，导致调试诊断输出错误并防止其收集任何有用的 .NET 内存相关信息的工具。

现在我被卡住了，我知道我有一个托管内存泄漏，但我不知道如何缩小它的范围。我也对垃圾收集器如何总是处于收集周期的中间感到困惑，这让我想知道垃圾收集线程是否以某种方式被阻塞，阻止它释放内存和/或退出垃圾收集周期。

性能监视器图的某些部分分配的 .NET 内存略有下降，因此垃圾收集器不会永远卡住，但大部分时间肯定都卡住了，否则调试诊断应该能够做到用户转储。

几个问题：

1. .NET 应用程序中的垃圾收集器是否有可能在尝试释放一些内存时卡住，也许是从一些编码不佳的析构函数/终结器或其他东西？

2. 我可以使用什么策略来继续缩小问题的来源？

我们的应用程序池每天循环多次。我很确定这是因为它达到了内存限制。我也很确定它不应该达到 ~3GB 的内存限制。我尝试使用 WinDbg 来分析内存转储，但收效甚微。我可能稍后再试。然而，使用 DebugDiag 为我提供了一些很好的数据可视化效果，并且已经导致了一些减少回收次数的变化。一份让我有点困惑和担心的报告是 HttpContext 报告。它显示了一些这样的输出：

HttpContext Timeout Completed RunningSince ThreadId ReturnCode Verb RequestPath+QueryString 
0x02374c94 110 Sec  No        995 Sec      ---      302        GET   /Loans/Details/529146/517006  
0x02472a44 110 Sec  No        993 Sec      ---      200        GET   /Login ReturnUrl=%2fLoans%2fDetails%2f529146%2f517006 
0x024d2f94 110 Sec  No        979 Sec      ---      302        POST  /Loans/UpdateDealer  
0x025773c0 110 Sec  No        951 Sec      ---      302        GET   /Applicants  
0x025d6bb4 110 Sec  No        951 Sec      ---      200        GET   /Login ReturnUrl=%2fApplicants 
0x025f5adc 110 Sec  No        935 Sec      ---      302        GET   /Applicants/Details/537358  
0x02654708 …

我有一个 6GB 的转储文件，用于我生成的 IIS 进程，在处理的“运行分析”阶段，我在 60 秒限制后从工具收到“因超时取消”消息。

有没有办法增加超时？

我有一个来自生产的故障转储来识别内存泄漏。当我使用 DebugDiag (v2 update 2) 时，我得到一个报告

DebugDiag 未检测到加载在 w3wp.DMP 中的 LeakTrack.dll，因此未对该文件执行泄漏分析。如果您正在对内存泄漏进行故障排除，请确保在生成新转储之前使用 DebugDiag 工具将 LeakTrack.dll 注入目标进程

. 我无法找到从 DebugDiag UI 或通过文档后注入 LeakTrack.dll 的方法。如何手动注入 LeakTrack.dll？