Estoy utilizando una API de fuente cerrada de un tercero que arroja una excepción que indica que "todos los conductos con nombre están ocupados".Análisis del volcado de emergencia en windbg
Me gustaría depurar esto aún más (en lugar de simplemente dar un paso al frente) para poder aprender lo que sucede bajo las sábanas.
He realizado un vuelco de este proceso utilizando WinDbg. ¿Qué comandos debería usar ahora para analizar este volcado?
Gracias
En general, esto sucede cuando un cliente llama a CreateFile para una tubería existente y todas las instancias de canalización existentes están ocupados. En este punto, CreateFile devuelve un error y el código de error es ERROR_PIPE_BUSY. Lo correcto en este momento es llamar a WaitNamedPipe con un valor de tiempo de espera para esperar que una instancia de canal esté disponible.
El problema generalmente ocurre cuando más de un cliente intenta conectarse a la tubería con nombre al mismo tiempo.
que suponer que la tercera parte está DLL nativa (De lo contrario, sólo tiene que utilizar reflector)
Antes de utilizar WinDbg para analizar el volcado, intente usar Proceso-Monitor (SysInternals, freeware) para supervisar la actividad de su proceso. si falla debido a un problema relacionado con el sistema de archivos, puede ver exactamente qué fue lo que causó el problema y qué intentó exactamente hacer antes de fallar.
Si Process-Monitor no fue suficiente, puede intentar y depurar su proceso. pero para ver alguna información significativa sobre el dll de terceros, necesitarás sus pdb.
Después de establecer los símbolos de depuración correctos, puede ver la pila de llamadas utilizando el comando k o una de sus variaciones (de nuevo, supongo que está hablando de código nativo). si su proceso se bloquea debido a este dll entonces examine los parámetros que pasa a su función para asegurarse de que el problema no está de su lado. Supongo que más adelante en la pila de llamadas, se llega a alguna API de Win32: examine los parámetros que está pasando la función de la dll, tratando de ver si algo "huele". Si tiene el símbolo privado de la dll, también puede examinar las variables locales de su función (dv) que le pueden dar más información.
Espero haberles dado un buen punto de partida.
Este es un excelente recurso para usar WinDbg para analizar los accidentes que pueden ser de alguna utilidad: http://www.networkworld.com/article/3100370/windows/how-to-solve-windows-10-crashes-in-less-than-a-minute.html
El artículo es para Windows 10, pero contiene enlaces a información similar para las versiones anteriores de Windows.
El enlace está roto. – UserControl
@UserControl: gracias por señalar eso. He actualizado la respuesta. – boot13
En la depuración post mortem con Windbg, puede ser útil ejecutar algunos comandos generales de diagnóstico antes de decidir dónde profundizar. Estos deben ser sus primeros pasos:
.logopen <filename> (See also .logappend)
.lastevent See why the process halted and on what thread
u List disassembly near $eip on offending thread
~ Status of all threads
Kb List callstack, including parameters
.logclose
Estos comandos normalmente le dan una visión de lo que sucedió para que pueda seguir perforando. En el caso de tratar con bibliotecas en las que no tiene el código fuente, enviar el archivo de registro resultante al proveedor junto con el número de compilación de la biblioteca binaria debería ser suficiente para que puedan rastrearlo a un problema conocido si existe.
Se podría empezar a hacer la siguiente manera para obtener una visión general de la excepción:
!analyze -v
Ahora se puede cargar el registro contexto excepción:
.ecxr
Y ahora ... sólo echar un vistazo en la pila, registros, hilos, ...
kb ;will show you the stack trace of the crash.
dv ;local variables
Según las pistas que obtenga, debe seguir un dif dirección diferente Si desea una referencia rápida a WinDbg, le recomendaría this link.
Espero que algunos de estos comandos e información les sean útiles.
¿Está administrado o es nativo? ¿Puedes arrojar más detalles? – Naveen