Tengo un volcado que tiene ambas versiones .NET cargadas:

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) 

Ahora no estoy seguro de qué versión de SOS utilizar. Ambos se cargarán sin problemas.

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

¿Cómo sabría qué versión usar mejor para mi análisis? ¿O siempre necesitaré ambos?

¿Es confiable .cordll -ve -u -l en este caso?

.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

El hilo 0 muestra mscorwks. Comandos utilizados:

~0s
k

=== ACTUALIZACIÓN ===

.cordll en principio está bien. Por defecto utilizará .NET 4 framework. Este comportamiento puede ser cambiado por.cordll -I.

He obtenido las dos versiones de SOS que coinciden con las del equipo de destino y cargadas por ruta

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

He actualizado de WinDbg 6.2 a la última versión 6.3. Todavía no mejor.

También le he preguntado a Steve Johnson, el autor de SOSEX que sugirió.cordll -I, pero esto tampoco funciona en mi volcado, ni con el nombre del módulo ni con la dirección base.

.cordll -I clr
.cordll -I 65490000

Cualquier intento de correr!threads siempre resulta en

Error al solicitar ThreadStore.

Cualquier intento de correr!clrstack siempre resulta en

No se puede caminar la pila administrada. El hilo actual probablemente no sea un hilo administrado. Puede ejecutar subprocesos para obtener una lista de subprocesos administrados en el proceso.

=== ACTUALIZACIÓN ===

Como lo sugiere Mario Hewardt, el escenario complejo con la especificación de la ruta completa de SOS se puede evitar cargando solo una extensión SOS en el proceso (o descargando una en caso de que ya estén cargadas) o podemos usar.setdll Para definir la versión por defecto de SOS nos gusta.

Sin embargo, esto no mejora el análisis.

=== ACTUALIZACIÓN ===

También he intentado descargar uno de los módulos .NET por.reload /u con la esperanza de que WinDbg / SOS no vuelva a estar en conflicto, pero aún así no hay suerte.