问题标签 [debugdiag]

我正在尝试使用 WinDBG 分析来自我们的一台生产机器的故障转储。我的问题的根源似乎是我的 .NET 框架构建与生产机器不同，只是我不知道如何解决这个问题。当我打开 !sym 嘈杂然后运行 ​​!dlk(from SOSEX) 时，我收到以下错误，因为它试图找到 mscordacwks dll

我从生产机器中取出 mscorwks.dll、mscordawks.dll 和 sos.dll 并将它们放在 C:\mysymbols 中。看起来 WinDBG 正在寻找 mscorwks dll 内的 dll。

我使用的是 Windows 2008 R2，CPU 为 100%。我在负责的应用程序池上运行了 DebugDiag，并发现了以下调用堆栈：

我的问题是我想弄清楚是什么组件产生了这个线程，所以我知道这个线程是来自 Telerik 应用程序，还是由我们的开发人员创建的某个东西控制。

如何确定是什么对象产生了这个线程？

我有一个 Web 应用程序，有时它挂起/执行非常慢。我使用 DebugDiag 进行了完整转储，并尝试使用 Crash/Hang 分析对其进行分析。

总结告诉我，我 7.86% 的线程 (10) 被阻塞并等待Monitor.Wait.

但是，当我使用线程检查调用堆栈/堆栈跟踪时，输出以下内容：

它实际上并没有告诉我他们正在等待获得哪个锁 - 关于如何获取这些信息的任何想法？

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

当然，报告中还有更多行。我真的有运行了 995 秒（约 15 分钟）但仍未完成的请求吗？他们只是挂在那里吗？他们在等待其他事情完成吗？我不确定我什至可以相信它，更不用说开始诊断它了。其他人可以给我一些关于如何解释这些数据的见解吗？

我有一个 .Net 4.0 WPF 应用程序，它有时似乎挂起（每天 1-2 次）。该应用程序与监视用户活动有关，因此使用了许多本机调用（例如 EnumWindows、GetForegroundWindow、GetLastInputInfo 等）。该应用程序还使用 SQL Server CE 4.0 数据库来存储一些信息。

我已经设法从这些挂起的 4 到 5 个中获得崩溃转储，它们看起来都非常相似，但我仍在努力找出问题的原因。

我在下面包含了对最新故障转储的 DebugDiag 分析结果。在此之前大约 20 秒的故障转储显示了完全相同的结果。由此看来，有 2 个线程导致其他线程等待它们。

17 - 该线程正在向 CE 数据库中插入一些数据。我看不出这个线程会挂起的任何原因。

22 - 我不知道这个线程在堆栈跟踪中做了什么。

该应用程序在多个地方大量使用 System.Threading.Tasks 来启动任务以处理各种事件，因此可能会有相当多的线程。从一些阅读来看，Thread 22 似乎是 LoaderLock 问题，但我通过 DllImport 使用标准 Windows API 调用，并且没有任何自定义 c++ 代码（这似乎通常会导致此问题）。

任何建议或指示将不胜感激，因为此刻我有点卡住了！

我无法发布完整的 DebugDiag 结果，因为它太大了，但这里是最重要的部分：

感觉这可能有一个简单的答案，但我一直找不到。

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

我通常使用 DebugDiag 1.2 来检查来自我们遇到的挂起的 .dmp 文件——通常是线程锁定问题。它们是使用 DebugDiag 的“创建完整用户转储”选项创建的。

我最近开始编译面向 .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 线程摘要

请求线程存储失败

我认为“请求线程存储失败”是问题的关键，因为 .NET 3.5 .DMP 文件（使用 psscor2.dll）报告了“线程摘要”标题下的所有线程信息。

.dmp 是否缺少信息，或者 DebugDiag 出于某种原因无法检索它？

可能这是正常情况，但我很困惑。

我正在从 Visual Studio 运行我的 C# 调试应用程序。DebugDiag 设置为自动附加到进程。

我有一条规则可以从此应用程序收集故障转储，并且该规则定义未配置的第一次机会异常的操作应为“无”。

但是当应用程序崩溃时，当我查看转储文件时，它说存在第一次机会异常。

从这个 SO question的答案中，我了解到“异常首先被抛出给调试器，然后被抛出到实际程序，如果它没有被处理，它会再次被抛出给调试器”

那么为什么 DebugDiag 会为第一次机会异常收集转储文件呢？

编辑为了清楚起见，我不想在这里修复损坏的代码。我试图理解为什么 DebugDiag 告诉我第一次机会异常导致我的代码崩溃。当然，根据定义，只有第二次机会异常会导致代码崩溃，即代码未处理的异常？

“崩溃”意味着进程终止并且 DebugDiag 生成崩溃转储文件。我在“Start without Debugging”上运行代码的调试版本

一年多以前，我已经使用 WinDbg 和 DebugDiag 来查找我们在 Java 中使用的 JNI 本机 DLL 中的内存泄漏。现在我正在寻找线程句柄泄漏。我使用 Process Explorer 创建了一个内存转储，并尝试在 DebugDiag 中对其进行分析，但我得到的只是脚本错误：

我也尝试过 WinDbg，但它不再能够附加到进程。我总是收到错误消息“dbghelp.dll 的版本与调试器不匹配”：（ “Unbekannter Fehler”的意思是“未知错误”）

我卸载了 DebugDiag 和 Windows SDK，然后下载了最新版本并安装了 Windows SDK 8 和 DebugDiag 1.2 (x86)。问题保持不变。即使将 Windows SDK 替换为 7.1 版（Windows 7 的最新 SDK），也没有任何变化。

我正在使用一台装有 Windows 7（32 位）的机器。

我假设 DebugDiag 中的问题与 WinDbg 中的问题具有相同的原因。但我不明白版本不匹配是什么意思（谷歌搜索也没有帮助）：

• WinDbg：6.12.0002.633
• 数据库：6.12.0002.633
• 数据库帮助：6.12.0002.633

我怎样才能让 WinDbg（并希望 DebugDiag）再次工作？

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

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

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

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

基本上，每次尝试在应用程序运行时每 5 秒收集一次“完全 UserDump”，但由于当时垃圾收集器始终处于垃圾收集周期的中间，导致调试诊断输出错误并阻止它收集任何有用的 .NET 内存相关信息的工具。

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

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

几个问题：

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

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

当第一次发生 OutOfMemoryException 时尝试使用 DebugDiag 进行转储时，我遇到了一个问题。所以我写了一个应用程序，我可以用它来创建内存不足的情况，并按照以下说明进行操作：

http://blogs.msdn.com/b/kaushal/archive/2012/05/09/using-debugdiag-to-capture-a-dump-on-first-chance-exception.aspx

但我没有第一次转储，我只是获得第二次转储。当我查看来自 DebugDiag 的日志文件时，我得到以下信息：

然后后来我得到这个：

最后我得到了

貌似可以获取异常对象的地址，为0，所以脚本调用DumpObject时找不到异常信息。

我阅读这些日志条目的方式是我从 malloc 或其他东西中获得原生的第一次机会异常，然后跟进 OutOfMemoryException 的 CLR 异常。我试图弄清楚第二个第一次机会异常是什么，我的代码如下所示：

此代码是从 WPF 按钮上的命令触发的。因此，源自此代码的任何异常都应导致 TargetInvocationException，我认为这是第一次机会异常中的第二个。最后来自 throw 块的是第二次机会异常，其类型为 TargetInvocationException。

所以我开始查看第二次机会转储文件。我将它加载到 windbg 中，然后发出以下命令：

我可以看到，我的上述假设得到了第二次机会异常是 TargetInvocationException 这一事实的支持，但是为什么 DebugDiag 不能获取 CLR 异常类型呢？对于健全性检查，我尝试进行实时调试会话。所以我启动应用程序并附加，然后发出这些命令。

这是完全软管。于是我开始研究这个问题。

此 url 表明它可能是多个 CLR 实例：

http://blogs.msdn.com/b/jjameson/archive/2011/01/11/issues-debugging-managed-code-in-windbg-with-sos-and-psscor2-eg-quot-failed-to-请求-threadstore-quot.aspx

所以我发出这些命令：

这对我来说很奇怪，我认为从 4.0 开始，mscorwks 就被 clr 抛弃了。mscordacwks 是 4.5 吗？

我发出了这个命令：

但是 clr 已加载：

所以我认为我没有加载多个 CLR。

因此，我假设导致我的实时调试问题的同一件事是导致我未能在第一次机会问题上触发。有任何想法吗？