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:


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


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:


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 (10)

  1. You’ve been kicked (a good thing) – Trackback from DotNetKicks.com

  2. shooting in the dark… you loaded a 64bit dump

  3. 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.

  4. Josh Coswell says:

    This gives me more insight into function of sos.dll

    Josh Coswell


  5. Bill Menees says:

    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

  6. 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.

  7. So the last quiz asked about a common error message you may see when debugging a dump from .NET on a

  8. Bill Menees says:

    Thanks, Tom.  I figured out why it wasn’t working for me half the time: User Error.  When I copied the 1434 version from a Windows 2008 box, I accidentally renamed the file as this:


    But it should have been this:


    without the ".dll" immediately after "mscordacwks".

    After reading through your articles and still not getting it to work with my existing dll, I decided to step back and look for a simpler explanation for my problem.  On a careful redo, I finally noticed my renaming error.  Hopefully, I won’t make that mistake again.  🙂

    Thanks again for providing the blog articles.  It’s nice to have this stuff documented.

  9. that is a very good point Bill.  You have to be very careful with the rename or it won’t find the correct file.

Skip to main content