4

I am working on a mixed-mode app (C++/CLI, C++, some C#) and when it crashes in the field a memory dump gets created. I usually get these dumps from the customer and try to figure out what went wrong.

The question is - how to handle post-mortem debugging of the managed code? I usually use WinDbg with the SOS.dll, however it seems like SOS is not backwards compatible! I recently ran Windows Update and now I cannot load any minidumps from the client site. It complains of wrong SOS version.

How can I get and load the previous version(s)? I am doing something wrong?

Justin
  • 84,773
  • 49
  • 224
  • 367
Filip Frącz
  • 5,881
  • 11
  • 45
  • 67
  • There have been no recent updates to sos.dll afaik. You usually have to worry about your *customer* making configuration changes. Document your question better with *exact* error messages and versions and dates on your sos.dll file and the mscorlib.dll in the minidump. – Hans Passant Aug 31 '11 at 15:11
  • Could you list the error you get please. – Brian Rasmussen Feb 10 '13 at 07:24

1 Answers1

1

It's likely an x86/64 issue. How are you loading sos?

You might try loading sos by using:

.loadby sos mscorwks

Or, failing that, try to load the 64-bit sos explicitly:

.load c:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dll
Richard Szalay
  • 83,269
  • 19
  • 178
  • 237
  • Note: These examples are a bit odd. The first attempts to load `sos` from the location of `mscorwks`, i.e. the 2.0 runtime. The second example tries to load `sos` directly from the 4.0 runtime. – Brian Rasmussen Feb 10 '13 at 07:23