7

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

有问题的场景是一个 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 出于某种原因无法检索它?

4

3 回答 3

3

最终,这个问题自己解决了。我向微软发送了一个问题,他们说 DebugDiag 1.1 不支持 .NET 4+。他们不久前发布了 v1.2,确实如此 - 再次像魅力一样工作:

http://www.microsoft.com/en-us/download/details.aspx?id=26798

于 2014-02-17T16:29:16.553 回答
0

假设您正在进行完整转储,这可能与它如何共同定位 sos 有关。在 3.5 下,它将使用 mscorlib 共同定位,而在 CLR 4 下,它将使用 clr 共同定位。这将取决于编写 debugdiag 以适应 CLR 4 的人。

于 2013-06-13T21:48:29.470 回答
0

我遇到了同样的问题,对我来说,它有助于从 DebugDiag 的子目录“exts”中删除 psscor4.dll

在 DebugDiag 报告中,我的 CLR 运行时现在显示为:

CLR Information

CLR version = 4.0.30319.18052

CLR Debugger Extension = C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dll

PS:请注意使用正确版本的 DebugDiag(32 位与 64 位)。

于 2013-07-17T05:09:36.217 回答