SOS commands fail while live debugging a process which has multiple versions of CLR loaded

Asked 3/3, 2011 at 7:27 Answered 19/12, 2017 at 6:1

I have a ASP.net 2.0 application that I am trying to debug live using Windbg and SOS.dll. When I attach the debugger to the process, I see it loads both 2.0 and 4.0 versions of CLR.[ mscorwks.dll and CLR.dll].I load my SOS by - .loadby sos mscorwks. After this, none of my SOS commands work. I get "Failed to request threadstore", "Unable to get info from System domain" etc.

I learnt this is due to the mismatch in the mscordacwks.dll for the different version of CLR. But all the solutions that I found on google around loading the right version of mscordacwks using cordll command failed to solve my problem. Particularly, I have used .cordll –ve –lp but doesnt seem to make any difference. Upon executing "!threads" commads again, I get

"CLR DLL status: Loaded DLL C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\mscordacwks.dll

Failed to request threadstore"

I have seen another entry in stackoverflow around this problem. But luckily for him the problem disappeared before a solution was suggested and also this is not a duplicate of this entry

Any clue to help me use SOS exention with 2 versions of CLRs loaded into my process would be greatly appreciated.

MSCORDACWKS versions loading behaviour is as follows -

**0:033>** .cordll -e 
CLR DLL status: Loaded DLL C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\mscordacwks.dll 
**0:033>** .cordll -ve -u -lp C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscordacwks.dll
 CLR DLL status: No load attempts 
**0:033>** .cordll -e
 CLR DLL status: No load attempts
 **0:033>** !threads 
CLRDLL: Loaded DLL C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\mscordacwks.dll Failed to request ThreadStore

Larrainelarrie answered 3/3, 2011 at 7:27 Comment(4)

Good question. What is the output regarding mscordacwks when you do a .cordll -ve -lp? – Humour 3/3, 2011 at 8:24

@Brian - I have updated my question with the typical behavior of .cordll that I am seeing. .cordll -ve -lp <2.0 mscorwks path> gets a "No load attempts". But if I execute any other sos command after that,it will immediately load 4.0 mscordacwks and throw me error messages "Failed to request thread store" etc. – Larrainelarrie 3/3, 2011 at 9:43

I'm having exactly the same problem :/ windbg keeps loading the .NET 4 dll. If you get an answer, or if you have any public URL with your case in Microsoft forums... please post it back :) – Booby 28/3, 2011 at 15:58

What was the debugger version back then? I have the same issue with version 6.12.0002.633 x86 using .cordll -ve -se -u -I 72f60000 -lp C:\WINNT\Microsoft.NET\Framework\v2.0.50727\ I stuck for a little while, detecting -I <address> is in fact a capital I but even with that, it doesn't work so I'm wondering if I'm not simply getting the same bug. – Gytle 12/5, 2011 at 15:54

I had a case opened on this with MS and the response I got was -

"this is an issue with the debugger and the product team is working on it now. "

I guess I will have to wait for the upcoming releases of windbg to have this fixed or explore other tools!

Thank you!

Larrainelarrie answered 18/3, 2011 at 11:48 Comment(1)

Loading sos works fine if i am analyzing a dump. But its also not working for me when i attach a live SSMS editor to windbg. – Arellano 22/9, 2011 at 16:11

I had the same problem and had contact with Microsoft. Using the latest version of windbg, the on that was released during the BUILD conference, I was able to load the .net 2 version of the data access library.

The Windbg version is included in the Windows 8 driver kit. I was able to load the mscorwks data access library using the following command:

.cordll -I mscorwks -lp <path to mscorwks dll>

Taxation answered 7/11, 2011 at 12:20 Comment(0)

It has been discussed already by long time Microsoft support guys,

http://blogs.msdn.com/b/asiatech/archive/2010/09/10/how-to-load-the-specified-mscordacwks-dll-for-managed-debugging-when-multiple-net-runtime-are-loaded-in-one-process.aspx

Enugu answered 5/3, 2011 at 12:39 Comment(3)

I have tried the solution suggested by that blog. The first option gives ".cordll -ve -se -u -I 79e70000 -N NOTE: This code is not supported and may not work. Do not report any problems you have. CLR DLL status: No load attempts Test new CLR interfaces" While the second one is ineffective like the other suggestions on the internet. "0:025> .cordll -ve -se -u -I 79e70000 -lp C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ CLR DLL status: No load attempts" . MY windbg version is 6.12.0002.633 X86 and my server is windows server 2003 32 bit. – Larrainelarrie 7/3, 2011 at 7:18

Then it is very likely some special configuration is required, which is missing from the blog post. If I were you, I won't hesitate to open a support case with Microsoft. – Enugu 7/3, 2011 at 8:23

Yes Lex, I have indeed opened a case with MS for this. Will update the thread if I get a resolution on the same. – Larrainelarrie 7/3, 2011 at 13:56

Today I also have the same problem, all the commands I could find just not work:(

Then I tried to load the dump with a older debugger, it works. My version is 6.7.5.0, fortunately some older versions are still available on my machine:)

Nettie answered 18/11, 2011 at 4:38 Comment(0)

I'm still facing to this problem today.

I found a solution works for me (assume mscordacwks.dll & sos.dll are stored in folder "C:\sos"):

.cordll -I mscorwks -lp "C:\sos"
.loadby sos mscorwks
!clrstack

This solution works for WinDbg of follwing versions:

10.0.15063 (of Windows Kits 10)
6.2.9200 (of Windows Kits 8.0)

Has been tested on Win7 x86 & Win10 x64.

Cauterant answered 19/12, 2017 at 6:1 Comment(0)