如何处理“SOS 版本与您正在调试的 CLR 版本不匹配”在WinDbg中?

发布于 2024-12-04 21:02:41 字数 1960 浏览 1 评论 0 原文

我的某些应用程序出现问题。这是一个基于 wcf 的应用程序,在 Windows 2003 Server (x86) 的 IIS6 下运行:
在事件日志中,我从“W3SVC-WP”源(EventID=2262)收到这样的错误:

ISAPI 'C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll' reported itself as unhealthy for the following reason: 'Deadlock detected'.

我正在尝试弄清楚发生了什么。我已按照知识库中所述设置为孤立工作进程创建转储。 当发生死锁时,会创建一个小型转储。
然后我用这个小型转储来尝试了解发生了什么。我被困住了。

我运行 WinDbg x86,打开我的转储,然后:

0:037> .loadby sos clr
0:037> .sympath SRV*c:\temp\symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*c:\temp\symbols*http://msdl.microsoft.com/download/symbols
Expanded Symbol search path is: srv*c:\temp\symbols*http://msdl.microsoft.com/download/symbols
0:037> !clrstack
The version of SOS does not match the version of CLR you are debugging.  Please load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.1
SOS Version: 4.0.30319.235
CLRDLL: C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\mscordacwks.dll:4.0.30319.235 f:8 doesn't match desired version 4.0.30319.01 f:8
CLRDLL: Loaded DLL c:\temp\symbols\mscordacwks_x86_x86_4.0.30319.01.dll\4BA1D9EF66f000\mscordacwks_x86_x86_4.0.30319.01.dll
OS Thread Id: 0x690 (37)
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

如何处理此错误 - “SOS 版本与您正在调试的 CLR 版本不匹配”?

当我在 VS2010 中打开小型转储时,出现同样的错误(“SOS 版本与您正在调试的 CLR 版本不匹配”)。

我读过这篇文章 - http://tech-thinker.com/Forums/tabid/62/forumid/12/postid/471/scope/posts/Default.aspx,并尝试安装KB2518870。这没有帮助。

I'm having a problem with some of my apps. It's a wcf-based app running under IIS6 in Windows 2003 Server (x86):
In Event Log I get such an error from "W3SVC-WP" source (EventID=2262):

ISAPI 'C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll' reported itself as unhealthy for the following reason: 'Deadlock detected'.

I'm trying figuring out what's going on. I've set up creating dump for Orphan Worker Process as described in this KB.
When an deadlock occured a minidump is created.
Then I take this minidump to try to understand what's happened. Here's I'm stuck.

I run WinDbg x86, open my dump and then:

0:037> .loadby sos clr
0:037> .sympath SRV*c:\temp\symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*c:\temp\symbols*http://msdl.microsoft.com/download/symbols
Expanded Symbol search path is: srv*c:\temp\symbols*http://msdl.microsoft.com/download/symbols
0:037> !clrstack
The version of SOS does not match the version of CLR you are debugging.  Please load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.1
SOS Version: 4.0.30319.235
CLRDLL: C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\mscordacwks.dll:4.0.30319.235 f:8 doesn't match desired version 4.0.30319.01 f:8
CLRDLL: Loaded DLL c:\temp\symbols\mscordacwks_x86_x86_4.0.30319.01.dll\4BA1D9EF66f000\mscordacwks_x86_x86_4.0.30319.01.dll
OS Thread Id: 0x690 (37)
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

What to do with this error - "The version of SOS does not match the version of CLR you are debugging" ?

The same error ("The version of SOS does not match the version of CLR you are debugging") I'm getting when I open the minidump in VS2010.

I've read this post - http://tech-thinker.com/Forums/tabid/62/forumid/12/postid/471/scope/posts/Default.aspx, and tried installing KB2518870. It doesn't help.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

成熟稳重的好男人 2024-12-11 21:02:41

这对我有用:

下载以下 DLL:

  • clr.dll
  • mscordacwks.dll
  • SOS.dll:

从生成转储的计算机上的此文件夹

C:\Windows\Microsoft.NET\Framework64\v4.0.30319

运行以下命令。 SOS.DLL 的路径应该不带引号、未转义的路径分隔符:

.load 下载的 SOS.DLL 的路径

我认为需要一个新的 WinDbg 会话才能正常工作。

This is what worked for me:

Download the following DLLs:

  • clr.dll
  • mscordacwks.dll
  • SOS.dll

from this folder on the machine that generated the dump:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319

Run the following command. The path to SOS.DLL should be without quotes, unescaped path delimiters:

.load path to downloaded SOS.DLL

I think a new WinDbg session is required for this to work.

ま昔日黯然 2024-12-11 21:02:41

WinDbg 将无法使用调试适配器 mscordacwks.dll,除非它与原始计算机的版本相同。您可以通过将此 DLL 从生成转储的目标计算机复制到 Windows 调试工具目录来解决此错误。

我们使用 WinDbg 调试 .NET 2.0 应用程序。关于 mscordacwks_x86_x86_2.0.50727.3615.dll,我们会不断收到同样的错误。我必须将此文件从服务器复制到我的客户端,并将其放入 C:\Program Files\Debugging Tools for Windows (x86)\ 文件夹中。从那以后WinDbg就不再抱怨了。

如果所有其他方法均失败,您可以尝试在检索故障转储的同一服务器上使用 WinDbg 进行调试。

WinDbg will not be able to use the debugging adapter mscordacwks.dll unless it is the same version as the one from the original machine. You can get around this error by copying this DLL from the target machine which generated the dump to your Debugging Tools for Windows directory.

We debug .NET 2.0 applications with WinDbg. We would continually get this same error regarding mscordacwks_x86_x86_2.0.50727.3615.dll. I had to copy this file from the server onto my client and put it in the C:\Program Files\Debugging Tools for Windows (x86)\ folder. WinDbg stopped complaining after that.

If all else fails, you can try debugging with WinDbg on the same server from which you retrieved the crash dump.

兮子 2024-12-11 21:02:41

核心问题通常在于 mscordacwks.dll 版本不匹配(如果进行完整转储,则不需要 mscorwks.dll 本身)。理论上,它应该可以从符号服务器实现 - 只需运行 .cordll -ve -u -l 即可。有关 mscordacwks.dll 的详细信息,请参阅无法加载数据访问 DLL, 0x80004005” – 或者 – 什么是 mscordacwks.dll

不幸的是,某些版本的 mscordacwks.dll 尚未建立索引,这意味着上述内容并不总是有效。在这种情况下,您可以尝试从进行转储的计算机获取正确的版本,如 Yocahi托马斯提到(例如来自C:\Windows\Microsoft.NET\Framework64\v4.0.30319)。获取后,发出以下命令来加载它:.cordll -u -ve -lp PathToFolderContainingMscorDAC。当然,该机器可能无法访问,或者自转储以来它可能已被修补。

幸运的是,有一个 从实际更新 KB 包中提取 mscorwdacwks.dll 的方法(它驻留在 self 内的 cab 文件之一中)提取可执行文件 - 使用诸如 7-Zip 之类的工具来提取它)。还有 .NET 更新存储库(由 MS 员工 Doug Stewart 提供),因此您可以浏览它们以获取所需的确切内部版本号:

一旦您拥有正确的 mscordacwks.dllSOS.dll 警告在大多数情况下可以忽略,因为尽管有警告,最新的 SOS.dll 版本在大多数情况下都可以工作。但是,在某些情况下,还需要正确的 SOS.dll 版本(并且作为奖励,您可以摆脱讨厌的警告)。 Dunken 链接到 博客文章 在这方面应该有所帮助(基本上,您需要将符号服务器放置在 _NT_SYMBOL_PATH 环境变量中并运行 !analyze –v 不先加载 SOS.dll - 它会自行加载正确的版本)。如果这不起作用,您可以尝试如上所述从更新包之一中提取 SOS.dll此网站可能更容易用于此目的,因为它专门索引 SOS.dll 版本。

最后,考虑 PsscorR2 (适用于 .NET 2.0- 3.5) 和 Psscor4(适用于 .NET 4.0)。 PsscorSOS.dll 的超集,只要您使用适当的主要版本,它就不会抱怨版本不匹配。应该注意的是,随着时间的推移,它的维护程度不如 SOS.dll,因此后者可能包含前者所没有的增强功能和错误修复。在撰写本文时,.NET 4.5 还没有 Psscor 版本。

The core problem usually lies with a mismatching mscordacwks.dll version (mscorwks.dll itself should not be needed if a full dump was taken). In theory, it should be attainable from the symbol server - simply run .cordll -ve -u -l. For more information on mscordacwks.dll see Failed to load data access DLL, 0x80004005” – OR – What is mscordacwks.dll.

Unfortunately, some versions of mscordacwks.dll have not been indexed, meaning the above won't always work. In such cases you could try and get the correct version from the machine on which the dump was taken, as Yocahi and Thomas mentioned (e.g. from C:\Windows\Microsoft.NET\Framework64\v4.0.30319). Once you get it, issue the following command to load it: .cordll -u -ve -lp PathToFolderContainingMscorDAC. Of course, that machine may be inaccessible, or it may have been patched since the time the dump was taken.

Fortunately, there is a way to extract mscorwdacwks.dll from the actual update KB package (it resides in one of the cab files inside the self extracting executable - use a tool such as 7-Zip to extract it). There also exist repositories of .NET updates (courtesy of MS employee Doug Stewart), so you can browse them for the exact build number you require:

Once you have the correct mscordacwks.dll, the SOS.dll warning could be ignored in most cases, as the most recent SOS.dll version would work most of the time despite the warning. However, in some cases the correct SOS.dll version is needed as well (and as a bonus you get rid of the pesky warnings). Dunken links to a blog post that should be helpful in that regard (basically you need to place the symbol server in the _NT_SYMBOL_PATH environment variable and run !analyze –v without loading SOS.dll first - it will load the correct version itself). If that doesn't work, you could try extracting SOS.dll from one of the update packages as described above. This site may prove easier to use for that purpose, as it specifically indexes SOS.dll versions.

Finally, consider PsscorR2 (for .NET 2.0-3.5) and Psscor4 (for .NET 4.0). Psscor is a superset of SOS.dll which doesn't complain about mismatched versions, so long as you're using the appropriate major version. It should be noted that over time, it hasn't been maintained as well as SOS.dll, so the latter may include enhancements and bug fixes absent from the former. At the time of writing there was no Psscor version for .NET 4.5.

空名 2024-12-11 21:02:41
The version of SOS does not match the version of CLR you are debugging.  Please load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.1
SOS Version: 4.0.30319.235

这意味着进行转储的目标计算机正在 CLR 版本 4.0.30319.1 上运行。
您的系统正在运行 4.0.30319.235 版本。

这是因为 .Net 4.0 的安全更新更改了 CLRSOS 文件。并且某些计算机可能还没有此更新。

请参阅:http://support.microsoft.com/kb/2572078

这可能会导致堆栈中的某些行有点错误...
您可以通过获取SOS.dllCLR.dll以及mscordacwks.dllmscorwks.dll来避免该错误> 原始版本并在加载 SOS 时加载它们。
原始文件通常位于:C:\Windows\Microsoft.NET\Framework\v4.0.30319
取决于框架版本...然后将它们复制到特定文件夹。
像这样加载正确的文件:

.load C:\CurrectFiles\sos

请注意,它只是“sos”,而不是 sos.dll。

The version of SOS does not match the version of CLR you are debugging.  Please load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.1
SOS Version: 4.0.30319.235

This means the target machine which made the dump is running on CLR version 4.0.30319.1.
Your system is running with version 4.0.30319.235.

This is because there was a security update to .Net 4.0 which changed the CLR and SOS files. And some computers may not have this update yet.

See: http://support.microsoft.com/kb/2572078

This may cause some of the lines in the stack to be a bit wrong...
You can avoid the error by obtaining the SOS.dll and CLR.dll and mscordacwks.dll and mscorwks.dll of the original version and load those when you load the SOS.
The original files are usualy under : C:\Windows\Microsoft.NET\Framework\v4.0.30319
Depends on the framework version... and then copy them to a specific folder.
Load the correct files like this:

.load C:\CurrectFiles\sos

Note that it's just "sos" and not sos.dll.

鱼窥荷 2024-12-11 21:02:41

您可以自动加载正确的 SOS.dll。查看 John Robbins 的精彩博客文章 http:// /wintellect.com/blogs/jrobbins/automatically-load-the-right-sos-for-the-minidump

您还可以使用 .chain 检查已加载的内容。在某些情况下,您必须首先卸载(例如.unload sos)错误加载的dll。

You can automatically load the right SOS.dll. Check out John Robbins' great blog post http://wintellect.com/blogs/jrobbins/automatically-load-the-right-sos-for-the-minidump

You also might to check with .chain what's already loaded. In some cases you have to unload (e.g. .unload sos) the wrongly loaded dlls first.

递刀给你 2024-12-11 21:02:41

简而言之,请执行以下操作:

  1. 从转储中获取 CLR 版本
  2. 查找并下载适当的 Microsoft 补丁
  3. 从补丁中提取 sos.dllmscordacwks.dll
  4. 使用它

下面是一个例子:

1.加载故障转储后,我得到了我需要的版本:

>lm vm clr

它给了我

File version:     4.0.30319.18051

2.我在谷歌上搜索包含此版本的MS更新:

sos.dll 4.0.30319.18051

在此案例谷歌给出了 带有下载链接的 MS 知识库页面
我通常下载x64版本,因为它同时包含x86和x64 dll,所以我现在有Windows8-RT-KB2833958-x64.msu

注意:有时获取所需的补丁很困难,但在本例中并非如此。

3. 使用 FAR 文件管理器 我从这个MSU:

Windows8-RT-KB2833958-x64.cab

注意:有时里面有多个柜子,所以你需要检查哪一个包含sos.dll。

注意:有时补丁会以.EXE形式分发,因此您首先需要提取MSU或MSP文件(我使用FAR来提取),然后从中提取压缩包。

4. 有时 CAB 中的文件可以通过 FAR 提取,但有时它们的结构非常不同,我使用 WinAIK。 WinAIK 是 1.7 Gb ISO,但您只需要一小部分。
我使用以下 BAT 文件

mkdir Extracted
..\winaik_amd64\servicing\Expand.exe "%1" -F:sos.dll "Extracted"
..\winaik_amd64\servicing\Expand.exe "%1" -F:mscordacwks.dll "Extracted"

此命令提取指定 dll 的所有版本,每个版本都位于其自己的目录中。
有时 mscordacwks.dll 和 sos.dll 都有 2 个版本。我相信这是因为 GRD/LDR(QFE) 工作人员的原因。
在我们的示例中,有 4.0.30319.18051 和 4.0.30319.19079
使用 Windows 资源管理器检查文件属性。

5. 适当重命名文件:mscordacwks.dll 必须命名为 mscordacwks_%arch%_%arch%_%version%.dll 并且放置在 sos.dll 附近

所以
mscordacwks.dll (4.0.30319.18051) 转到mscordacwks_AMD64_AMD64_4.0.30319.18051.dll

(x86 版本重命名为mscordacwks_x86_x86_4.0.30319.18051.dll

sos.dll 可能保持原样,但我将其重命名为 sos.4.0.30319.18051.dll em>

对 4.0.30319.19079 版本执行相同操作(以备将来可能的需要)

6. 将这些文件复制到“C:\SOS\”文件夹,该文件夹包含大量 sos.4.xxxdllmscordacwks_AMD64_AMD64_4.xxxdll

< strong>7. 与 注意: 一起使用

.load C:\SOS\sos.4.0.30319.18051.dll

,有时对于 .Net 4.5,您需要向 mscordacwks 版本添加额外的“0”
mscordacwks_AMD64_AMD64_4.6.1055.00.dll 而不是 mscordacwks_AMD64_AMD64_4.6.1055.0.dll。但我没有深入挖掘,因为可以在很短的时间内处理这个问题。

顺便说一句,如果找不到 mscordacwks,WinDbg 会提示并指定版本(末尾有两个“0”)。

In short, do the following:

  1. Get the CLR version form the dump
  2. Find and download appropriate Microsoft patch
  3. Extract the sos.dll and mscordacwks.dll from the patch
  4. Use it

Below is an example:

1. After loading a crash dump I get the version I need:

>lm vm clr

it gives me

File version:     4.0.30319.18051

2. I google for MS update that contains this version:

sos.dll 4.0.30319.18051

In this case google gives an MS KB page with a download link.
I usually download x64 version, because it contains both x86 and x64 dlls, so I have Windows8-RT-KB2833958-x64.msu now.

Note: sometimes it's tricky to get the required patch, but not in this example.

3. Using FAR file manager I extract cabinet archive from this MSU:

Windows8-RT-KB2833958-x64.cab

Note: Sometimes there're several cabinets inside, so you need to check which one contains sos.dll.

Note: Sometimes patches are distributed as .EXE, so you first need to extract MSU or MSP files (I do it with FAR), and then extract cabinets from them.

4. Sometimes files from CABs can be extracted by FAR, but sometimes they have very different structure and I use Expand.exe from WinAIK. WinAIK is 1.7 Gb ISO, but you need only a small part.
I use the following BAT file

mkdir Extracted
..\winaik_amd64\servicing\Expand.exe "%1" -F:sos.dll "Extracted"
..\winaik_amd64\servicing\Expand.exe "%1" -F:mscordacwks.dll "Extracted"

This command extracts all versions of specified dlls, each one inside its own dir.
Sometimes there're 2 versions of both mscordacwks.dll and sos.dll. I believe this is because of GRD/LDR(QFE) staff.
In our example there're 4.0.30319.18051 and 4.0.30319.19079.
Check file properties with Windows Explorer.

5. Rename the files appropriately: mscordacwks.dll must be named as mscordacwks_%arch%_%arch%_%version%.dll and placed near the sos.dll

So
mscordacwks.dll (4.0.30319.18051) goes to mscordacwks_AMD64_AMD64_4.0.30319.18051.dll

(x86 version rename to mscordacwks_x86_x86_4.0.30319.18051.dll)

sos.dll might stay as is intact, but I rename it to sos.4.0.30319.18051.dll

Do the same for 4.0.30319.19079 version (for possible future needs)

6. Copy these files to 'C:\SOS\' folder which contains a lot of sos.4.x.x.x.dll and mscordacwks_AMD64_AMD64_4.x.x.x.dll

7. Use it with

.load C:\SOS\sos.4.0.30319.18051.dll

Note: Sometimes for .Net 4.5 you need to add additional '0' to mscordacwks version
mscordacwks_AMD64_AMD64_4.6.1055.00.dll instead of mscordacwks_AMD64_AMD64_4.6.1055.0.dll. I didn't dig deeper though, because could handle this within a small timeframe.

BTW, WinDbg will say if mscordacwks cannot be found and will specify the version (which will have double '0' at the end).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文