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!