I recently had to look at the  memory consumption of a .NET process (running as a service). The process memory was growing up and we wanted to see how the memory was used  (on a Windows 2003 SP2-32 bits server machine).

Using WinDbg, we created a dump of the process memory. Then I tried to look at it on my development machine (Windows XP SP2, 32 bits) and I got the error message “Failed to load data access DLL, 0x80004005“. The error was about the version of “mscordacwks.dll“.

Here are the steps I had to do to overcome this issue and carry on my investigation. It seems I am not the only one still having this issue.  I hope this help you if you need  it.

1. I setup correctly the path for the symbols files (used “!sym noisy” and “ld *“, or you can use “.reolad“).
2. Load “Son-Of-Strike” (SOS) (“>loadby sos mscorwks“).
3. I tried to have a look at the overall memory consumption by type (“> !dumpheap -stat“). I got the following error message:
• 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.
4. I used the recommended instruction to see what was going on (“>.cordll -ve -u -l“). I tried again and got the following (I enabled the “noisy” feature about symbols loading):
   • 0:000> !sym noisy
   • 0:000> .cordll -ve -u -l
     CLR DLL status: No load attempts
     0:000> !dumpheap -stat
     CLRDLL: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscordacwks.dll:2.0.50727.3082 f:0
     doesn’t match desired version 2.0.50727.3615 f:0
     CLRDLL: Unable to find mscordacwks_x86_x86_2.0.50727.3615.dll by mscorwks search
     CLRDLL: Unable to find ‘mscordacwks_x86_x86_2.0.50727.3615.dll’ on the path
     CLRDLL: Unable to get version info for ‘D:\SymbolCache\mscorwks.dll\4BE902C7590000\mscordacwks_x86_x86_2.0.50727.3615.dll‘, Win32 error 0n87
     CLRDLL: ERROR: Unable to load DLL mscordacwks_x86_x86_2.0.50727.3615.dll, Win32 error 0n87
     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 ….
5. Interesting hint: the server has a different .NET Runtime than my development machine. There is a useful page on Wikipedia about .NET CLR versions (http://en.wikipedia.org/wiki/List_of_.NET_Framework_versions).
6. WinDbg (or more exactly SOS) is trying to load a helper debug DLL called “mscordacwks.dll” from this location “D:\SymbolCache\mscorwks.dll\4BE902C7590000\”. On my machine, my local cache symbol root is set to “D:\SymbolCache”.  Although I had Microsoft public symbol setup as a downstream store server, it was unable to get this version from it. Lucky enough I still had access to the server where the dump was created. So, manually:
1. I created the folder “D:\SymbolCache\mscorwks.dll\4BE902C7590000\“.
2. I retrieved the file from the machine where the dump was done (<windows folder\…>)
3. I renamed the file “mscordacwks.dll” to “mscordacwks_x86_x86_2.0.50727.3615.dll“
7. I tried again and this time it worked:
• 0:000> .cordll -ve -u -l
  CLR DLL status: No load attempts
  0:000> !clrstack
  CLRDLL: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscordacwks.dll:2.0.50727.3082 f:0
  doesn’t match desired version 2.0.50727.3615 f:0
  DBGHELP: D:\SymbolCache\mscordacwks_x86_x86_2.0.50727.3615.dll\4BE902C7590000\mscordacwks_x86_x86_2.0.50727.3615.dll – OK
  CLRDLL: Loaded DLL D:\SymbolCache\mscordacwks_x86_x86_2.0.50727.3615.dll\4BE902C7590000\mscordacwks_x86_x86_2.0.50727.3615.dll
  OS Thread Id: 0x390 (0)
  ESP       EIP
  002cf42c 7d61c876 [NDirectMethodFrameStandalone: 002cf42c] System.ServiceProcess.NativeMethods.StartServiceCtrlDispatcher(IntPtr)
  002cf43c 67a45db7 System.ServiceProcess.ServiceBase.Run(System.ServiceProcess.ServiceBase[])
  002cf468 00f733ef MyBasicService.RunAsService(System.String[])
  002cf47c 00f7338f MyBasicService.Main(System.String[])
  002cf69c 79e71b4c [GCFrame: 002cf69c]

Here a few links that helped me on this issue:

• [REF-1] Loading CLR DAC dll from a different path – blog entry from Junfeng Zhang, 13 Aug 2007.
• [REF-2] Failed to load data access DLL, 0x80004005 – OR – What is mscordacwks.dll? – blog entry from Doug S, 18 Feb 2009.
• [REF-3] List_of_.NET_Framework_versions – Useful page on Wikipedia about .NET CLR versions.