共用方式為


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

  • Anonymous
    January 12, 2011
    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 mscorwksstart    end        module name71b70000 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=Retail0:000> .loadby sos mscorwks0:000> !clrstackOS Thread Id: 0xd70 (0)Unable to walk the managed stack. The current thread is likely not amanaged thread. You can run !threads to get a list of managed threads inthe process0:000> .cordll -ve -u -lCLR DLL status: No load attempts0:000> .cordll -ve -se -u -I 71b70000  -lp C:WindowsMicrosoft.NETFrameworkv2.0.50727CLR DLL status: No load attempts0:000> .unloadUnloading C:WindowsMicrosoft.NETFrameworkv2.0.50727sos extension DLL0:000> .loadby sos mscorwks0:000> !clrstackCLRDLL: Loaded DLL C:WindowsMicrosoft.NETFrameworkv4.0.30319mscordacwks.dllOS Thread Id: 0xd70 (0)Unable to walk the managed stack. The current thread is likely not amanaged thread. You can run !threads to get a list of managed threads inthe processAm I doing something wrong here?Regards,Manish
  • Anonymous
    March 28, 2011
    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
  • Anonymous
    April 21, 2011
    Same problem as above...  unbelievably annoying
  • Anonymous
    May 12, 2011
    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?
  • Anonymous
    September 01, 2012
    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