0

I am getting following error when trying to analyze a dump file.

    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.1022 
SOS Version: 4.0.30319.34011 
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.

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 clr.dll as well.

I am using correct version of WinDbg. I also know that the version of sos that I have on my machine is different than what was on machine where dump file is captured. So I am in process of getting correct version to see if that will solve the issue. However my problem is that when I open this dump file via DebugDiag Analyzer, it can read the dump file and provide me with correct results. I am just curious as to who DebugDiag is able to analyse this dump file when I don't have matching version of sos and mscordacwks on my machine?

whoami
  • 1,689
  • 3
  • 22
  • 45
  • Poking around in Microsoft.Diagnostics.Runtime.dll, it looks to me that it uses a more flexible version check on the DAC version. Verifying a single version number instead of trying to get an *exact* match on the SOS version number. This does not help you of course. – Hans Passant Oct 17 '14 at 15:30

1 Answers1

1

Debugdiag may be using psscor4 or something similar. Generally in 4.x frameworks we don't need a matching version, i don't remember the version but if you use an older windbg that thing works like a charm. Sosex and psscor4 will help in this case aswell.

Addy
  • 731
  • 5
  • 15
  • This is wrong. sos.dll requires exact match for DAC version. If you created dump on machine with different version of DAC, then what is currently installed on your machine, it will need you to have a mscordacwks___.dll in your symbol path. – seva titov Oct 17 '14 at 16:55
  • Not for clr i debug various versions every day only thing is if you have higher one it works – Addy Oct 17 '14 at 16:59
  • I wish there was a repository maintained by Microsoft where I can simply download various versions of debugging dlls, rather getting it from clients. psscor4 doesn't remain useful once you installed .net 4.5 unless Microsoft publishes a compatible psscor – whoami Oct 17 '14 at 18:33
  • 1
    Its not too late to start our own on a cloud storage. I have a few of them we can upload to a cloud space – Addy Oct 17 '14 at 18:37
  • not a bad idea. Can you share your collection somewhere? – whoami Oct 17 '14 at 20:50
  • 1
    @johnsmith Good initiative, except maybe the legal aspect. Anyway, see http://sos.debugging.wellisolutions.de/ – Thomas Weller Oct 17 '14 at 21:20
  • @ThomasW. Thanks for hosting that archive :-) – Marc Sherman Oct 20 '14 at 12:50