WinDbg – Failed to load data access DLL


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

Advertisements
Leave a comment

2 Comments

  1. I like this site very much so much fantastic information.

    Reply
  2. Removing symbols directory and full re-loading of it has helped me. It seems that WinDbg uses existing mscordacwks, but loads the corresponding version when otherwise.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: