Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Obtaining mscordacwks.dll for CLR Versions You Don’t Have

DZone's Guide to

Obtaining mscordacwks.dll for CLR Versions You Don’t Have

Free Resource

Note: This blog post assumes that you can capture and analyze managed dumps in WinDbg using SOS, and have encountered a bizarre technical problem when using dumps from a production environment. If this assumption is incorrect, feel free to peruse my .NET Debugging Resources link post.

When debugging managed dumps in WinDbg, you will need to load the SOS version that is compatible with the CLR version in the dump. SOS, in turn, requires the CLR “data access DLL” (mscordacwks.dll), which is a debugging helper shipping with the .NET Framework. If SOS and/or mscordacwks.dll are missing or have the wrong version, you will receive an error similar to the following when trying to run most SOS commands:

Failed to load data access DLL, 0x80004005 

Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of mscorwks.dll is in the version directory
3) or, if you are debugging a dump file, verify that the file mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
4) you are debugging on the same architecture as the dump file. For example, an IA64 dump file must be debugged on an IA64 machine.

You can also run the debugger command .cordll to control the debugger's load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload. If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable path is pointing to mscorwks.dll as well.

Some CLR versions have been indexed by the Microsoft public symbol server, so you can instruct the debugger to download everything automatically by setting your symbol path and image path to the Microsoft symbol server.

However, some CLR versions have not been indexed and cannot be retrieved automatically—and this is where you need to crawl the Web and find the binaries manually. Today I had the chance to encounter a CLR version, 2.0.50727.3607, which WinDbg couldn’t retrieve from the Microsoft symbol server:

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

Doug Stewart has been collecting updates to CLR 2.0 for several years now, and has an entry on his post for the 3607 CLR build, associated with KB article 976569.

If you go to the KB article, you’ll be able to download the update, an executable file. Instead of launching it, open it in an application that understands self-executing archives, such as 7-Zip:

image

Locate the .msp file and open it again:

image

One of the .cab files contains the files we are looking for. If you got the wrong .cab file, try the other one :-)

image

Now all that’s left is to extract them to a temporary directory, rename them to mscorwdacwks.dll and mscorwks.dll, and issue a .cordll -u -ve -lp <path> command in WinDbg:

0:014> .cordll -u -ve -lp D:\temp\3607
CLRDLL: Loaded DLL D:\temp\3607\mscordacwks.dll
CLR DLL status: Loaded DLL D:\temp\3607\mscordacwks.dll

Voila—you can run any SOS commands now.

 

Topics:

Published at DZone with permission of Sasha Goldshtein, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}