Why can't WinDBG find the mscordacwks.dll?

Question

I'm trying to use WinDBG to analyze a crash dump from one of our production machines. The root of my problem seems to be that I have a different build of the .NET framework than the production machine, only I don't know how to fix the problem. When I turn !sym noisy and then run !dlk(from SOSEX) I get the following error as it tries to find the mscordacwks dll

0:000> !dlk
CLRDLL: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscordacwks.dll:2.0.50727.3623 f:0
doesn't match desired version 2.0.50727.3607 f:0
SYMSRV:  c:\mysymbols\mscordacwks_x86_x86_2.0.50727.3607.dll\4ADD5446590000\mscordacwks_x86_x86_2.0.50727.3607.dll not found
SYMSRV:  http://msdl.microsoft.com/download/symbols/mscordacwks_x86_x86_2.0.50727.3607.dll/4ADD5446590000/mscordacwks_x86_x86_2.0.50727.3607.dll not found
SYMSRV:  c:\mysymbols\mscordacwks_x86_x86_2.0.50727.3607.dll\4ADD5446590000\mscordacwks_x86_x86_2.0.50727.3607.dll not found
SYMSRV:  c:\mysymbols\mscordacwks_x86_x86_2.0.50727.3607.dll\4ADD5446590000\mscordacwks_x86_x86_2.0.50727.3607.dll not found
SYMSRV:  http://msdl.microsoft.com/download/symbols/mscordacwks_x86_x86_2.0.50727.3607.dll/4ADD5446590000/mscordacwks_x86_x86_2.0.50727.3607.dll not found
SYMSRV:  c:\mysymbols\mscordacwks_x86_x86_2.0.50727.3607.dll\4ADD5446590000\mscordacwks_x86_x86_2.0.50727.3607.dll not found
CLRDLL: Unable to find mscordacwks_x86_x86_2.0.50727.3607.dll by mscorwks search
CLRDLL: Unable to find 'mscordacwks_x86_x86_2.0.50727.3607.dll' on the path
SYMSRV:  c:\mysymbols\mscorwks.dll\4ADD5446590000\mscorwks.dll not found
SYMSRV:  http://msdl.microsoft.com/download/symbols/mscorwks.dll/4ADD5446590000/mscorwks.dll not found
SYMSRV:  c:\mysymbols\mscorwks.dll\4ADD5446590000\mscorwks.dll not found
DBGHELP: C:\Program Files\Debugging Tools for Windows (x86)\mscorwks.dll - file not found
SYMSRV:  c:\mysymbols\mscorwks.dll\4ADD5446590000\mscorwks.dll not found
SYMSRV:  http://msdl.microsoft.com/download/symbols/mscorwks.dll/4ADD5446590000/mscorwks.dll not found
SYMSRV:  c:\mysymbols\mscorwks.dll\4ADD5446590000\mscorwks.dll not found
CLRDLL: Unable to find mscorwks.dll by search
CLRDLL: ERROR: Unable to load DLL mscordacwks_x86_x86_2.0.50727.3607.dll, Win32 error 0n2
Unable to initialize .NET data interface. Version 2.0.50727.3607 of mscordacwks.dll is required.
Locate and load the correct version of mscordacwks.dll. See documentation for the .cordll command.

I took the mscorwks.dll, mscordawks.dll and sos.dll from the production machine and placed them in C:\mysymbols. It looks like WinDBG is looking for a dll INSIDE the mscorwks dll.

Solution 1

This very complete explanation by Doug Stewart helped me in this situation.

Summary:

• Get the mscordacwks.dll from the original system.
• Rename it to something like mscordacwks_AAA_AAA_2.0.50727.xxxx.dll (depending on your architecture and the specific framework version) - e.g. mscordacwks_x86_x86_2.0.50727.3607.dll for the specific case in the question.
• Copy that file into the directory of windbg.exe.

Solution 2

After this 2 commands everything become OK:

0:000> .symfix
0:000> .reload

Solution 3

After checking out the article here http://codenasarre.wordpress.com/2011/06/22/sending-an-sos/

And then basically trying every incarnation of moving symbols around that I could, I found that the only way I could get this working was to copy the mscorwks.dll, mscordawks.dll and sos.dll from the production machine into C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727

It seems that WinDBG doesn't do so well with multiple version of the same DLL. Maybe I did something wrong, but copying the dlls directly to the .NET Framework directory at least got me up and running.

Solution 4

I've also found that using the 64bit version of windbg and debugging a "Any CPU" managed code project where the build is set to "prefer 32 bit" will cause this error.

View more solutions

Comments

[Lex Li]

It is not because of WinDbg cannot handle multiple versions of mscordacwks.dll, but it uses the by-design algorithm to query them (as it has so many patched versions), which is the style you adapt to actively. Once you get used to this fact, you won't face much trouble in the future.

[Dinesh Rajan]

thanks.. this worked for DebugDiag too... copied to C:\Program Files\DebugDiag

[CodeFox]

@diinesh-rajan, thank you for drawing my attention to DebugDiag!