在转储使用SOS与.NET 2（mscorwks）和.NET 4（CLR） [英] Using SOS in a dump with .NET 2 (mscorwks) and .NET 4 (clr)

问题描述

我有一个既具有.NET版本加载转储：

I have a dump which has both .NET versions loaded:

0:000> lm m clr
start    end        module name
65490000 65aff000   clr        (deferred)             
0:000> lm m mscorwks
start    end        module name
6a980000 6af2c000   mscorwks   (deferred) 

现在我不确定版SOS要使用的。双方将加载没有问题。

Now I'm uncertain which version of SOS to use. Both will load without problems.

0:000> .loadby sos mscorwks
0:000> .loadby sos clr

我将如何找出使用最适合我的分析是哪个版本？或者将我永远都需要？

How would I find out which version to use best for my analysis? Or will I always need both?

时.cordll -ve -u -l在这种情况下，可靠的？

Is .cordll -ve -u -l reliable in this case?

.symfix c:\symbols
.cordll -ve -u -l

CLRDLL: C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscordacwks.dll:4.0.30319.18047 f:8
doesn't match desired version 4.0.30319.296 f:8
CLRDLL: Loaded DLL c:\symbols\mscordacwks_x86_x86_4.0.30319.296.dll\50484AA966f000\mscordacwks_x86_x86_4.0.30319.296.dll
CLR DLL status: Loaded DLL c:\symbols\mscordacwks_x86_x86_4.0.30319.296.dll\50484AA966f000\mscordacwks_x86_x86_4.0.30319.296.dll

主题0显示mscorwks。使用命令：

Thread 0 shows mscorwks. Commands used:

~0s
k

===更新===

=== UPDATE ===

.cordll 在原则上就可以了。默认情况下，将使用.NET 4的框架。这种行为可以通过 .cordll -I修改。

.cordll in principle is ok. By default it will use .NET 4 framework. This behavior can be changed by .cordll -I.

我已经获得SOS的相匹配的目标计算机的两个版本，并通过路径加载

I have obtained both versions of SOS which match that of the target computer and loaded by path

.load C:\SOS\4.0.30319.296\SOS.dll

我已经升级，从WinDbg的6.2到最新的6.3。仍然没有更好的。

I have upgraded from WinDbg 6.2 to latest 6.3. Still not better.

我也问史蒂夫·约翰逊，SOSEX的作家谁建议 .cordll -I ，但是这也并不在我的转储工作，既不符合模块名，也不符合基址。

I have also asked Steve Johnson, the author of SOSEX who suggested .cordll -I, but this also does not work in my dump, neither with module name nor with base address.

.cordll -I clr
.cordll -I 65490000

运行任何企图！线程结果总是在

无法要求ThreadStore。

Failed to request ThreadStore.

运行任何企图！clrstack 结果总是在

无法行走的管理堆栈。当前线程可能不是托管线程。您可以运行！线程来获得在这个过程中管理的线程的列表。

Unable to walk the managed stack. The current thread is likely not a managed thread. You can run !threads to get a list of managed threads in the process.

===更新===

所建议的马里奥Hewardt，可避免只装入一张SOS扩展到过程（或者在卸载一个，他们已经加载），或者我们可以使用 .setdll 来定义我们喜欢默认的SOS版本。

As suggested by Mario Hewardt, the complex scenario with specifying the full SOS path can be avoided by only loading one SOS extension into the process (or unloading one in case they are already loaded) or we can use .setdll to define the default SOS version we like.

然而，这并不能改善分析

However, this does not improve the analysis.

===更新===

我也试图通过 .reload的/ U 卸载.NET模块之一，希望WinDbg中/ SOS不会在冲突更多，但仍没有运气。

I have also tried unloading one of the .NET modules by .reload /u in the hope that WinDbg/SOS would not be in a conflict any more, but still no luck.

推荐答案

这是一个非常难看的问题，AFAIK有没有为它简单的解决方案。核心问题是，你的客户使用不同的版本比你做的CLR。对于某些赔率，考虑到非常不同的版本号，你已经得到了.NET 4.5安装客户正在使用.NET 4.0。但是，仅仅一个安全补丁就足以造成不匹配，他们已经进来稳步晚了。

This is a very ugly problem and afaik there is no simple solution for it. The core issue is that your customer uses a different revision of the CLR than you do. With some odds, given the wildly different revision numbers, that you've got .NET 4.5 installed and the customer is using .NET 4.0. But just a security patch can be enough to cause a mismatch, they've been coming in steadily of late.

AFAIK你是pretty的多卡设置使用了的确切的同一版本作为您的客户使用虚拟机或机器。

Afaik you are pretty much stuck setting up a VM or machine that uses the exact same revision as your customer uses.

在.NET 4的过程中的并排侧CLR功能，可以以其他方式解释如何，你可以在一个进程个CLR版本结束了。在V2.0版本通常在那里实现一个COM服务器。有些事情，你可以避免通过添加参考[标记有ComVisible特性] .NET程序集来代替。虽然它可能不是你的code，这是否。祝你好运吧，不是一个很好的问题有。

The in-process side-by-side CLR feature in .NET 4 can otherwise explain how you could end up with two CLR versions in one process. The v2.0 version would typically be there to implement a COM server. Something you avoid by adding a reference to the [ComVisible] .NET assembly instead. Albeit that it may well not be your code that does this. Good luck with it, not a nice problem to have.

这篇关于在转储使用SOS与.NET 2（mscorwks）和.NET 4（CLR）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！