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

May 19, 2012


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 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:


Locate the .msp file and open it again:


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


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.

I am posting short updates and links on Twitter as well as on this blog. You can follow me: @goldshtn

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>



  1. mgkMay 25, 2012 ב 12:55 PM

    It would be worth pointing out that the GDRGDR.cab contain the “General Distribution Release” files, whilst the QFEGDR” contains the “Limited Distribution Release” files (for more details see http://support.microsoft.com/kb/960043/). Whilst you may need the LDR versions, I would expect most people to need the GDR versions first… Also, Doug has a page of versions for the CLR V4 release as well http://blogs.msdn.com/b/dougste/archive/2011/09/30/version-history-of-the-clr-4-0.aspx

  2. YosiApril 23, 2014 ב 2:27 PM

    What about changes to SOS.dll (The version of SOS does not match the version of CLR you are debugging)? I’m assuming the updated SOS.dll could be extracted similarly from the update ?

    1. Sasha Goldshtein
      Sasha GoldshteinApril 23, 2014 ב 6:47 PM

      Usually. It’s usually right there next to the CLR DLL. In some cases it’s even on the symbol server.

  3. Pingback: Obtaining the CoreCLR DAC DLL for Windows Phone | All Your Base Are Belong To Us