Windbg: psscor4 doesn't work

4
votes

I searched and tried a lot of things, but can't get psscor4 to work properly.

When I invoke !threads, I'm always getting

Failed to request ThreadStore

The things I checked are as follows:

  • I'm having a .NET 4 application that's compiled for X86 platform
  • I'm using Windbg version 6.2.9200.16384, X86 version
  • I'm using current psscor4 from Microsoft and it loads properly. I'm loading the X86 version, so that should be fine
  • Symbols are loaded from MS Symbol server (command .symfix+, then .reload)
  • .cordll shows the following:

    CLR DLL status: Loaded DLL C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscordacwks.dll

The same happens when I try to use SOS with .loadby sos clr

Does anybody have an idea?

2
.netwindbgsos
attached to process or on a dump? - Remus Rusanu
What is the build number of the CLR you're debugging (lmvm clr)? - Steve Johnson
1. Attached to a process 2. CLR v4.0.30319 - code-factory
I need to know the last (4th) part of the build number. I need to know whether you're debugging .NET 4.0 or 4.5. - Steve Johnson
It's .NET 4.0. Full Version of CLR: 4.0.30319.18052 - code-factory

2 Answers

6
votes

The problem is you're debugging .NET 4.5. PSSCOR4 won't work with .NET 4.5. I also suspect that you're running .NET 4.0 on your debugging machine, which would cause your SOS not to work either. In order to debug .NET 4.5, you need .NET 4.5 SOS and/or SOSEX (which works for all versions of .NET 2.0+).

1
votes

I've found this problem to happen when either:

  1. you are running the wrong version of the extension against the .NET framework for the process (!eeversion) - as mentioned by Steve Johnson here. To fix, verify ther version of .NET that the process was using (!eeversion) and download the corresponding correct version AND bitness of the extension.

OR

  1. you are not using the correct version of SOS against the memory dump for the process - i.e. your version of SOS is different than the version of SOS on the machine where the dump was taken. To test this, comapre the result of !eeversion against .chain and see if the SOS version is the same. If they are not, you make sure your Symbol Search Path in WinDbg is setup correctly and then run .symfix followed by .reload

The Symbol Search Path should be set to something like:

SRV*C:\SYMBOLS\PUBLIC*http://referencesource.microsoft.com/symbols;SRV*C:\SYMBOLS\PUBLIC*http://msdl.microsoft.com/download/symbols

You can also try the solution that is posted on John Robbins' blog here: http://wintellect.com/blogs/jrobbins/automatically-load-the-right-sos-for-the-minidump

Please note that I was able to get his solution to work only with WinDbg version 6.2+ - version 6.12 and below didn't work.

HTH