3

I am responsible for debuggin minidumps from Windows Error Reporting on a .Net based shrink-wrapped desktop application installed on almost half a million PC's world wide, all running different OS versions and different patched versions of the .Net framework. To do this requires the matching version of the following 3 files

sos.dll
Mscorwks.dll
Mscordacwks.dll

I have had moderate success in the past downloading .msu files and extracting these files from them, but I am sure there must be an easier way.

My question is, is there a single repository where I can download the correct versions of these files so that I can debug the minidumps?

Scott Baldwin
  • 431
  • 2
  • 10

2 Answers2

2

You need many more files that just those three to reliably debug / reproduce / analyze issues from the field. Basically, you need all of them (Windows, CLR, and (managed) .NET framework).

I'm not aware of any repository for just some files. You'd have to install the respective versions.

While you can install multiple versions of .NET CLR (1.1, 2.0, 4.0) on same box, and load the correct SOS.dll into WinDBG via the .loadby command, you would probably have to have multiple Windows installations for those Versions you support.

In addition, you also need the (public) symbols for those components, including the (private) symbols for your own application, to do any meaningful debugging.

Considering you have 3 versions of your application shipped and still supported, running on 4 operating system versions still supported by you (say Windows Vista SP1, Windows 7, Windows 7 SP1 and Windows 8), that gives you 12 combinations to have symbols for.

That is what symbol servers are for. You could use the public microsoft symbol server, but that (of course) doesn't contain symbols for your very own application.

Given the scope/size of the application you describe, I'd say it would be well in order to set up an in-house symbol server. That can keep all the symbols of the different versions of your app that are still in use by customers (a task not to take lightly).

Suggested reading:

You could also consider setting up a source server to allow you fetching the correct version of your sources, inside a debugging session, from source control.

Community
  • 1
  • 1
Christian.K
  • 47,778
  • 10
  • 99
  • 143
  • How does symbol server help? The user needs a dll's, not symbols. – seva titov Aug 30 '12 at 14:39
  • @SevaTitov yes, he needs binaries as well, I neglected that part, sorry. But to do any meaningful debugging he'll need symbols as well. – Christian.K Aug 30 '12 at 17:28
  • Hi Christian, thanks for your response, but I already have the symbols sorted out. I can set the symbol path to my private symbols, and .symfix+ works a treat for the framework symbols. The real issue is that before you can even connect the debugger to a .net minidump in a meaningful way, you need the matching version of the 3 dll's mentioned above. Most people working on web based ASP.Net client-server applications don't have this issue because they can just log on to their production server and grab the versions of these dll's from there. I don't have this luxury. – Scott Baldwin Aug 31 '12 at 00:28
  • I can understand that. Our production servers are totally off limits for us (developers). The only chance we have is setting up an identical system (including patches and all) and try to reproduce any issues there :-| – Christian.K Aug 31 '12 at 07:26
1

As no one has been able to give me a real answer to this question, I will offer my "work-around". What I have been doing to date is to search the Microsoft support site to find the ms update package for the version of the framework, download it, and extract it using expand.exe. It is then possible to connect WinDbg to this version instead of the one that is running the machine you are debugging on. Here is a blogpost that explains the process in full detail http://sjbdeveloper.blogspot.com.au/2012/10/getting-correct-versions-of-net.html

Scott Baldwin
  • 431
  • 2
  • 10