none
Help:Failed to load sos in windbg

    Question

  • These days I am trying to get the memory information of all objects in my c# apps with windbg.I am the first time to use the debug tool. I downloaded windbg 6.8 from ms and installed it in my winXP sp2 system.The settings are as follows.

        

          --symbol file path=srv*D:\Symbol*http://msdl.microsoft.com/download/symbols

     

    I copied the sos.dll from  the framework directory to the folder where I installed windbg .Then I used the commands to test.

    --cmd 1

    0:000> .load sos    //nothing was shown

     

    --cmd 2

    0:000> !dumpheap (or !eeheap)
    Failed to find runtime DLL (mscorwks.dll), 0x80004005    //It happened again after I copied the mscorwks.dll from  the 

                                                                                      // framework  directory to the folder where I installed windbg

    Extension commands need mscorwks.dll in order to have something to do.

     

    --cmd 3

    0:000> .cordll
    CLR DLL status: No load attempts

     

    --cmd 4

    0:000> .loadby sos mscorwks
    Unable to find module 'mscorwks'

     

    --cmd 5

    0:000> .chain
    Extension DLL search Path:
        D:\program files\Debugging Tools for Windows\WINXP;D:\program files\Debugging Tools for Windows\winext;D:\program files\Debugging Tools for Windows\winext\arcade;D:\program files\Debugging Tools for Windows\pri;D:\program files\Debugging Tools for Windows;D:\program files\Debugging Tools for Windows\winext\arcade;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;C:\Program Files\Microsoft SQL Server\90\DTS\Binn\;C:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\;C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\;C:\Program Files\MySQL\MySQL Server 5.0\bin
    Extension DLL chain:
        sos: image 6.8.0004.0, API 1.0.0, built Fri Apr 13 10:56:46 2007
            [path: D:\program files\Debugging Tools for Windows\sos.dll]
        D:\program files\Debugging Tools for Windows\clr10\sos.dll: image 6.8.0004.0, API 1.0.0, built Fri Sep 28 05:27:13 2007
            [path: D:\program files\Debugging Tools for Windows\clr10\sos.dll]
        dbghelp: image 6.8.0004.0, API 7.0.6, built Fri Sep 28 05:27:05 2007
            [path: D:\program files\Debugging Tools for Windows\dbghelp.dll]
        ext: image 6.8.0004.0, API 1.0.0, built Fri Sep 28 05:26:59 2007
            [path: D:\program files\Debugging Tools for Windows\winext\ext.dll]
        exts: image 6.8.0004.0, API 1.0.0, built Fri Sep 28 05:26:28 2007
            [path: D:\program files\Debugging Tools for Windows\WINXP\exts.dll]
        uext: image 6.8.0004.0, API 1.0.0, built Fri Sep 28 05:26:45 2007
            [path: D:\program files\Debugging Tools for Windows\winext\uext.dll]
        ntsdexts: image 7.0.6440.1, API 1.0.0, built Fri Sep 28 05:45:23 2007
            [path: D:\program files\Debugging Tools for Windows\WINXP\ntsdexts.dll]


     

    It seemed that the sos.dll had been loaded unsuccessfully and I don't kown why these happened.

    Can someone help me?

    Tuesday, April 01, 2008 3:51 AM

Answers

  • --I copied the sos.dll from  the framework directory to the folder where I installed windbg .

    This is not correct since there are several DLLs of CLR referenced by the SOS extension, you should load the SOS.dll by using its originally full path.

    In addition, .loadby locates a DLL by looking in the same directory as where another DLL was loaded from. So, ".loadby sos mscorwks" tells WinDbg to look up which directory mscorwks.dll was loaded from and load sos.dll from there. If you're running an unmanaged application (i. e., a non .NET application) then mscorwks.dll won't be loaded and you get the message "Unable to find module 'mscorwks'". You also get this message if you break into a managed application very early, before the .NET CLR is loaded.

    Also recommended reading
    WinDbg / SOS Cheat Sheet about this issue.
    Wednesday, April 02, 2008 6:13 AM

All replies

  • --I copied the sos.dll from  the framework directory to the folder where I installed windbg .

    This is not correct since there are several DLLs of CLR referenced by the SOS extension, you should load the SOS.dll by using its originally full path.

    In addition, .loadby locates a DLL by looking in the same directory as where another DLL was loaded from. So, ".loadby sos mscorwks" tells WinDbg to look up which directory mscorwks.dll was loaded from and load sos.dll from there. If you're running an unmanaged application (i. e., a non .NET application) then mscorwks.dll won't be loaded and you get the message "Unable to find module 'mscorwks'". You also get this message if you break into a managed application very early, before the .NET CLR is loaded.

    Also recommended reading
    WinDbg / SOS Cheat Sheet about this issue.
    Wednesday, April 02, 2008 6:13 AM
  • I am in the same boat here.  I was able to analyze IIS crash dumps prior to .net 3.5.  Now that I have it installed on my workstation, I get the following error:

     

    0:000> .load C:\Windows\Microsoft.NET\Framework\v2.0.50727\sos.dll
    0:000> !pe
    Failed to find runtime DLL (mscorwks.dll), 0x80004005
    Extension commands need mscorwks.dll in order to have something to do.

    I have tried .load sos, and .load sos.dll as well.

     

    Any ideas on how to solve this so that I can analyze my iis crash dump?

     

    Thanks,

    Shan

    Wednesday, April 23, 2008 5:28 PM
  • Use "sxe ld:mscorlib" and "g" to make it stop after the module is loaded, then enter ".loadby sos mscorwks" command. It should works.


    Elton
    Wednesday, October 08, 2008 10:15 AM
  • FYI... a newbie like me struggled with this for a while, until I realized that this command won't work until you see something like this fly by in the module load information...

    ModLoad: 79e70000 7a3ff000   C:\WINNT\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll

    Then you can type in the command ".loadby sos mscorwks "  and it will work....
    Javaman
    • Proposed as answer by Lodle Tuesday, September 18, 2012 6:24 AM
    Monday, December 08, 2008 9:16 PM
  • You can have the debugger break the instant mscorwks loads, like this:

    sxe ld mscorwks

    You could even get fancy and completely automate it:

    sxe -c ".loadby sos mscorwks ; g" ld mscorwks

    This will wait for the "module load" debug event, filtering for the mscorwks module. When the first chance exception happens "-c" execute the command to load the runtime, and go ".loadby sos mscorwks ; g".

     

    • Proposed as answer by doug65536 Friday, April 23, 2010 1:26 AM
    Friday, April 23, 2010 1:25 AM
  • Some tips for new users of windbg from a new user of windbg:

    1. If you are running 64-bit OS, install both the 32-bit and 64-bit verions of Windbg. You will need to attach the correct windbg version to your process depending on whether you are debugging 32- vs. 64- bit process. If you attach the wrong version, you can get the "clr module not found" error on trying to use .loadby sos clr command.
    2. A useful debugging extension is sosex. Download from Web and extract the 32-bit version into the 32-bit windbg install location. Extract the 64-bit version into 64-bit windbg location.
    3. In windbg , launch your .exe to debug through windbg menu or attach windbg to a running process. Remember 32-bit windbg for 32-bit OS or process running as 32-bit in 64-bit OS.
    4. Press F5 to start debuggee (your process), click Debug, break (or ctrl+break) to break into your process and freeze process threads. Now you are ready to use windbg.
    5. At windbg command prompt type:
    • .load sosex
    • .loadby sos clr
    • Note - If you get the clr not found error, make sure you are .NET 4.0. If not, use .loadby sos mscorwks as stipulated earlier in the thread. you can also use the lm command in windbg to see loaded modules and clr should be in that list if you are .NET 4.0.

    Some useful commands

    • ~                    displays all threads
    • !threads           displays all managed threads
    • ~#s                 where # is the thread number - switch between threads e.g., ~0s switches to thread 0
    • !clrstack           walks stack for a managed thread - note you need to switch to the thread first using info from !threads on which are managed and using ~#s to switch to the one you want the stack for.
    • ~*kP                stack for all threads
    • .prefer_dml 1     dml formatting for windbg output.
    Friday, April 08, 2011 7:18 PM
  • Very helpful kinshowa, thanks!

    Monday, July 25, 2011 8:48 PM
  • In case of postortem or remote debugging the situation can be complicated as one might not have the apropriate version and architecture of .NET Framework installed on his machine (especially with the arrival of arm devices running .NET) - using the Microsoft symbol server for loading the modules needed for debugging (especially mscordacwks.dll) is a recomendable way. Here is my rule of thumb setup steps for postmortem or remote debugging of managed code in windows debugger:

    1. Set your symbol path to Microsoft symbol server (internal or external)
    2. Set your execution image path to Microsoft symbol server
    3. Make sure that the core CLR binary (mscorwks.dll or clr.dll) is loaded, reload it (with .reload /f) if it’s not
    4. Reload CLR debugging related binaries by using ‘.cordll –ve –u –l’ command (-ve for verbose, –u for unload, –l for load)
    5. Load the SOS module from the core CLR binary location (as you’d do that for live debugging)

    For more info end example of the actuall comands and debugger spew please refer to this blog post: http://blogs.msdn.com/b/jankrivanek/archive/2012/11/16/setting-up-managed-code-debugging-with-sos-and-sosex.aspx

    I hope this helps
    Jan Krivanek

    Saturday, November 17, 2012 1:51 AM