WinDbg Tip:Failed to load data access DLL

For the past few months I have been almost exclusively using WinDbg to debug high severity production issues. It represents analysis on those gnarly situations that only volume stressed environments encounter. Almost by definition these situations rarely yield the whole story from single log files, even with the best intentions and foresight, memory dumps become the most direct and detailed way to see how your application is performing.

One of the first things you do in WinDbg is load the correct version of SOS debugging extension, ideally it would be one of the following commands which is based on the .NET version you are running.

Now for every CLR version there is a specific Data access component (DAC, mscordacwks.dll). The DAC is the layer that SOS uses to talk to the managed runtime, and if the correct version cannot be located, because say an MS patch has updated it then you get to see a message like this:

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___.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.

The most direct solutions are centered around step 2 and 3, that is, getting the correct version of mscordacwks.dll. We can start by running .cordll -ve -u -l to get information about what version is loaded and is trying to load. Let us assume for a moment that its supposed to be 4.6.1080.0,

1. On the server you performed the hang dump find the mscordacwks.dll and SOS.dll in the framework directory, for example C:\Windows\Microsoft.NET\Framework64\v4.0.30319.
2. Copy the files to a folder but also rename mscordacwks.dll as follows C:\hangdump\v4.0.30319\mscordacwks_x64_x64_4.0.30319.dll.
3. Go to File>Symbol File Path and add the folder reference you created in step 2.
4. Load SOS extension as follows .load C:\hangdump\v4.0.30319\SOS.dll.
5. Try running an SOS command like, !DumpHeap –stat.

To be honest the above is a really surgical approach to this problem and has worked for me, however, you can apply a little more brute force by simply running the !analyze –v command. If you are pointing at Microsoft’s symbol server it will automatically pull down and load the appropriate DAC version on your behalf.

Happy debugging!