Pantallas Azules en XP y cómo analizarlas 1/3

Fassou

Creo que puede ser interesante para muchos el artículo de Jose Manuel Tella Llop, sobre las pantallas azules en XP y cómo interpretar la información que muestran así que lo voy a copiar literalmente :

Uno de los peores errores en los que nos podemos encontrar es una pantalla azul (BSOD: Blue Screen of Death), congelaciones de la pantalla -cursor y teclado no responden- o reinicios espontáneos.

Empecemos desde el más sencillo:

Reinicios espontáneos: en Windows XP, estos reinicios espontáneos suelen ser producidos por tener marcado "Reiniciar Automáticamente" (es la opción por defecto). Dicha opción se modifica con botón derecho sobre Mi PC, propiedades, pestaña de avanzado y botón de inicio y recuperación.

Un reinicio espontáneo es, o bien porque iba a salir una pantalla azul, y al estar seleccionada la opción anterior, en vez de salir, el sistema se reinicia, o bien por un error hardware que el sistema operativo no ha podido atrapar. Si es la primera opción, simplemente debemos configurar para que NO se reinicie automáticamente y dejar que el sistema atrape el error. Si a pesar de eso, siguen los reinicios, implica entonces un error hardware y grave: normalmente placa madre o CPU y poco más podemos diagnosticar en este caso.

Pantalla azul: en este caso, nos dará en pantalla un mini-informe del error. Únicamente debemos fijarnos si en dicho mensaje aparece un .sys causante del error. Si no aparece este .sys, o lo que aparece son componentes de Windows (ntoskrln, win32k.sys, esbstor.sys, usbyhci.sys), deberemos analizar el archivo DMP que se produce (lo veremos posteriormente).
Si el driver que aparece es un archivo de terceros: ya tenemos localizado al culpable. La solución será actualizar dichos drivers, o dicho componente (los antivirus, si no ha existido cambio de hardware, suelen ser los primeros candidatos).

Un elevado número de veces no sale ningún .sys o .dll causante del error. En ese caso, no nos queda más remedio también que analizar el archivo DMP.

Por desgracia, la utilidad DUMPCHK que viene en las Support Tools de windows XP / W2003 poco nos sirve para analizar el error ya que únicamente nos mostrará lo mismo que nos muestra Windows en la pantalla azul. Por tanto, si Windows al generar la pantalla azul no ha sido capaz de mostrarlo, este herramienta no nos servirá de nada. Más adelante veremos qué herramienta debemos utilizar para ello.

Fassou

Congelaciones de la pantalla: Es un caso similar al 2). Tendremos que analizar el DMP. Ahora bien, ¿cómo podemos en este caso hacer que el sistema nos genere un DMP si el sistema está congelado?

(NO VÁLIDO PARA TECLADOS USB/BLUETOOTH): Para ello, previamente debemos tener configurado el registro para que una combinación de teclas nos provoque el DUMP aunque todo esté congelado. Por tanto, y es mi consejo que por defecto lo tengamos configurado, debemos tener una variable en la clave:

HKEY_LOCAL_MACHINE
System
CurrentControlSet
Services
i8042prt
Parameters

Nombre: CrashOnCtrlScroll
Tipo: DWORD (doble palabra)
Contenido: 1

(y reiniciar la máquina para que esté activo). Con esto, en cualquier momento, e incluso en caso de congelación de la pantalla, podremos provocar el DMP, pulsando la tecla CTRL (derecha) y dos veces consecutivas la tecla SCROLL BLOCK (bloqueo de desplazamiento).

TIPOS DE VOLCADO DE MEMORIA

Existen tres tipos de volcado de memoria, los cuales están activados desde: botón derecho sobre Mi PC, propiedades, pestaña de avanzado y botón de inicio y recuperación:

Minidump (64 KB: Realmente vale para poco y no es la mejor opción Si la tenemos activada, nos generará un "minidump" en \windows\minidump
Kernel.dmp: opción intermedia: solo se vuelca el kernel (núcleo) y en la mayoría de los casos es suficiente para diagnosticar el error. Genera el archivo MEMORY.DMP en la carpeta Windows.
Completo: para que el DMP completo funcione y no salga "corrupto", es obligatorio tener el archivo de paginación en la misma partición en la cual tenemos Windows. Generará igualmente en ella el archivo MEMORY.DMP

Muchas veces por motivos de rendimiento movemos el archivo de paginación a otro disco físico. Si tenemos BSOD del sistema y deseamos un volcado de memoria completo, deberemos previamente volver a establecer el archivo de paginación en la unidad de Windows. Igualmente debemos recordar que en este caso, debemos tener espacio en disco igual a la memoria física de la máquina ya que ese será el tamaño del archivo DMP creado.
SOFTWARE NECESARIO PARA EL ANALISIS DEL ERROR

La información podemos localizarla en esta página:
http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx

y el software que nos debemos descargar para versiones de 32 bits es este:
http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

El software puede instalarse tanto en la propia máquina como en una máquina ajena. No es necesario analizar el archivo .DMP en la misma máquina en la cual ha sucedido el error, pudiendo hacerse en cualquier otra.

PRIMERA CONFIGURACIÓN DEL SOFTWARE

Aunque no es necesario, para poco nos vale un error si no tenemos instalados los ficheros de símbolos. Los símbolos de drivers de terceros no podremos instalarlos porque los fabricantes normalmente no los dan, pero los símbolos de Windows sí que podremos. No aconsejo instalarlo desde el CD, ni descargarse del sitio de Microsoft los símbolos ya que la propia herramienta instalada: WINDBG, una vez configurada, si no tiene los símbolos los descargará en ese momento, y descargará justo los necesarios para ese análisis teniendo en cuenta por tanto los Service Packs y parches que tiene instalados el sistema que estamos analizando.

Para configurarlos de esa manera arrancamos el programa de análisis que hemos instalado: WINDBG y en el menú "File", "Symbol File Path" colocamos:

SRVc:\websymbolshttp://msdl.microsoft.com/download/symbols

(en este caso he seleccionado que los símbolos, cuando los descargue, -por ello la primera vez de análisis será lenta, dependiendo de la velocidad de nuestra conexión a Internet- los sitúe en la carpeta: c:\websimbols)

Dicha carpeta puede ser cualquier otra, y lo único que tener presente es que debemos tenerla creada previamente.

Fassou

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

Bugcheck Analysis *

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

Bugcheck Analysis *

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

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

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

marcelot

Estupendo xD .Que trbajas para Willi???. Deveria ser fijado.
Por otro lado, recien termino de ensamblar mi nueva pc y tengo pantallazos azules y 1/2segundo despues se reinicia aunque no este haciendo nada. :susto:

marcelot

FASSOU: me podrias decir quetengo que hacer cuando en la pantalla azul me aparece win32k.sys????ya no se que hacer con los pantallazos, desinstale todos los drivers pero nada.

Yorus

Muy interesante. Acabo de añadir la web de ese señor a mis Marcadores ;).

Rober

Hola, tengo un problema con XP. Desde hace unos dias cada vez que arranco algun juego, primero se me pone la pantalla en negro y luego me da un pantallazo azul y se me reinicia. Porque puede ser?Que tengo que hacer para arreglarlo?

Gracias por adelantado

krampak

Que hace esta guia perdida en el fondo del foro? No la habia visto

Yorus

Ni me acordaba, y eso que últimamente me hubiera venido bién. 5 estrellas y nota positiva para Fassou.

cobito

Que alguien lo fije.

krampak

Cuando has posteado ya hacia media hora que estaba fijado

Fassou

Gracias por los puntitos Yorus ;D

morfeo27

@Fassou:

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

Bugcheck Analysis *

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

Bugcheck Analysis *

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

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

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

Sirocco

IM PRESIONANTE

Mira que siempre me había picado el gusanillo de qué significaba el contenido de las pantallas azules…

Esto se va de cabeza a los bookmarks.

Gracias!

_Neptunno_

morfeo27, el DRIVER_IRQL_NOT_LESS_EQUAL creo que trata sobre un problema de tener asignadas varias cosas a un mismo IRQ. A mi me paso esto con los puertos USB, ade+ me paso despues de hacer el idiota en la bios y tocar las IRQ , creo que tambien tiene algo que ver con el SP2….no se que leches hacen en microsoft, pero cada SP da mas problemas que soluciones, aggg!!

Caparso

Muy interesante la información, la suerte de entrar en esta pagina es que cada dia aprendes cosas nuevas.

Un saludo

Demon_82

@_Neptunno_:

morfeo27, el DRIVER_IRQL_NOT_LESS_EQUAL creo que trata sobre un problema de tener asignadas varias cosas a un mismo IRQ. A mi me paso esto con los puertos USB, ade+ me paso despues de hacer el idiota en la bios y tocar las IRQ , creo que tambien tiene algo que ver con el SP2….no se que leches hacen en microsoft, pero cada SP da mas problemas que soluciones, aggg!!

A mi el DRIVER_IRQL_NOT_LESS_EQUAL me lo causaba un disco SATA que estaba en las últimas… y me hacia referencia al AC'97 de la placa base, que el pobre no tenía anda que ver. De los que tengo vistos el DRIVER_IRQL_NOT_LESS_EQUAL es el mensaje de pantallazo azul que más temo por ya no estar seguro nunca de dónde sale ;D

krampak

El IRQL_NOT_LESS_EQUAL es el pantallazo que me encuentro siempre yo cuando me paso con el OC… si envez de reiniciar o colgarse sale un pantallazo siempre da ese error.. (o casi siempre).

anblue

Menuda esplicasion, wena guia si señor! mola

denon_barna

Llevo unos dias que cuando me levanto por la mañana y voy a mirar las descargas del emule, me encuentro con un pantallazo azul, el SO es Windows XP SP1+parche Blaster+Parche Sasser nunca instalo el SP2. El SP1 lo instalo para tener soporte al USB 2.0 porque si no tampoco lo instalaria.

Tengo 4 Pcs asi en casa y nunca he tenido ningun problema y es mas el resto de equipos que he montado les instalo lo mismo y siempre 0 problemas y han sido bastantes.

Se que me direis que tengo que instalar el SP2, quizas a partir de ahora lo haga con el nuevo hardware de los proximos pc que monte, ya que algunas aplicaciones no funcionan si no esta instalado el SP2, por ejemplo instale una webcam Logitech el otro dia y si no se lo instalaba no iba bien.

La proxima vez que me pase hare un foto a la pantalla para postearla, porque la captura no lo puedo hacer ya que la unica forma de entrar de nuevo a Windows es apagar el pc manteniendo pulsado unos segundos el boton de encendido.

Ayer estuve mirando el visor de sucesos y vi que habia varios errores pero los borre, deberia haberlos dejado para poder postearlos, pero no lo hice.

Por lo que ahora estoy totalmente perdido de que puede ser. He leido en el google que uno de los fallos que da es por el zone alarm relacionado con el true vector.

El caso es que tengo una imagen de sistema hecha con el Ghost, y supuse que restaurandola se solucionaria el problema, ya que esta imagen la he usado en infinidad de ocasiones y nunca a dado problemas, despues instale la ultima version del Zone Alarm por si acaso.

Pero esta mañana cuando fui a mirar como iban las descargas del emule, me encontrado de nuevo con una pantalla azul. Asi que fui al visor de sucesos y me encontre con los siguiente:

Error de aplicación.

Windows guardó el Registro de usuario AMD64\primi mientras una aplicación o servicio todavía estaba usando el Registro durante el cierre de sesión. No se ha liberado la memoria usada por el Registro de usuario. Se descargará el Registro cuando ya no esté en uso.

Esto es debido a menudo por los servicios ejecutándose como cuentas de usuario. Intente configurar los servicios para ejecutarse en la cuenta ServicioLocal o ServicioRed.

Error del Servicio de instantáneas de volumen: error inesperado al llamar a la rutina CoCreateInstance. HR = 0x80040206.

El sistema de sucesos COM+ detectó un código de retorno incorrecto durante el procesamiento interno. HRESULT fue 8007043C en la línea 44 de d:\nt\com\com1x\src\events\tier1\eventsystemobj.cpp. Póngase en contacto con el departamento de Soporte técnico de Microsoft para informar de este error.

Windows guardó el Registro de usuario AMD64\Administrador mientras una aplicación o servicio todavía estaba usando el Registro durante el cierre de sesión. No se ha liberado la memoria usada por el Registro de usuario. Se descargará el Registro cuando ya no esté en uso.

Esto es debido a menudo por los servicios ejecutándose como cuentas de usuario. Intente configurar los servicios para ejecutarse en la cuenta ServicioLocal o ServicioRed.

Error del Servicio de instantáneas de volumen: error inesperado al llamar a la rutina CoCreateInstance. HR = 0x80040206.

El sistema de sucesos COM+ detectó un código de retorno incorrecto durante el procesamiento interno. HRESULT fue 8007043C en la línea 44 de d:\nt\com\com1x\src\events\tier1\eventsystemobj.cpp. Póngase en contacto con el departamento de Soporte técnico de Microsoft para informar de este error.

Error de sistema.

DCOM ha obtenido un error "El servicio no puede iniciarse en modo a prueba de errores " al intentar iniciar el servicio EventSystem con argumentos "" para ejecutar el servidor:
{1BE1F766-5536-11D1-B726-00C04FB926AF}

DCOM ha obtenido un error "El servicio no puede iniciarse en modo a prueba de errores " al intentar iniciar el servicio StiSvc con argumentos "" para ejecutar el servidor:
{A1F4E726-8CF1-11D1-BF92-0060081ED811}

El controlador de inicialización siguiente no se cargó correctamente:
Avg7Core
Avg7RsW
Avg7RsXP
Fips
IPSec
lusbaudio
MRxSmb
NetBIOS
NetBT
Processor
RasAcd
Rdbss
Tcpip
vsdatant

El servicio TrueVector Internet Monitor depende del servicio vsdatant, el cual no pudo iniciarse debido al siguiente error:
Uno de los dispositivos vinculados al sistema no funciona.

El servicio Servicios IPSEC depende del servicio Controlador IPSEC, el cual no pudo iniciarse debido al siguiente error:
Uno de los dispositivos vinculados al sistema no funciona.

El servicio Cliente DNS depende del servicio Controlador de protocolo TCP/IP, el cual no pudo iniciarse debido al siguiente error:
Uno de los dispositivos vinculados al sistema no funciona.

El servicio Cliente DHCP depende del servicio NetBios a través de Tcpip, el cual no pudo iniciarse debido al siguiente error:
Uno de los dispositivos vinculados al sistema no funciona.

DCOM ha obtenido un error "El servicio no puede iniciarse en modo a prueba de errores " al intentar iniciar el servicio EventSystem con argumentos "" para ejecutar el servidor:
{1BE1F766-5536-11D1-B726-00C04FB926AF}

DCOM ha obtenido un error "El servicio no puede iniciarse en modo a prueba de errores " al intentar iniciar el servicio netman con argumentos "" para ejecutar el servidor:
{BA126AE5-2166-11D1-B1D0-00805FC1270E}

Tambien he mirado en el administrador de dispositivos por si habia algun conflicto de hardware y esta todo OK.
Lo extraño es que lo hace siempre con el Emule bajando archivos debo fijarme si durante el dia lo hace tambien,si fuese problema de software, al restaurar la imagen ya no deberia de volver a pasar.

Estoy pensando, en volver a instalar todo de nuevo, pero no creo que se solucione nada, porque al restaurar la imagen, es practicamete lo mismo que instalarlo todo aplicacion por aplicacion.

Pantallas Azules en XP y cómo analizarlas 1/3

Followup: MachineOwner

Debugging Details:

Followup: MachineOwner

Followup: MachineOwner

Debugging Details:

Followup: MachineOwner

Foreros conectados [Conectados hoy]

Estadísticas de Hardlimit