How to load the specified mscordacwks.dll for managed debugging when multiple .NET runtime are loaded in one process


 

When multiple .NET runtime are loaded in one target process or one dump file, for example:

 

0:030> lm

start             end                 module name

00000000`1b6d0000 00000000`1b9ba000   System_Data   (deferred)            

000007fe`f3e60000 000007fe`f47c5000   clr        (deferred)            

000007fe`f9880000 000007fe`fa230000   mscorwks   (deferred) 

 

0:030> lmvm clr

start             end                 module name

000007fe`f3e60000 000007fe`f47c5000   clr        (deferred)            

    Image path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll

    Image name: clr.dll

……

    CompanyName:      Microsoft Corporation

    ProductName:      Microsoft® .NET Framework

    InternalName:     clr.dll

    OriginalFilename: clr.dll

    ProductVersion:   4.0.30319.1

    FileVersion:      4.0.30319.1 (RTMRel.030319-0100)

    PrivateBuild:     DDBLD431

    FileDescription:  Microsoft .NET Runtime Common Language Runtime – WorkStation

    LegalCopyright:   © Microsoft Corporation.  All rights reserved.

Comments:         Flavor=Retail

 

0:030> lmvm mscorwks

start             end                 module name

000007fe`f9880000 000007fe`fa230000   mscorwks   (deferred) 

    Image path: C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorwks.dll

    Image name: mscorwks.dll

…….

    CompanyName:      Microsoft Corporation

    ProductName:      Microsoft® .NET Framework

    InternalName:     mscorwks.dll

    OriginalFilename: mscorwks.dll

    ProductVersion:   2.0.50727.4206

    FileVersion:      2.0.50727.4206 (VistaSP2GDR.050727-4200)

    FileDescription:  Microsoft .NET Runtime Common Language Runtime – WorkStation

    LegalCopyright:   © Microsoft Corporation.  All rights reserved.

Comments:         Flavor=Retail

 

Both .NET runtime 4.0 clr.dll and .NET runtime 2.0 mscorwks.dll are loaded in one process, managed debugging may not give the right result as the below:

 

0:030> .loadby sos mscorwks

0:030> !clrstack

OS Thread Id: 0x2674 (30)

Unable to walk the managed stack. The current thread is likely not a

managed thread. You can run !threads to get a list of managed threads in

the process

 

Actually the thread 30 is a managed thread, it is .NET 2.0 managed thread  but not .NET 4.0 managed thread.

 

If try to load managed debugging module mscordacwks.dll by using .cordll as the below, it could be seen that the debugger will always try to load the mscordacwks.dll for the newest .NET run time by default, in our sample it is .NET 4.0 runtime, that’s why a .NET 2.0 managed thread could not be debugged normally.

 

0:030> .cordll -ve -u -l

CLRDLL: Loaded DLL C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscordacwks.dll

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

 

 

How to load the specified mscordacwks.dll for managed debugging in this situation? For example, load the managed debugging module for .NET 2.0 runtime mscorwks.dll in this case? Assume the matched mscordacwks.dll is copied into the folder c:\temp, the following two commands can be used to load the module for managed debugging:

 

.cordll -ve -se -u -I <Start address of the target .NET runtime module> -N

 

Or

 

.cordll -ve -se -u -I <Start address of the target .NET runtime module> -lp <path of the managed debugging module>

 

In our sample, the command would be:

 

*note*  -N switch causes the debugger to search the matched mscordacwks.dll in the configured symbol  path. -lp switch causes the debugger to load the matched mscordacwks.dll from the specified path.

 

0:030> .cordll -ve  -se -u -I 000007fe`f9880000 –N

 

CLRDLL: C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscordacwks.dll:2.0.50727.4952 f:0

doesn’t match desired version 2.0.50727.4206 f:0

CLRDLL: Loaded DLL

\\SymbolShare\websymbols\mscordacwks_AMD64_AMD64_2.0.50727.4206.dll\4BF4C1819b0000\mscordacwks_AMD64_AMD64_2.0.50727.4206.dll

CLR DLL status: Loaded DLL \\SymbolShare\websymbols\mscordacwks_AMD64_AMD64_2.0.50727.4206.dll\4BF4C1819b0000\mscordacwks_AMD64_AMD64_2.0.50727.4206.dll

….

 

Or

 

0:030> .cordll -ve -se -u -I 000007fe`f9880000 -lp c:\temp

 

CLRDLL: Loaded DLL c:\temp\mscordacwks.dll

CLR DLL status: Loaded DLL c:\temp\mscordacwks.dll

 

Now try the managed debugging command and it can give the right result.

 

0:030>.loadby sos mscorwks

0:030> !clrstack

OS Thread Id: 0x2674 (30)

(!clrstack processes a max of 1000 stack frames)

Child-SP         RetAddr          Call Site

0000000005fb71a0 000007fef6fc79b5 System.Net.Sockets.Socket.MultipleSend(System.Net.BufferOffsetSize[], System.Net.Sockets.SocketFlags)

0000000005fb7290 000007fef6fc747b System.Net.Sockets.NetworkStream.MultipleWrite(System.Net.BufferOffsetSize[])

0000000005fb7310 000007fef6fc7381 System.Net.ConnectStream.ResubmitWrite(System.Net.ConnectStream, Boolean)

0000000005fb73c0 000007fef6fc7240 System.Net.HttpWebRequest.EndWriteHeaders_Part2()

……

 

Enjoy the debugging ,  Cheers!

 

Xiao

 

Comments (5)

  1. Manish says:

    Hi Xiao,

    I am facing a problem with the same symptoms that you have described. However the solution doesn't work for me. An excerpt from my WinDbg session is given below:

    0:000> lmvm mscorwks

    start    end        module name

    71b70000 72100000   mscorwks   (deferred)            

       Image path: C:WindowsMicrosoft.NETFrameworkv2.0.50727mscorwks.dll

       Image name: mscorwks.dll

       Timestamp:        Thu May 20 06:20:39 2010 (4BF4C6A7)

       CheckSum:         005914C4

       ImageSize:        00590000

       File version:     2.0.50727.4206

       Product version:  2.0.50727.4206

       File flags:       0 (Mask 3F)

       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:     mscorwks.dll

       OriginalFilename: mscorwks.dll

       ProductVersion:   2.0.50727.4206

       FileVersion:      2.0.50727.4206 (VistaSP2GDR.050727-4200)

       FileDescription:  Microsoft .NET Runtime Common Language Runtime – WorkStation

       LegalCopyright:   © Microsoft Corporation.  All rights reserved.

       Comments:         Flavor=Retail

    0:000> .loadby sos mscorwks

    0:000> !clrstack

    OS Thread Id: 0xd70 (0)

    Unable to walk the managed stack. The current thread is likely not a

    managed thread. You can run !threads to get a list of managed threads in

    the process

    0:000> .cordll -ve -u -l

    CLR DLL status: No load attempts

    0:000> .cordll -ve -se -u -I 71b70000  -lp C:WindowsMicrosoft.NETFrameworkv2.0.50727

    CLR DLL status: No load attempts

    0:000> .unload

    Unloading C:WindowsMicrosoft.NETFrameworkv2.0.50727sos extension DLL

    0:000> .loadby sos mscorwks

    0:000> !clrstack

    CLRDLL: Loaded DLL C:WindowsMicrosoft.NETFrameworkv4.0.30319mscordacwks.dll

    OS Thread Id: 0xd70 (0)

    Unable to walk the managed stack. The current thread is likely not a

    managed thread. You can run !threads to get a list of managed threads in

    the process

    Am I doing something wrong here?

    Regards,

    Manish

  2. Javier says:

    Hmmm…

    I have the same problem as Manish. WinDbg keeps loading the v4 of the mscordacwks, Even if I remove the .NET 4 environment It will ask for the v4 dll.

    There is also an open stack overflow question with this problem:

    stackoverflow.com/…/sos-commands-fail-while-live-debugging-a-process-which-has-multiple-versions-of-c

  3. Scott says:

    Same problem as above…  unbelievably annoying

  4. BK says:

    Hi, got the same problem… On the stackoverflow question, it is said that MS told the bug was with WinDbg. Could you confirm or infirm that?

  5. The instructions above works only in windbg that is shipped as part of Windows 8 SDK (6.2.8400.0).

    For previous versions it doesn't seems to work

Skip to main content