感觉就像这可能是一个简单的答案，但我找不到它。
有问题的场景是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 version = 4.0.30319.17929 CLR Debugger Extension = C：\ Program 文件\ DebugDiag资料\ EXTS \ psscor4.dll
.NET主题摘要
无法请求ThreadStore
我认为“无法请求ThreadStore”是问题的关键，因为.NET 3.5 .DMP文件（使用psscor2.dll）报告“Threads Summary”标题下的所有线程信息。
问题是.dmp缺少信息，或者DebugDiag由于某种原因无法检索它？
答案 0 :(得分：2)
最终，这个解决了自己。我向微软发了一个问题，他们说DebugDiag 1.1不支持.NET 4+。他们不久前发布了v1.2，这确实 - 再次像魅力一样：
http://www.microsoft.com/en-us/download/details.aspx?id=26798
答案 1 :(得分：0)
假设您正在进行完全转储，这可能与它如何共同定位sos有关。在3.5以下它将使用mscorlib共同定位，而在CLR 4下它将使用clr共同定位。这将取决于编写debugdiag的人是否容忍CLR 4。
答案 2 :(得分：0)
我遇到了同样的问题，对我而言，它有助于从DebugDiag的子目录“exts”中删除psscor4.dll
在DebugDiag-Report中，我的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位）。