Mostrando entradas con la etiqueta Debugging. Mostrar todas las entradas
Mostrando entradas con la etiqueta Debugging. Mostrar todas las entradas

domingo, 20 de febrero de 2011

Debugging I parte

En este articulo quiero hablar del Debugging en Windows, más abajo vamos a ver las definiciones de las Aplicaciones, Procesos, Threads y CallStacks una vez que ya sabemos estas definiciones nos podemos defender con las aplicaciones de Debugging.
Aplicaciones, procesos y threads
Una aplicación está formada por uno o más procesos
Un proceso es un ejecutable (.exe) que está en memoria y que está formado por uno o más threads (hilos de ejecución) y sus propios recursos
Piensa en un proceso como en un contenedor de threads
Un thread es la unidad básica de ejecución para la que el sistema operativo reserva tiempo de procesador para llevar a cabo una tarea
Un thread es lo que la CPU ejecuta. Todo proceso vivo ha de tener al menos un thread, y a menudo tiene varios.
Thread Call Stacks
Foto de un thread en un instante de tiempo
Muestra la historia de llamadas a funciones
Cada thread tiene su propio Call Stack
Ejemplo:
ntdll!KiFastSystemCallRet
USER32!NtUserGetMessage+0xc
notepad!WinMain+0xe5
notepad!WinMainCRTStartup+0x174
kernel32!BaseProcessStart+0x23
Cada hilo(Thread) de un proceso tiene su Call Stack independiente. Con el Windbg (Debugging Tools for Windows) podemos ver los call stack de alguna aplicación común, como notepad.exe o calc.exe por ejemplo.
Aquí os dejo un procedimiento que habría que seguir para determinar la causa y ubicar el fallo de nuestro Sistema Operativo.
Procedimiento a seguir para resolver problemas:
Determinar el tipo de fallo: Access Violation, resultado inesperado…
Documentar los síntomas: Memory Leak, 100% CPU, Crash…
Elegir las herramientas y técnicas adecuadas:
  - Habilitar tracing en la aplicación.
  - Usar logs de debug o “checked builds”.
  - Perfmon, EventLogs, Netmon, Filemon, logs de IIS, MSDN, etc.
  - Conseguir dumps y analizarlos.
  - y analizarlo: examinar el stack, evaluar parámetros y variables, desensamblar y entender el código, poner breakpoints antes del fallo, examinar/modificar la memoria y loAdjuntarse al proceso con un depurador s registros, editar el código o los datos, etc.
Bien, una vez que tenemos claro todo esto, podemos empezar a hablar de las herramientas de Debbuging.
Para analizar el archivo de volcado que se genera al "colgarse" el sistema operativo necesitaremos un depurador y los símbolos pertenecientes al sistema operativo en el que se ha producido ese dump.
Windbg es una herramienta de depuración tanto en modo kernel como en modo usuario, con ella analizaremos los volcados.
Cuando pasa un error en modo kernel Windows nos saluda con una pantalla azul y la info sobre el código de stop. Esto puede modificarse, de manera que:
- Se puede asignar un depurador (como windbg o KD).
- Se grabe el archivo de volcado de memoria (dump).
- Se produzca un reinicio automático del sistema.
- Se grabe el volcado y reinicie el sistema inmediatamente después.
Los volcados.
Modo-kernel:
Completo: volcado de tamaño más grande, contendrá la memoria física del equipo en el momento del error. Lo que implica que el archivo de paginación deba tener al menos el tamaño de la memoria real + 1MB.
El volcado se guarda en la raíz del sistema  %systemroot%\Minidump con el nombre de memory.dmp, y en el caso de volcados posteriores, irían sustituyendo al existente.
Memoria Kernel: Con un tamaño significativamente menor contiene la memoria ocupada por el kernel en el momento del error. Es decir, ni memoria no asignada ni la que está asignada a aplicaciones en modo usuario, sólo la usada por el kernel, HAL, y la asignada a controladores y programas en modo kernel.
En general es el volcado más útil y se guarda en la raíz del sistema con el nombre memory.dmp. Los volcados posteriores, sean memoria kernel o completo, sustituyen al existente.
Volcado pequeño: Con un tamaño de 64KB es el más pequeño de todos y por tanto sólo requiere un archivo de paginación de ese tamaño.
Su contenido es:
- Mensaje del código de stop y sus parámetros.
- El contexto del procesador que ha cascado.
- La información del proceso y el contexto kernel, del proceso que ha petado.
- La información del hilo y el contexto kernel, del proceso que ha petado.
- La pila de llamadas en modo kernel para el hilo que ha petado. Sólo hasta 16KB, los de arriba de la pila.
- Una lista de los controladores cargados.
Además, si es Windows XP o posterior:
- Una lista de módulos cargados y descargados.
- El bloque de datos del depurador (información de depuración básica del sistema).
- Cualquier página de memoria que Windows crea que es útil en la depuración de errores. (Las páginas de datos a qué apuntan los registradores en el momento del pete y otras que hayan sido solicitadas específicamente por el componente que falla).
Después de esta pequeña explicación, vamos a descargar e instalar la herramienta, le tenemos que descargar los símbolos desde el servidor de descarga:
SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Para eso tendríamos que crear un directorio en C$ con el mismo nombre "websymbols" o poner el nombre que os convengan, en mi caso es"DebuggingToolsSymbols". Una vez que ya hemos creado el directorio, abrimos la aplicación y entramos en File>Symbol File Path... o con Ctrl+S y se nos abrirá esta misma ventana donde debemos que pegar la ruta a utilizar en el Windbg:
Una vez que ya tenemos esta parte hecha ya podemos abrir el  archivo .dmp (DUMP) en  File>Open Crash Dump y cuando se abre la ventana tenemos que ir a  %systemroot%\Minidump (en este directorio el sistema guarda los volcados de memoria) para seleccionar el archivo .dmp.
Se abrirá el archivo dump (al abrir el primer archivo dump va tardar un poco por el motivo de que se está descargando los Symbolos de la url que le hemos configurado antes)
Podemos empezar con el comando:
!analyze –v
Con este comando podemos ver todos los detalles de archivo dump.
0: kd> !analyze -v
PFN_LIST_CORRUPT (4e)
Typically caused by drivers passing bad memory descriptor lists (ie: calling
MmUnlockPages twice with the same list, etc).  If a kernel debugger is
available get the stack trace.
Arguments:
Arg1: 00000099, A PTE or PFN is corrupt
Arg2: 0004d4f9, page frame number
Arg3: 00000002, current page state
Arg4: 0004d4ee, 0

Debugging Details:
------------------
BUGCHECK_STR:  0x4E_99
CUSTOMER_CRASH_COUNT:  1
DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT
PROCESS_NAME:  Mcshield.exe
CURRENT_IRQL:  2
LAST_CONTROL_TRANSFER:  from 82b066dc to 82af9d10
STACK_TEXT: 
aadbba50 82b066dc 0000004e 00000099 0004d4f9 nt!KeBugCheckEx+0x1e
aadbba68 82ac4598 c0006000 aadbbbf0 00000000 nt!MiBadShareCount+0x24
aadbbb7c 82ad6ad4 c0005eb8 c0005f38 855da4a8 nt!MiDeletePteRun+0x66a
aadbbc84 82ad0e41 00bd0000 00c50fff 8c5ea1d1 nt!MiDeleteVirtualAddresses+0x3c1
aadbbd1c 82a6044a ffffffff 02cbf828 02cbf824 nt!NtFreeVirtualMemory+0x60b
aadbbd1c 77a664f4 ffffffff 02cbf828 02cbf824 nt!KiFastCallEntry+0x12a
WARNING: Frame IP not in any known module. Following frames may be wrong.
02cbf75c 00000000 00000000 00000000 00000000 0x77a664f4
STACK_COMMAND:  kb
FOLLOWUP_IP:
nt!MiBadShareCount+24
82b066dc cc              int     3
SYMBOL_STACK_INDEX:  1
SYMBOL_NAME:  nt!MiBadShareCount+24
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: nt
DEBUG_FLR_IMAGE_TIMESTAMP:  4c1c3fac
IMAGE_NAME:  memory_corruption
FAILURE_BUCKET_ID:  0x4E_99_nt!MiBadShareCount+24
BUCKET_ID:  0x4E_99_nt!MiBadShareCount+24
Followup: MachineOwner

Si nos fijamos en MODULE_NAME y IMAGE_NAME este es el error, que tenemos, los bloques de memoria están corruptos, pero para asegurarnos de que es la memoria física, tenemos que usar este comando:
0: kd> !memusage
Search: READ_PVOID error
InitTypeRead(nt!MmPhysicalMemoryBlock, nt!_PHYSICAL_MEMORY_DESCRIPTOR) error 1
En este caso ya está más que claro, que es lo que está fallando y para detectar cual es el modulo de memoria que nos está fallando (en el caso de que tenemos más de 1 modulo) tenemos que realizar un test de la memoria física.

sábado, 19 de febrero de 2011

Debugging V Parte

En la V parte me gustaria hablar de una herrameinta no muy conocida que nos puede ser de gran ayuda en los casos que nuestro servidor tiene problemas con algun proceso o con los handles de algun proceso que nos pone la CPU al 100% y no podemos trabajar con el servidor, se queda bloqueado.
La herramienta se llama Notmyfault del creaador Mark Russinovich y sirve para provocar un el famoso pantallazo azul y a su vez el volcado de memoria.
En el archivo .rar que nos descargamos tenemos 2 ejecutables tanto para procesadores de X86 como para X64:
Ejecutamos el ejecutable Notmyfault de X86 o X64 (el que coincida con nuestro s.o.) y veremos la siguiente pantalla:
Como podeis ver tenemos varias opciones para realizar un volcado del S.O., si ejecutamos la 1ª opcion High IRQL fault (por ejemplo), el equipo se reiniciara y podemos ver como realiza el volcado de memoria en el BSOD:


Una vez completado el proceso de volcado de memoria y despues de que se reinicie el servidor al iniciar sesion, podemos observar el mismo codigo de error que en el pantallazo azul anteriormente mostrado:
Bien , pues ya teniendo el volcado de memoria lo podemos analizar con debugging tools y realizar el troubleshooting para localizar el fallo.
Un Saludo

Debugging IV Parte

En la IV parte os quiero comentar de la simple herrameinta con la cual se puede configurar los archivos dump en local. Ya se que pensais que para configurar el volcado de los archivos dump en local se puede hacer en las propiedades de sistema > Opciones avanzadas > Inicio y Recuperacion y listo, pero esta herramienta no solo lo puede hacer en el sistema local donde se esta ejecutando, si no tambien en remoto.
La herramienta se llama Dump Configurator.hta y se puede usar cuando no podemos acceder a un servidor por control remoto porque tiene la CPU al 100% y se reinicia o tiene el servicio RDP caido.





Pulsando en Change nos podemos conectar a cualquier servidor o pc de nuestra red local por el hostname o la IP que tengamos en nuestra empresa para cambia la configurarion del Volcado de memoria.
Espero que os sirva.
Un Saludo

jueves, 3 de febrero de 2011

Debugging III Parte

Para estar seguros que nuestro sistema podrá guardar los archivos de volcado, podemos comprobar que la unidad del sistema (normalmente C:\Windows) dispone de suficiente espacio libre, que el disco dispone de suficiente espacio libre y que el disco no esté corrupto.
Un volcado de memoria completo supone que el espacio libre necesario debe ser al menos igual a la cantidad de memoria física presente en el equipo. Hay que comprobar que hay espacio suficiente en la unidad del sistema para el máximo tamaño de archivo de paginación para el archivo de volcado.
Para evitar fragmentación del disco al crear el archivo de volcado de memoria es interesante establecer un tamaño fijo para el archivo de volcado como para el sistema, el tamaño deseado y recomendado por microsoft es de 1,5 tamaño de la memoria fisica y así no necesitar expandirlo mientras se crea el volcado de memoria.
Se ha de comprobar que la ruta del archivo de volcado de memoria, de forma predeterminada %systemroot%\Memory.dmp, dispone de suficiente espacio libre para almacenar el volcado.
Para utilizar con destreza la herramienta Windbg requiere largo tiempo de estudio ya que es una aplicacion bastante compleja, conocer todas las funcionalidades que pueda permitir esta herramienta. Sin embargo cuanto mas conocimientos se tenga de esta herramienta, mas informacion se obtendra y menos tiempo necesario se invertira. Entre los comandos fundamentales que se deben conocer aparte de los comando que he presentado en Debugging & Optimization II Parte son los siguientes:
!VM
La salida de este comando muestra las aplicaciones que usaban la memoria virtual junto con su distribucion en el momento del volcado.
.logappend
Permitira escribir todo el contenido de la shell en un archivo log.Es muy util para exportar todo lo que sacamos en pantalla de la shell y disponer de una bitacora de todos los comandos ejecutados hasta el momento.
.logappend D:\Windbg.log (en mi caso puse esta ruta de path, pero podeis poner la ruta cual os convenga mejor)
.logclose
Este comando cierra el log para su posterior analisis
!process 0 0 
Este comando informa sobre todos los procesos que se encontraban en ejecucion en el momento de la recojida del volcado de memoria.
!process 0 7
Este comando es para obtener datos asociados a los procesos, como puedes ser los hilos de ejecucion.
.process
Establece el contexto para un proceso determinado.
lm t n
Muestra una lista de los modulos que se encontraban cargados en la memoria antes de realizar el volcado.
dt (Display Type process)
Este comando es capaz de mostrar la estructura de una variable ya sea local o global y su tipo de dato.Por ejemplo el objeto EPROCESS:
kd> dt nt!_EPROCESS
   +0x000 Pcb              : _KPROCESS
   +0x078 ProcessLock      : _EX_PUSH_LOCK
   +0x080 CreateTime       : _LARGE_INTEGER
   +0x088 ExitTime         : _LARGE_INTEGER
   +0x090 RundownProtect   : _EX_RUNDOWN_REF
   +0x094 UniqueProcessId  : Ptr32 Void
   +0x098 ActiveProcessLinks : _LIST_ENTRY
   +0x0a0 QuotaUsage       : [3] Uint4B
   +0x0ac QuotaPeak        : [3] Uint4B
   +0x0b8 CommitCharge     : Uint4B
   +0x0bc PeakVirtualSize  : Uint4B
   +0x0c0 VirtualSize      : Uint4B
   +0x0c4 SessionProcessLinks : _LIST_ENTRY
   +0x0cc DebugPort        : Ptr32 Void
   +0x0d0 ExceptionPort    : Ptr32 Void
   +0x0d4 ObjectTable      : Ptr32 _HANDLE_TABLE
   +0x0d8 Token            : _EX_FAST_REF
   +0x0dc WorkingSetPage   : Uint4B
   +0x0e0 AddressCreationLock : _KGUARDED_MUTEX
   +0x100 HyperSpaceLock   : Uint4B
   +0x104 ForkInProgress   : Ptr32 _ETHREAD
   +0x108 HardwareTrigger  : Uint4B
   +0x10c PhysicalVadRoot  : Ptr32 _MM_AVL_TABLE
   +0x110 CloneRoot        : Ptr32 Void
   +0x114 NumberOfPrivatePages : Uint4B
   +0x118 NumberOfLockedPages : Uint4B
   +0x11c Win32Process     : Ptr32 Void
   +0x120 Job              : Ptr32 _EJOB
   +0x124 SectionObject    : Ptr32 Void
   +0x128 SectionBaseAddress : Ptr32 Void
   +0x12c QuotaBlock       : Ptr32 _EPROCESS_QUOTA_BLOCK
   +0x130 WorkingSetWatch  : Ptr32 _PAGEFAULT_HISTORY
   +0x134 Win32WindowStation : Ptr32 Void

!cpuinfo
Muestra la informacion de la CPU.
!sysinfo
Permite mostrar info acerca de los objetos del sistema analizados como la BIOS, la CPU, etc.
!reg
Con este comando accedemos al registro del s.o. este mostrara las claves de registro almacenadas en la memoria en un instante concreto.

miércoles, 2 de febrero de 2011

Debugging II Parte

Después de la pequeña introducción en la I parte, vamos a hablar en esta II parte de la instalación, configuración y el uso de esta herramienta.
Descargar e instalar la herramienta del siguiente Link una vez instalada vamos a pasar a la configuracion de la misma para que se descargue los symbols y entramos en File>Symbol File Path... o con Ctrl+S y se nos abrirá esta misma ventana :




Donde tenemos que añadir el siguiente comando con la url de los symbols para que se lo descargue:
SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Pero antes tendríamos que crear un directorio en C$ con el mismo nombre "websymbols" o poner el nombre que os convengan, en mi caso es el mismo "websymbols". Una vez que ya hemos creado el directorio,

le pegamos toda la linea, pulsamos OK y quedara de asi:



Una vez que ya tenemos esta parte hecha ya podemos abrir el  archivo .dmp (DUMP) en  File>Open Crash Dump y cuando se abre la ventana tenemos que ir a  %systemroot%\Minidump (en este directorio el sistema guarda los volcados de memoria) para seleccionar el archivo .dmp.
Se abrirá el archivo dump (al abrir el primer archivo dump va tardar un poco por el motivo de que se está descargando los Symbolos de la url que le hemos configurado antes)
Podemos empezar con el comando:
!analyze –v
Con este comando podemos ver todos los detalles de archivo dump.
0: kd> !analyze -v
PFN_LIST_CORRUPT (4e)
Typically caused by drivers passing bad memory descriptor lists (ie: calling
MmUnlockPages twice with the same list, etc).  If a kernel debugger is
available get the stack trace.
Arguments:
Arg1: 00000099, A PTE or PFN is corrupt
Arg2: 0004d4f9, page frame number
Arg3: 00000002, current page state
Arg4: 0004d4ee, 0

Debugging Details:
------------------
BUGCHECK_STR:  0x4E_99
CUSTOMER_CRASH_COUNT:  1
DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT
PROCESS_NAME:  Mcshield.exe
CURRENT_IRQL:  2
LAST_CONTROL_TRANSFER:  from 82b066dc to 82af9d10
STACK_TEXT:
aadbba50 82b066dc 0000004e 00000099 0004d4f9 nt!KeBugCheckEx+0x1e
aadbba68 82ac4598 c0006000 aadbbbf0 00000000 nt!MiBadShareCount+0x24
aadbbb7c 82ad6ad4 c0005eb8 c0005f38 855da4a8 nt!MiDeletePteRun+0x66a
aadbbc84 82ad0e41 00bd0000 00c50fff 8c5ea1d1 nt!MiDeleteVirtualAddresses+0x3c1
aadbbd1c 82a6044a ffffffff 02cbf828 02cbf824 nt!NtFreeVirtualMemory+0x60b
aadbbd1c 77a664f4 ffffffff 02cbf828 02cbf824 nt!KiFastCallEntry+0x12a
WARNING: Frame IP not in any known module. Following frames may be wrong.
02cbf75c 00000000 00000000 00000000 00000000 0x77a664f4
STACK_COMMAND:  kb
FOLLOWUP_IP:
nt!MiBadShareCount+24
82b066dc cc              int     3
SYMBOL_STACK_INDEX:  1
SYMBOL_NAME:  nt!MiBadShareCount+24
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: nt
DEBUG_FLR_IMAGE_TIMESTAMP:  4c1c3fac
IMAGE_NAME:  memory_corruption
FAILURE_BUCKET_ID:  0x4E_99_nt!MiBadShareCount+24
BUCKET_ID:  0x4E_99_nt!MiBadShareCount+24
Followup: MachineOwner

Si nos fijamos en MODULE_NAME y IMAGE_NAME este es el error, que tenemos, los bloques de memoria están corruptos, pero para asegurarnos de que es la memoria física, tenemos que usar este comando:
0: kd> !memusage
Search: READ_PVOID error
InitTypeRead(nt!MmPhysicalMemoryBlock, nt!_PHYSICAL_MEMORY_DESCRIPTOR) error 1
En este caso ya está más que claro, que es lo que está fallando y para detectar cual es el modulo de memoria que nos está fallando (en el caso de que tenemos más de 1 modulo) tenemos que realizar un test de la memoria física.

Otro archivo DUMP con otro error y esta vez no por fallo fisico si no por fallo del software/drivers:

kd> !analyze -v
BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 00000020, a pool block header size is corrupt.
Arg2: edf60120, The pool entry we were looking for within the page.
Arg3: edf60188, The next pool entry.
Arg4: 0c0d0403, (reserved)
Debugging Details:
------------------
BUGCHECK_STR:  0x19_20
POOL_ADDRESS:  edf60120
CUSTOMER_CRASH_COUNT:  1
DEFAULT_BUCKET_ID:  DRIVER_FAULT_SERVER_MINIDUMP
PROCESS_NAME:  cmd.exe
CURRENT_IRQL:  0
LAST_CONTROL_TRANSFER:  from 808927bb to 80827c83
STACK_TEXT: 
b2879250 808927bb 00000019 00000020 edf60120 nt!KeBugCheckEx+0x1b
b28792b8 f7b7ac3c edf60128 00000000 f7b7c2bd nt!ExFreePoolWithTag+0x477
b2879370 f7b7ac7f a2a3e0e8 f080daf0 edd46cd8 Ntfs!NtfsAddDosOnlyName+0x1d1
b28793ac f7b904af a2a3e0e8 00000001 20811000 Ntfs!NtfsAddLink+0xac
b28795a8 f7b94a04 a2a3e0e8 a07330d0 a0733260 Ntfs!NtfsCreateNewFile+0x847
b28797cc f7b91ef8 a2a3e0e8 a07330d0 b287980c Ntfs!NtfsCommonCreate+0x1226
b28798d0 8081df85 a4b855a8 a07330d0 a533cb88 Ntfs!NtfsFsdCreate+0x17d
b28798e4 f723a458 a07330d0 a533cb88 a42e04b0 nt!IofCallDriver+0x45
b2879910 8081df85 a4358e78 a07330d0 b2879a30 fltmgr!FltpCreate+0xe4
b2879924 f7b1e203 b2879a30 a1564308 a1564364 nt!IofCallDriver+0x45
WARNING: Stack unwind information not available. Following frames may be wrong.
b2879964 f7b0117d b2879a30 a0733284 a421ec30 mfehidk+0x26203
b2879988 f7b01f2d 00000002 a0733284 a33f3c08 mfehidk+0x917d
b2879a20 f7b1d45b cccccccc a52bcc38 a3f35168 mfehidk+0x9f2d
b2879a48 8081df85 a3f35168 a07330d0 a07330d0 mfehidk+0x2545b
b2879a5c 808f904b b2879c04 a52d1bb0 00000000 nt!IofCallDriver+0x45
b2879b44 80937a20 a52d1bc8 00000000 a1d68610 nt!IopParseDevice+0xa35
b2879bc4 80933b54 00000000 b2879c04 00000042 nt!ObpLookupObjectName+0x5b0
b2879c18 808eaeff 00000000 00000000 879c8801 nt!ObOpenObjectByName+0xea
b2879c94 808ec199 0013fc14 40100080 0013fbb0 nt!IopCreateFile+0x447
b2879cf0 808eec28 0013fc14 40100080 0013fbb0 nt!IoCreateFile+0xa3
b2879d30 808897cc 0013fc14 40100080 0013fbb0 nt!NtCreateFile+0x30
b2879d30 7c82860c 0013fc14 40100080 0013fbb0 nt!KiFastCallEntry+0xfc
0013fc0c 00000000 00000000 00000000 00000000 0x7c82860c
STACK_COMMAND:  kb
FOLLOWUP_IP:
mfehidk+26203
f7b1e203 ??              ???
SYMBOL_STACK_INDEX:  a
SYMBOL_NAME:  mfehidk+26203
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: mfehidk
IMAGE_NAME:  mfehidk.sys
DEBUG_FLR_IMAGE_TIMESTAMP:  4a79a9b2
FAILURE_BUCKET_ID:  0x19_20_mfehidk+26203
BUCKET_ID:  0x19_20_mfehidk+26203
Followup: MachineOwner

En el Module_Name y en Image_Name nos muestra cual es el proceso y el driver que ha provocado el volcado y el reinicio.
0x19 Error Check: BAD_POOL_HEADER
La comprobación de errores BAD_POOL_HEADER tiene un valor de 0x00000019. Esto indica que el encabezado del bloque está dañado.
El problema es porque el pool  está dañado.
Para ver cual es la causa y poder indentificar mejor el fallo teneis que usar las opciones disponibles de !analyze que son: 
-v
Salida de info extendida por pantalla
-f
Genera información sobre la excepción. Se usa para ver un análisis de la excepción aún si el depurador no la ha detectado.
-hang
Genera información sobre el pete de la aplicación.  
-D BucketID
Sólo muestra aquéllos elementos que son relevantes al BucketID especificado. 
-show
Muestra en pantalla la información sobre el código de stop especificado. 
-c
Sigue con la depuración cuando el depurador se encuentra con un problema conocido. Si el problema no es uno conocido, el depurador permanecerá detenido.
Podemos usar -c con ciertos subparámetros, que configuran la lista de problemas conocidos y de porsí no se ejecutan, hasta que usemos !analyze -c -load al menos una vez. !analyze -c no tiene ningún efecto.
-load Archivoconocidos
Carga un archivo de problemas conocidos. Archivoconocidos específica la ruta y el nombre del archivo a cargar. Debe estar en formato xml.  Se usará en todos los análisis posteriores con el parámetro !analyze -c hasta que se descargue el archivo o se cargue otro nuevo que sustituya al cargado. 
-unload
descarga la lista de problemas conocidos.
-help
Muestra ayuda para la extensión !analyze -c en la ventana de comandos del depurador.
BugCheckCode
Específica el código de stop a mostrar.
BugParameters
Especifica hasta cuatro parámetros del código separados por espacios. Ese parámetro nos permite mayor refinamiento en la especificación de los cuatro parámetros.
Con el comando LMV M controlador-que-queremos-analizar
3: kd> lmv m mfehidk
start    end        module name
f7af8000 f7b49c40   mfehidk  T (no symbols)          
    Loaded symbol image file: mfehidk.sys
    Image path: mfehidk.sys
    Image name: mfehidk.sys
    Timestamp:        Wed Aug 05 17:48:02 2009 (4A79A9B2)
    CheckSum:         00059EED
    ImageSize:        00051C40
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

Podemos ver los detalles del controlador como la fecha/hora de cuando se ha creado este controlador por el fabricante y no es la fecha de cuando se instalo.

Saludos

Debugging

En este articulo quiero hablar de las herramientas Debugging Tools, más abajo vamos a ver las definiciones de las Aplicaciones, Procesos, Threads y CallStacks una vez que ya sabemos estas definiciones nos podemos defender con las aplicaciones de Debugging.
Aplicaciones, procesos y threads
Una aplicación está formada por uno o más procesos
Un proceso es un ejecutable (.exe) que está en memoria y que está formado por uno o más threads (hilos de ejecución) y sus propios recursos
Piensa en un proceso como en un contenedor de threads
Un thread es la unidad básica de ejecución para la que el sistema operativo reserva tiempo de procesador para llevar a cabo una tarea
Un thread es lo que la CPU ejecuta. Todo proceso vivo ha de tener al menos un thread, y a menudo tiene varios.
Thread Call Stacks
Foto de un thread en un instante de tiempo
Muestra la historia de llamadas a funciones
Cada thread tiene su propio Call Stack
Ejemplo:
ntdll!KiFastSystemCallRet
USER32!NtUserGetMessage+0xc
notepad!WinMain+0xe5
notepad!WinMainCRTStartup+0x174
kernel32!BaseProcessStart+0x23
Cada hilo(Thread) de un proceso tiene su Call Stack independiente. Con el Windbg (Debugging Tools for Windows) podemos ver los call stack de alguna aplicación común, como notepad.exe o calc.exe por ejemplo.
Aquí os dejo un procedimiento que habría que seguir para determinar la causa y ubicar el fallo de nuestro Sistema Operativo.
Los volcados.
Modo-kernel:
Completo: volcado de tamaño más grande, contendrá la memoria física del equipo en el momento del error. Lo que implica que el archivo de paginación deba tener al menos el tamaño de la memoria real + 1MB.
El volcado se guarda en la raíz del sistema  %systemroot%\Minidump con el nombre de memory.dmp, y en el caso de volcados posteriores, irían sustituyendo al existente (si tenemos la pestaña de sobrescribir marcada) de lo contrario si la pestaña no está marcada, se grabaran los archivos .dmp con el siguiente nombre Mini011811-01.dmp (donde se muestra la fecha y el nº de fichero creado este día, si hay varios reinicios serian 01,02,03,04,etc.
Memoria Kernel: Con un tamaño significativamente menor contiene la memoria ocupada por el kernel en el momento del error. Es decir, ni memoria no asignada, ni la que está asignada a aplicaciones en modo usuario, sólo la usada por el kernel, HAL, y la asignada a controladores y programas en modo kernel.
En general es el volcado más útil y se guarda en la raíz del sistema con el nombre memory.dmp (este nombre lo tendrá si tenemos la pestaña de sobrescribir marcada).
Volcado pequeño: Con un tamaño de 64KB es el más pequeño de todos y por tanto sólo requiere un archivo de paginación de ese tamaño.
Su contenido es:
- Mensaje del código de stop y sus parámetros.
- El contexto del procesador que ha cascado.
- La información del proceso y el contexto kernel, del proceso que ha petado.
- La información del hilo y el contexto kernel, del proceso que ha petado.
- La pila de llamadas en modo kernel para el hilo que ha petado. Sólo hasta 16KB, los de arriba de la pila.
- Una lista de los controladores cargados.
Además, si es Windows XP o posterior:
- Una lista de módulos cargados y descargados.
- El bloque de datos del depurador (información de depuración básica del sistema).
- Cualquier página de memoria que Windows crea que es útil en la depuración de errores. (Las páginas de datos a qué apuntan los registradores en el momento del pete y otras que hayan sido solicitadas específicamente por el componente que falla).
Procedimiento a seguir para resolver problemas:
Determinar el tipo de fallo: Access Violation, resultado inesperado…
Documentar los síntomas: Memory Leak, 100% CPU, Crash…
Elegir las herramientas y técnicas adecuadas:
  - Habilitar tracing en la aplicación.
  - Usar logs de debug o “checked builds”.
  - Perfmon, EventLogs, Netmon, Filemon, logs de IIS, MSDN, etc.
  - Conseguir dumps y analizarlos.
Bien, una vez que tenemos claro todo esto, podemos empezar a hablar de las herramientas de Debbuging.
Para analizar el archivo de volcado que se genera al "colgarse" el sistema operativo necesitaremos un depurador y los símbolos pertenecientes al sistema operativo en el que se ha producido ese dump.
Windbg es una herramienta de depuración tanto en modo kernel como en modo usuario, con ella analizaremos los volcados.
Cuando pasa un error en modo kernel Windows nos saluda con una pantalla azul y la info sobre el código de stop. Esto puede modificarse, de manera que:
- Se puede asignar un depurador (como windbg o KD).
- Se grabe el archivo de volcado de memoria (dump).
- Se produzca un reinicio automático del sistema.
- Se grabe el volcado y reinicie el sistema inmediatamente después.

Saludos