0

I've been working on a tool to pull some information out of crash dumps (minidumps) and create a report. In some cases I'm finding that WinDBG is unable to automatically download the correct combination of mscordacwks and SOS. The source of the crash dump is an application containing both native and managed code.

My symbol path is:

Cache*D:\SymbolCache;SRV*\\\storage\Symbols;SRV*http://msdl.microsoft.com/download/symbols;SRV*http://referencesource.microsoft.com/symbols;SRV*https://dotnet.myget.org/F/rx/symbols";

.loadby sos clr

CLRDLL: Unable to get version info for '\\storage\symbols\clr.dll\5B5542C49ec000\mscordacwks.dll', Win32 error 0n87
CLRDLL: Unable to find mscordacwks_AMD64_AMD64_4.7.3132.00.dll by mscorwks search
CLRDLL: Unable to find 'mscordacwks_AMD64_AMD64_4.7.3132.00.dll' on the path
Cannot Automatically load SOS
CLRDLL: ERROR: Unable to load DLL mscordacwks_AMD64_AMD64_4.7.3132.00.dll, Win32 error 0n2
CLRDLL: Consider using ".cordll -lp <path>" command to specify .NET runtime directory.
Failed to load data access DLL, 0x80004005

I have also tried .cordll -ve -u -l but the result is the same as shown above.

!pe

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.7.3132.0
SOS Version: 4.7.3190.0

Inspecting the outgoing HTTP requests i see the following:

WinDBG:

http://msdl.microsoft.com/download/symbols/mscordacwks_AMD64_AMD64_4.7.3132.00.dll/5B5542C49ec000/mscordacwks_AMD64_AMD64_4.7.3132.00.dll

Visual Studio:

http://msdl.microsoft.com/download/symbols/mscordacwks.dll/5B5541451ca000/mscordacwks.dll

I'm surprised to see that the files they request have different paths. It seems to me that Visual Studio must have further logic to locate the correct mscordacwks (unsure about SOS.dll)...whats the difference between the two - how come Visual Studio's version doesn't have the architecture in the name?

At one point i did see it working albeit after locating the mscordacwks and placing it in the right folder, however this is not a solution as i need this to be an automatic process.

Can anyone shed any light on what is going wrong here?

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
rupertmulrenan
  • 355
  • 1
  • 3
  • 13
  • 2
    Just type the full path name to sos.dll. Not that this is likely to help much, v4.7.3190.0 is the version number of the update that was released on October 10th. Your minidump came from a machine that wasn't updated yet. Painful problem. – Hans Passant Oct 26 '18 at 00:51
  • Did you run `!analyze -v`? – Thomas Weller Oct 26 '18 at 17:23
  • Which version of WinDbg do you use? And which version of dbghelp.dll does it use? And how does that compare to VS? "this is not a solution as i need this to be an automatic process" - good luck. Sometimes MS didn't even publish the DLL and they just made it available upon request. – Thomas Weller Oct 26 '18 at 21:29
  • People usually capture `mscordacwks` (or `clr`) and `sos` from the machine where the dump was captured, so that later they can debug the dump in WinDbg, https://blogs.msdn.microsoft.com/dougste/2009/02/18/failed-to-load-data-access-dll-0x80004005-or-what-is-mscordacwks-dll/ Not sure what Visual Studio does under the hood, but it is rare that Visual Studio is used to analyze dump files (though it can of course). – Lex Li Oct 26 '18 at 23:15
  • I tried running !analyze -v but unsurprisingly it only outputs the native stack (it also repeatedly suggests to load a matching sos dll). The WinDbg/dbghelp.dll version is 10.0.17763.1. I agree that it makes sense to package up the dac/sos libraries with the dump file to avoid these nasty issues. Going forward its definitely something to look into. If Visual Studio is able to download a compatible dac isn't it likely that the sos.dll is also on Microsoft's symbols server? If so how can i calculate its path to download it manually? – rupertmulrenan Oct 28 '18 at 19:27

0 Answers0