What to do with "The version of SOS does not match the version of CLR you are debugging" in WinDbg?

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.

Solution 1:

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.

Solution 2:

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.

Solution 3:

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:

• Version history of the CLR 2.0
• Version history of the CLR 4.0

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.