У меня есть дамп, в котором загружены обе версии .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

=== ОБНОВЛЕНИЕ ===

.cordll в принципе нормально. По умолчанию он будет использовать .NET 4 Framework. Это поведение может быть изменено.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, чтобы получить список управляемых потоков в процессе.

=== ОБНОВЛЕНИЕ ===

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

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

=== ОБНОВЛЕНИЕ ===

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