none
Dump analysis SOS expects mscorwks to be loaded, but it's not present in the memory dump RRS feed

  • Question

  • Hi,

    I have a memory dump of my 32 bit  application running on 64 bit Citrix server. I recently got a memory dump of it and I ran the following commands:

    0:000> lmvm clr
    start             end                 module name
    00000000`70e00000 00000000`7146e000   clr        (deferred)             
        Image path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
        Image name: clr.dll
        Timestamp:        Sat Jul 09 05:07:57 2011 (4E181A6D)
        CheckSum:         0067171F
        ImageSize:        0066E000
        File version:     4.0.30319.239
        Product version:  4.0.30319.239
        File flags:       8 (Mask 3F) Private
        File OS:          4 Unknown Win32
        File type:        2.0 Dll
        File date:        00000000.00000000
        Translations:     0409.04b0
        CompanyName:      Microsoft Corporation
        ProductName:      Microsoft® .NET Framework
        InternalName:     clr.dll
        OriginalFilename: clr.dll
        ProductVersion:   4.0.30319.239
        FileVersion:      4.0.30319.239 (RTMGDR.030319-2300)
        PrivateBuild:     DDBLD234
        FileDescription:  Microsoft .NET Runtime Common Language Runtime - WorkStation
        LegalCopyright:   © Microsoft Corporation.  All rights reserved.
        Comments:         Flavor=Retail
    

    and

    0:000> lmvm mscorwks
    start             end                 module name
    

    Notice that CLR loads, but mscorwks does not. Indicating it's a .net 4.0 application, right? wrong!

    Because as soon as I did this:

    0:000> .loadby sos clr
    0:000> !pe
    Failed to find runtime DLL (mscorwks.dll), 0x80004005
    Extension commands need mscorwks.dll in order to have something to do.
    
    Notice the error, it expect MSCORWKS - what do I do??


    Friday, May 25, 2012 5:45 PM

Answers

  • Hi,

    You need to make sure that clr.dll (or mscorwks.dll for .NET Framework lower then 4.0) is loaded. You did that correctly by using lmvm command. The output of lmvm however tells you that the module is not loaded - the load is deffered - it means it will be loaded once it's accessed when debugging live process, or when you request the loading from the debugger by .load /f.

    So you just need to force load that module and then you would be able to load the sos extension.

    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

    • Marked as answer by BabbuP Friday, December 14, 2012 8:16 PM
    Saturday, November 17, 2012 1:44 AM

All replies

  • Hi, 

    Same issue is discussed over here

    http://social.msdn.microsoft.com/Forums/en-US/clr/thread/e609dc9b-bf6f-4f49-9f51-5c3a4a5efa2d/

    Please check if this solves your problem?


    If this post answers your question, please click "Mark As Answer". If this post is helpful please click "Mark as Helpful".

    Friday, May 25, 2012 5:56 PM
  • hi Kris444, 

    Thanks for your reply, no that does not solve the problem. I had already seen that. I must also mention that I was able to debug on it few days back and I didn't encounter any problem. 

    I think my version of clr has changed from 4.0.30319.239 to 4.0.30319.269 - that may be another issue; but my application is built on .net 2.0 so I don't know how CLR is affecting my dump and why is mscorwks not present at all.

    Friday, May 25, 2012 6:09 PM
  • Hi Babbup,

    I am trying to involve some other one in this thread, please wait for a while.

    Thank you for your patience.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, May 28, 2012 9:18 AM
    Moderator
  • 1. On 64bit system, you may want to use 32bit debugging tools (adplus, debugdiag, etc.) to capture memory dump of 32bit process.

    2. If clr.dll is loaded to the process address space, it usually indicates that the running process is .NET 4.0 based. However, you mentioned that your application is build on .NET 2.0, so please verify whether the target system has .NET 2.0 installed, meanwhile, did you specify <supportedRuntime> (http://msdn.microsoft.com/en-us/library/w4atty68(v=vs.80).aspx) element in the app.config file?


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Regards,
    Eric Yang
    Microsoft Online Community Support

    Thursday, May 31, 2012 6:36 AM
  • Hi,

    You need to make sure that clr.dll (or mscorwks.dll for .NET Framework lower then 4.0) is loaded. You did that correctly by using lmvm command. The output of lmvm however tells you that the module is not loaded - the load is deffered - it means it will be loaded once it's accessed when debugging live process, or when you request the loading from the debugger by .load /f.

    So you just need to force load that module and then you would be able to load the sos extension.

    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

    • Marked as answer by BabbuP Friday, December 14, 2012 8:16 PM
    Saturday, November 17, 2012 1:44 AM