Freigeben über


POP QUIZ: SOS not loading properly

So for this quiz, we are going to be looking at attempting to load sos.dll for the .NET Framework 2.0.

We get a dump file, and when we try to run a command on the dump file, we get an error like:

quiz1

So reading this, we see that we should run .cordll -ve -u -l.  Ok, so we run that:

quiz2

So the questions are:

  1. What is going on here?
  2. Why can’t we run sos commands on this dump?
  3. What is mscordacwks?
  4. How do we fix it?

As an additional bit of trivia, what if when you run the .cordll command you see something like:

quiz3

What does this mean and how do you fix it?

As usual, I will post the solution and the comments tomorrow.

kick it on DotNetKicks.com

Comments

  • Anonymous
    April 08, 2008
    You've been kicked (a good thing) - Trackback from DotNetKicks.com

  • Anonymous
    April 08, 2008
    shooting in the dark... you loaded a 64bit dump

  • Anonymous
    April 08, 2008
    Just from the "x64" in the path I'd suspect a bitness mis-match - 32 bit debugger trying to load x64 SOS.   No justification from the ".cordll -ve -u -l" command, just a hunch.

  • Anonymous
    April 08, 2008
    This gives me more insight into function of sos.dll Josh Coswell http://riverasp.net

  • Anonymous
    April 09, 2008

  1.  The current machine has a different revision of .NET 2.0 than the machine the dump was taken on.  See the following article for a list of some of the .NET 2.0 revisions: http://blogs.msdn.com/dougste/archive/2007/09/06/version-history-of-the-clr-2-0.aspx
  2.  The current machine has revision 1433, which is .NET 2.0 SP1.  The dump machine only had revision 926, which was a pre-SP1 hotfix.
  3.  DLL description for mscordacwks: Microsoft .NET External Data Access Support
  4.  In theory, you can copy the mscordacwks.dll from the dump machine into your local machine's symbol path and rename it to have the architecture and version in the file name.  In practice, this only works for me about half the time.  The other half I just end up cussing a lot because SOS is so fragile with respect to DLL revisions.  :-(  I'm hoping you can tell me a procedure that will make these situations debuggable 100% of the time. Bill Menees
  • Anonymous
    April 09, 2008
    Bill, I posted the answer.  If this doesn't give you enough, I am going to be making another post in the next few days going into more detail of how to get this to work.

  • Anonymous
    April 09, 2008
    So the last quiz asked about a common error message you may see when debugging a dump from .NET on a

  • Anonymous
    April 09, 2008
    Bill, Check out http://blogs.msdn.com/tom/archive/2008/04/09/asp-net-tips-getting-sos-to-work-when-commands-fail.aspx

  • Anonymous
    April 10, 2008
    The comment has been removed

  • Anonymous
    April 10, 2008
    that is a very good point Bill.  You have to be very careful with the rename or it won't find the correct file.