windbg and SciTech profiler: Failed to load data access DLL for x64 memory dump

2
votes

I know this has been asked many times but well, I have read them all and have not been able to fix the problem.

Basically I have a memory dump of an IIS 7.0 x64 w3wp.exe process running as a web role in Azure. I have got multiple dumps and cannot load any of them in windbg or SciTech .Net Memory Profiler. For both, problem seems to be finding right mscordacwks.dll.

I have obtained both x64 and x86 mscordacwks.dll from the machine and this could not load any of them.

So when I want to see the managed threads, etc in windbg I get familiar error:

0:000> !threads
The version of SOS does not match the version of CLR you are debugging.  Please
load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.551
SOS Version: 4.0.30319.17929
CLRDLL: Unable to get version info for 'D:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscordacwks.dll', Win32 error 0n87
DBGHELP: C:\Program Files\Debugging Tools for Windows (x64)\sym\mscordacwks_AMD64_AMD64_4.0.30319.551.dll\4F191DB4964000\mscordacwks_AMD64_AMD64_4.0.30319.551.dll - OK
CLRDLL: Loaded DLL C:\Program Files\Debugging Tools for Windows (x64)\sym\mscordacwks_AMD64_AMD64_4.0.30319.551.dll\4F191DB4964000\mscordacwks_AMD64_AMD64_4.0.30319.551.dll
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 clr.dll is 
                in the version directory or on the symbol path
            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 supported cross platform architecture as 
                the dump file. For example, an ARM dump file must be debugged
                on an X86 or an ARM machine; an AMD64 dump file must be
                debugged on an AMD64 machine.

So I see 2 oddities here:

  1. Windows is deployed on D:\ drive on Azure (can this cause a problem?)
  2. CLR Version: 4.0.30319.551 but SOS Version: 4.0.30319.17929

So could it be the SOS version which is 17929? mscordacwks.dll on the server is definitely 551.

I have run about every command line you could imagine without solving the problem.

Thanks in advance

3
.netwindbgmemory-profiling

3 Answers

2
votes

Technically, it is always a requirement to use the same version of SOS as the runtime you're debugging. However, you can usually get by with matching the first three version places. In this dump, though, it's .NET 4.0, but your SOS version is 4.5. This will never work, because the underlying debugging API was completely changed in .NET 4.5. Therefore, you need to acquire the proper version of SOS.dll.

2
votes

PSSCOR4.dll from Microsoft is a superset of SOS.dll and works with all the .NET 4 framework versions prior to .NET 4.5. Thanks to Steve Johnson for clarifying that it won't work with .NET 4.5.

psscor4.dll can be downloaded from here

1
votes

OK, I grabbed the SOS.dll for the same box and this fixed it. So it is what no one tells you anywhere in the posts.

You need both SOS.dll and mscordacwks.dll from the machine you generated dumps - not just mscordacwks.dll.