VOLCADO DE MEMORIA (DMP o DUMP). ANALISIS DE LOS ARCHIVOS
Un vez configurado tal y como está descrito anteriormente, procedemos a abrir el DUMP con windbg, en el menú "File" y la opción "Open Crash Dump". Podemos abrir cualquier archivo de dump, estemos o no en la máquina que ha causado el casque. Incluso puede abrirse en remoto por ADSL, por ejemplo y aunque el DUMP será de muchas megas, normalmente con sólo leer la cabecera y poco más, estará en disposición de ver datos. En este caso vamos a abrir el DUMP desde otra máquina por red.
NOTA 1: la primera vez que analizamos un dump de un determinado sistema operativo (o con parches específicos), se bajará automáticamente del sitio de Microsoft los ficheros de símbolos necesarios. Por ello, debemos estar conectados a Internet y puede que esa primera vez tarde unos minutos en bajárselos.
Este es un "casque" real en un W2003 Server que está actuando como Controlador de Dominio. Estaba seleccionada la opción de "kernel dump". En la pantalla azul únicamente informó de MULTIPLE_IRP_COMPLETE_REQUESTS, sin dar mas información sobre el módulo causante del fallo.
Lo primero que debemos fijarnos en un DUMP es si en las líneas de cabecera cabecera nos indica si está "corrupto". Si lo estuviese, no nos vale para nada.
NOTA 2: Un dump puede estar corrupto, si tenemos la opción de DUMP completo de memoria y el fichero de paginación reside en otra unidad física. En ese caso, deberemos esperar a repetir el error una vez hayamos puesto el fichero de paginación en la misma unidad que Windows.
Resultado del analizador: (es conveniente leer todos, ya que nos va indicando versión del sistema operativo, parches instalados, etc…) Y sobre todo la parte final:
==============================================================================================
Microsoft (R) Windows Debugger Versión 6.4.0007.2
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [\ka000SRV\d$\WINDOWS\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available
Symbol search path is: SRVc:\websymbolshttp://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Server 2003 Kernel Versión 3790 (Service Pack 1) MP (4 procs) Free x86 compatible
Product: LanManNt, suite: TerminalServer SingleUserTS
Built by: 3790.srv03_sp1_rtm.050324-1447
Kernel base = 0x80800000 PsLoadedModuleList = 0x808af988
Debug session time: Thu May 19 19:32:53.800 2005 (GMT+2)
System Uptime: 0 days 0:05:14.483
Loading Kernel Symbols
…..................................................................
Loading unloaded module list
.
Loading User Symbols
PEB is paged out (Peb.Ldr = 7ffd800c). Type ".hh dbgerr001" for details
Use !analyze -v to get detailed debugging information.
BugCheck 44, {87e5a490, d75, 0, 0}
*** ERROR: Module load completed but symbols could not be loaded for ax88172.sys
*** ERROR: Module load completed but symbols could not be loaded for portmap.sys
*** ERROR: Module load completed but symbols could not be loaded for PfModNT.sys
*** ERROR: Module load completed but symbols could not be loaded for nfsrdr.sys
*** ERROR: Module load completed but symbols could not be loaded for dump_Fasttrak.sys
*** ERROR: Module load completed but symbols could not be loaded for winacusb.sys
*** ERROR: Module load completed but symbols could not be loaded for vmm.sys
*** ERROR: Module load completed but symbols could not be loaded for ctac32k.sys
*** ERROR: Module load completed but symbols could not be loaded for ctsfm2k.sys
*** ERROR: Module load completed but symbols could not be loaded for emupia2k.sys
*** ERROR: Module load completed but symbols could not be loaded for ha10kx2k.sys
*** ERROR: Module load completed but symbols could not be loaded for hap16v2k.sys
*** ERROR: Module load completed but symbols could not be loaded for ctoss2k.sys
*** ERROR: Symbol file could not be found. Defaulted to export symbols for drmk.sys -
*** ERROR: Module load completed but symbols could not be loaded for ctaud2k.sys
*** ERROR: Module load completed but symbols could not be loaded for e100b325.sys
*** ERROR: Module load completed but symbols could not be loaded for lstone2k.sys
*** ERROR: Module load completed but symbols could not be loaded for el90xbc5.sys
*** ERROR: Module load completed but symbols could not be loaded for MTXPARHM.sys
*** ERROR: Module load completed but symbols could not be loaded for pfc.sys
*** ERROR: Module load completed but symbols could not be loaded for drmkaud.sys
*** ERROR: Module load completed but symbols could not be loaded for ASAPIW2k.sys
*** ERROR: Module load completed but symbols could not be loaded for MTXPARHD.dll
*** ERROR: Module load completed but symbols could not be loaded for netmate2.sys
*** ERROR: Symbol file could not be found. Defaulted to export symbols for rpcxdr.sys -
*** ERROR: Module load completed but symbols could not be loaded for Fasttrak.sys
*** ERROR: Module load completed but symbols could not be loaded for VMNetSrv.sys
*** ERROR: Module load completed but symbols could not be loaded for TSKNF601.SYS
*** ERROR: Module load completed but symbols could not be loaded for ctprxy2k.sys
*** ERROR: Module load completed but symbols could not be loaded for PSXDRV.SYS
*** ERROR: Module load completed but symbols could not be loaded for memalloc.sys
*** Your debugger is not using the correct symbols ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** Type referenced: ocaData ***
Probably caused by : usbehci.sys
Followup: MachineOwner
==============================================================================
Bien, esta es la primera información del error. Aparece un nombre de módulo candidato: usbehci.sys el cual corresponde a uno de los drivers del propio Windows para USB. Al menos ya sabemos que el casque está provocado por "algo" que está en el bus USB.
Es extraño, a no ser un error hardware, que un driver del propio Microsoft sea el causante.
Fijémonos en que, en una línea superior, la propia salida del debugger nos aconseja:
**** Use !analyze -v to get detailed debugging information.
Por tanto en la línea inferior de la pantalla, procedemos a ejecutar ese comando:
===============================================================================
0: kd> !analyze -v
MULTIPLE_IRP_COMPLETE_REQUESTS (44)
A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed. This is a tough bug to find because
the easiest case, a driver actually attempted to complete its own packet
twice, is generally not what happened. Rather, two separate drivers each
believe that they own the packet, and each attempts to complete it. The
first actually works, and the second fails. Tracking down which drivers
in the system actually did this is difficult, generally because the trails
of the first driver have been covered by the second. However, the driver
stack for the current request can be found by examining the DeviceObject
fields in each of the stack locations.
Arguments:
Arg1: 87e5a490, Address of the IRP
Arg2: 00000d75
Arg3: 00000000
Arg4: 00000000
Debugging Details:
IRP_ADDRESS: 87e5a490
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x44
CURRENT_IRQL: 2
DEVICE_OBJECT: 8a055618
DRIVER_OBJECT: 8a14eaa8
IMAGE_NAME: usbehci.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 42435bb3
MODULE_NAME: usbehci
FAULTING_MODULE: ba27b000 usbehci
LAST_CONTROL_TRANSFER: from 808596ec to 8087b6be
STACK_TEXT:
f789ee10 808596ec 00000044 87e5a490 00000d75 nt!KeBugCheckEx+0x1b
f789ee48 ba11ddc4 87e5a490 88770eb0 8a0e1028 nt!IopfCompleteRequest+0x2f7
f789eeb0 ba11ea45 b70989c0 00000000 8083b28b USBPORT!USBPORT_CompleteTransfer+0x38c
f789eee0 ba11f558 026e6f44 8a0e10e0 8a0e10e0 USBPORT!USBPORT_DoneTransfer+0x137
f789ef18 ba120d58 8a0e1028 8083b28b 8a0e1230 USBPORT!USBPORT_FlushDoneTransferList+0x168
f789ef44 ba12eef2 8a0e1028 8083b28b 8a0e1028 USBPORT!USBPORT_DpcWorker+0x224
f789ef80 ba12f06a 8a0e1028 00000001 ffdffa40 USBPORT!USBPORT_IsrDpcWorker+0x380
f789ef9c 8083eb0f 8a0e164c 6b755044 00000000 USBPORT!USBPORT_IsrDpc+0x166
f789eff4 8083a92b b76d5d44 00000000 00000000 nt!KiRetireDpcList+0xca
STACK_COMMAND: .bugcheck ; kb
FOLLOWUP_NAME: MachineOwner
FAILURE_BUCKET_ID: 0x44_IMAGE_usbehci.sys_DATE_3_25_2005
BUCKET_ID: 0x44_IMAGE_usbehci.sys_DATE_3_25_2005
Followup: MachineOwner
===================================================================
La salida del comando nos da la explicación de por qué ocurre un MULTIPLE_IRP_COMPLETE_REQUESTS, básicamente nos informa de que un driver ha solicitado la ejecución de un IRP (IoCompleteRequest) pero el paquete ya había sido completado. Nos dice que es un problema no resuelto por el software y difícil de encontrar, ya que en el mejor de los casos, un driver erróneo que pidió su propio paquete dos veces, no suele ser lo que ha sucedido. Nos dice igualmente que lo más probable es que haya dos drivers diferentes, cada uno de ellos cree que el paquete es suyo y hacen intentos para completarlo. Por último indica que seguir la pista de esto no suele ser fácil.
Veamos que se equivoca, y que al menos en nuestro caso es sencillo de seguir ![;-) 😉](https://foro.hardlimit.com/assets/plugins/nodebb-plugin-emoji/emoji/android/1f609.png?v=cqj7hbmdbe4)
Si no fijamos igualmente en la parte anterior, nos da la dirección del IRP en estas líneas:
Arguments:
Arg1: 87e5a490, Address of the IRP
Arg2: 00000d75
Arg3: 00000000
Arg4: 00000000
Por tanto, vamos a pedir al debugguer que nos muestre el contenido de esa dirección ejecutando el comando: !IRP con la dirección anterior:
====================================================================
0: kd> !IRP 87e5a490
Irp is active with 3 stacks 3 is current (= 0x87e5a548)
No Mdl Thread 00000000: Irp stack trace.
cmd flg cl Device File Completion-Context
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000
Args: 00000000 00000000 00000000 00000000
[ f, 0] 0 c0 8a055618 00000000 b69de300-00000000 Success Error
\Driver\usbehci ax88172
Args: b70989c0 00000000 00220003 00000000
====================================================================
Esta última línea nos da todos los drivers que han intervenido "creyendo" que un paquete era suyo y han intentado completar la petición. Y al no ser realmente suya es lo que ha provocado el fallo del sistema. Vemos en la penúltima línea que son:
\Driver\usbehci ax88172
El primero corresponde al stack USB de Windows… y el segundo a un "dudoso" y no certificado driver de un dispositivo de red (una NIC LAN 10/100). El aix88712 es el chip que monta y su driver se llama igual.
Por tanto... ya sabemos quien ha sido el culpable ![:-) 🙂](https://foro.hardlimit.com/assets/plugins/nodebb-plugin-emoji/emoji/android/1f642.png?v=cqj7hbmdbe4)
El artículo se encuentra también en TrucoXP como podeis ver aquí
PD: Creo que no incumplo ninguna norma por referenciar esa web, ya que sus contenidos no tratan sobre temas prohibidos en este foro, ni compite con esta comercialmente, pero si algún moderador cree que no es adecuado puede borrar el post, aunque creo contiene una explicación interesante para aquellos que sufran pantallazos y estén buscando el origen del problema
¿De donde se puede descargar el programa windbg?esque cuando ejecuto el programa alcohol120% y le doy a seleccionar el archivo a grabar ,me sale un pantallazo azul que pone DRIVER_IRQL_NOT_LESS_EQUAL y en el registro del sistema pone origen del error:system error,Categoria:102,Suceso:1003 ¿de que puede ser este error?el equipo es nuevo y ayer mismo el alcohol funcionaba perfectamente el resto de aplicaciones,juegos,etc van perfectos¿puede ser un virus?Gracias