Использование SOS на свалке с .NET 2 (mscorwks) и .NET 4 (CLR)

Question

У меня есть дамп, который как .NET версии загруженную:

0:000> lm m clr 
start end  module name 
65490000 65aff000 clr  (deferred)    
0:000> lm m mscorwks 
start end  module name 
6a980000 6af2c000 mscorwks (deferred) 

Теперь я неопределенными, какая версия SOS использовать. Оба будут загружаться без проблем.

0:000> .loadby sos mscorwks 
0:000> .loadby sos clr 

Как узнать, какая версия лучше всего подходит для моего анализа? Или мне всегда нужны оба?

Есть .cordll -ve -u -l надежный в этом случае?

.symfix c:\symbols 
.cordll -ve -u -l 

CLRDLL: C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscordacwks.dll:4.0.30319.18047 f:8 
doesn't match desired version 4.0.30319.296 f:8 
CLRDLL: Loaded DLL c:\symbols\mscordacwks_x86_x86_4.0.30319.296.dll\50484AA966f000\mscordacwks_x86_x86_4.0.30319.296.dll 
CLR DLL status: Loaded DLL c:\symbols\mscordacwks_x86_x86_4.0.30319.296.dll\50484AA966f000\mscordacwks_x86_x86_4.0.30319.296.dll 

Тема 0 показывает mscorwks. Команды, используемые:

~0s 
k 

=== UPDATE ===

.cordll в принципе нормально. По умолчанию он будет использовать среду .NET 4. Такое поведение можно изменить на .cordll -I.

Я получил обе версии SOS, которые соответствуют, что на целевом компьютере и загружается путь

.load C:\SOS\4.0.30319.296\SOS.dll 

Я модернизировал от WinDbg 6.2 до последней 6.3. Все еще не лучше.

Я также спросил Стива Джонсона, автора SOSEX, который предложил .cordll -I, но это также не работает в моем дампе, ни с именем модуля, ни с базовым адресом.

.cordll -I clr 
.cordll -I 65490000 

Любая попытка запустить !threads всегда приводит к

Не удалось запросить ThreadStore.

Любая попытка запустить !clrstack всегда приводит к

Невозможно пройти управляемый стек. Текущий поток, вероятно, не управляемый поток. Вы можете запускать! Threads для получения списка управляемых потоков в процессе.

=== UPDATE ===

Как полагает Марио Хьюардт, сложный сценарий с указанием полного пути SOS можно избежать только загрузки одного расширения SOS в процесс (или разгрузки один в случае они уже загружены), или мы можем использовать .setdll для определения стандартной версии SOS по умолчанию.

Однако это не улучшает анализ.

=== UPDATE ===

Я также попытался разгрузки один из .NET модулей по .reload /u в надежде, что WinDbg/SOS не будет в конфликте больше, но до сих пор не повезло.

Answer 1

Это очень уродливая проблема, и у нее нет простого решения. Основная проблема заключается в том, что ваш клиент использует другую версию CLR, чем вы. С некоторыми разногласиями, учитывая совершенно разные номера версий, у вас установлен .NET 4.5, а клиент использует .NET 4.0. Но просто патча безопасности может быть достаточно, чтобы вызвать несоответствие, но они стали неуклонно поздно.

Afaik Вы практически застряли в настройке виртуальной машины или машины, которая использует точный номер той же ревизии, что и ваш потребитель.

Функция CLR для совместной работы в .NET 4 в противном случае может объяснить, как вы могли бы использовать две версии CLR в одном процессе. Версия v2.0, как правило, будет там для реализации COM-сервера. Что-то вы избегаете, добавляя вместо этого ссылку на сборку [ComVisible] .NET. Хотя это может не быть вашим кодом, который делает это. Удачи в этом, неплохая проблема.

Answer 2

Вам придется использовать сложные .cordll команды для загрузки mscordacwks.dll явно, которая покрыта в этом блоге,

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