Los comandos SOS fallan mientras se depura en vivo un proceso que tiene múltiples versiones de CLR cargadas

Tengo una aplicación ASP.net 2.0 que estoy tratando de depurar en vivo usando Windbg y SOS.dll. Cuando adjunto el depurador al proceso, veo que carga las versiones 2.0 y 4.0 de CLR. [Mscorwks.dll y CLR.dll]. Cargo mi SOS por - .loadby sos mscorwks. Después de esto, ninguno de mis comandos SOS funciona. Obtengo "No se pudo solicitar Threadstore", "No se puede obtener información del dominio del sistema", etc.Los comandos SOS fallan mientras se depura en vivo un proceso que tiene múltiples versiones de CLR cargadas

Me enteré de que esto se debe a la falta de coincidencia en mscordacwks.dll para la versión diferente de CLR. Pero todas las soluciones que encontré en google cargando la versión correcta de mscordacwks usando el comando cordll no pudieron resolver mi problema. Particularmente, he usado .cordll -ve -lp pero no parece hacer ninguna diferencia. Al ejecutar "hilos"! Commads nuevo, consigo

"CLR DLL de estado: Cargado DLL C: \ WINDOWS \ Microsoft.NET \ Framework \ v4.0.30319 \ Mscordacwks.dll

no solicitó threadstore"

He visto another entry en stackoverflow alrededor de este problema. Pero afortunadamente para él el problema desapareció antes de que se sugiriera una solución y este no es un duplicado de this entry

Cualquier pista para ayudarme a usar la exención de SOS con 2 versiones de CLR cargadas en mi proceso sería muy apreciada.

MSCORDACWKS versiones comportamiento de la carga es el siguiente -

**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

Fuente

2011-03-03 Mallika Ravi

Buena pregunta. ¿Cuál es el resultado con respecto a mscordacwks cuando haces un '.cordll -ve -lp'? –

@Brian - He actualizado mi pregunta con el comportamiento típico de .cordll que estoy viendo. .cordll -ve -lp <2.0 mscorwks path> obtiene un "Sin intentos de carga". Pero si ejecuto cualquier otro comando SOS después de eso, inmediatamente cargará 4.0 mscordacwks y me lanzará mensajes de error "No se pudo solicitar la tienda de hilos", etc. –

Tengo exactamente el mismo problema:/windbg sigue cargando .NET 4 dll . Si recibe una respuesta, o si tiene alguna URL pública con su caso en los foros de Microsoft ... publíquelo de nuevo :) – graffic

que tenía un caso abierto en esto con EM y la respuesta que obtuve fue -

"este es un problema con el depurador y el equipo del producto está trabajando en ello ahora. "

¡Creo que tendré que esperar a que las próximas versiones de windbg lo arreglen o explore otras herramientas!

¡Gracias!

Fuente

2011-03-18 11:48:37

Cargando sos funciona bien si estoy analizando un vertedero. Pero tampoco funciona para mí cuando adjunto un editor de SSMS en vivo a windbg. –

Ya se ha discutido por largo tiempo tipos de soporte Microsoft,

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

Fuente

2011-03-05 12:39:21

He intentado con la solución sugerida por ese blog. La primera opción da ".cordll -ve -se -u -I 79e70000 -N NOTA: Este código no es compatible y puede no funcionar. No reporte ningún problema que tenga. Estado CLR DLL: Sin intentos de carga Pruebe nuevas interfaces CLR" Mientras que el segundo es ineficaz como las otras sugerencias en Internet. "0: 025> .cordll -ve -se -u -I 79e70000 -lp Estado de la DLL C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ CLR: Sin intentos de carga". MY windbg es 6.12.0002.633 X86 y mi servidor es Windows Server 2003 de 32 bits. –

Entonces es muy probable que se requiera alguna configuración especial, que falta en la publicación del blog. Si yo fuera usted, no dudaría en abrir un caso de soporte con Microsoft. –

Sí Lex, de hecho, he abierto un caso con MS para esto. Actualizaré el hilo si obtengo una resolución sobre el mismo. –

Tuve el mismo problema y tuve contacto con Microsoft. Usando la última versión de windbg, la que se lanzó durante la conferencia BUILD, pude cargar la versión .net 2 de la biblioteca de acceso a datos.

La versión Windbg está incluida en el Windows 8 driver kit. Yo era capaz de cargar la biblioteca de acceso a datos mscorwks con el siguiente comando:

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

Fuente

2011-11-07 12:20:42 Jonne

Hoy también tengo el mismo problema, todos los comandos que pude encontrar simplemente no funcionan :(

Luego trató de cargar el volcado con un depurador anterior, funciona. Mi versión es 6.7.5.0, afortunadamente algunas versiones anteriores todavía están disponibles en mi máquina :)

Fuente

2011-11-18 04:38:03 sali98

Todavía me enfrento a este problema hoy.

Encontré una solución que funciona para mí (supongamos mscordacwks.dll & sos.DLL se almacenan en la carpeta "C: \ sos"):

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

Esta solución funciona para WinDBG de las versiones siguientes;

10.0.15063 (de kits de Windows 10)
6.2.9200 (de Windows Kits 8.0)

Ha sido probado en Win7 x86 & Win10 x64.

Fuente

2017-12-19 06:01:20 daseny

Los comandos SOS fallan mientras se depura en vivo un proceso que tiene múltiples versiones de CLR cargadas

Respuesta

Cuestiones relacionadas