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.

.NET Framework version

CLR version

CLR filename

WinDbg Command

1.1

1.1

mscorwks.dll

.load clr10\sos

2.0

2.0

mscorwks.dll

.loadby sos mscorwks

3.0

2.0

mscorwks.dll

.loadby sos mscorwks

3.5

2.0

mscorwks.dll

.loadby sos mscorwks

4.0

4.0

clr.dll

.loadby sos clr

4.5

4.0

clr.dll

.loadby sos clr

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, 0x80004005Verify 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 isin the version directory3) or, if you are debugging a dump file, verify that the filemscordacwks_<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 IA64machine.

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,

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.

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.

Go to File>Symbol File Path and add the folder reference you created in step 2.

Load SOS extension as follows .load C:\hangdump\v4.0.30319\SOS.dll.

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.