Use WinDbg and SOS.DLL with multiple CLR instances SxS in the same process

If you debugging a managed app that has more than one CLR instances loaded in the same process (typically V2/V1.1 + V4 at the time of writing), you’ll probably run into a problem that SOS commands doesn’t quite work in this case. More specifically, if you do a .loadby sos clr, all SOS commands work just fine. But if you unload the SOS (by .unload command) and then load the SOS for V2 by using .loadby sos mscorwks, you’ll find out that SOS commands in V2 doesn’t really work. For example, !dumpmt will tell you that a valid MethodTable is invalid, !do will tell you a valid object is invalid, etc.

The trick is that you need to have WinDbg load the right version of Mscordacwks.dll. SOS needs this DLL to read data structures out-of-proc from the debuggee, and just like SOS.dll, this DLL is tightly coupled with CLR and needs to exactly match the CLR that you want to debug. The right command to load up the mscordacwks.dll is as follows:

.cordll –ve –I <address_of_CLR_DLL> -l

For example, say you want to load SOS for V2 mscorwks.dll, you need to follow these steps:

1. .unload (This unloads all the extensions, or you can use .unload <SOS path name>. I found using .unload much easier)

2. .loadby sos mscorwks (This loads up SOS)

3. .cordll –u (This unloads the current mscordacwks loaded by WinDbg)

4. lmvm mscorwks (Find out the address of mscorwks)

5. .cordll –ve –I <address_of_mscorwks_DLL> -l

Then you can go ahead and use V2 SOS commands.

Read more: YI ZHANG'S MSDN BLOG

Posted via email from .NET Info