martes, 30 de abril de 2013

BSOD: Pantallazos azules y como identificarlos

Muchas veces realizando pruebas a los software nos encontramos con pantallazos azules los cuales muchas veces nos dejan con ese sabor amargo a "que paso?" "cual fue el problema?".

Muchas veces excedemos los buffers, pilas entre otros pero no sabemos interpretar el volcado que se realiza.


Antes de nada aclarar que un BSOD es un pantallazo azul. De sobra son conocidas las famosas pantallas azules de Windows que tan temidas son por el usuario y tan dificiles de interpretar son para el experto, en algunos casos dando auténticos quebraderos de cabeza por no saber identificar la causa del pantallazo. A continuación escribiré una breve guía para identificar la causa de un pantallazo azul. Lo primero que hay que conocer es que en Windows XP los pantallazos azules han sido reemplazados por la acción de reiniciar el equipo sin mostrarlo antes, quizás por la mala prensa que éstos han generado del sistema de Microsoft. Existen dos tipos de pantallazos azules, los que muestran el fichero causante y los que muestran una dirección y un error determinado, como pudiera ser PAGE FAULT IN NON PAGED AREA, IRQ NOT LESS OR EQUAL o KMODE EXCEPTION NOT HANDLED. En el caso de que el pantallazo azul nos muestre el fichero que produce el error, no hay ningún problema, porque ya sabemos quién esta generando el error, pero en el caso de que no muestre ningún fichero, procederemos a analizar el pantallazo azul. Lo primero que debemos hacer es activar la característica para que nos muestre las pantallas de error en lugar de reiniciar. Para ello vamos al Panel de Control / Sistema / Opciones avanzadas / Inicio y recuperación.


Nos aparece la siguiente imágen: En ella deberemos desmarcar la opción Reiniciar automáticamente para que nos muestre el pantallazo, y Volcado de memoria del núcleo (en la información de depuración) para poder identificar el pantallazo azul en caso de que no lo consigamos en los primeros pasos. Con un Volcado de memoria pequeño (64kb) no obtendríamos suficiente información para determinarlo. En el caso de tampoco conseguirlo con el volcado del núcleo, haríamos un volcado completo. Considerar que necesitamos en éste caso, tener al menos la capacidad de nuestra memoria RAM de espacio libre en nuestro disco, ya que se va a generar un dump de nuestra memoria.



He leído que para que el dump no resulte corrupto, hay que tener establecida la paginación de memoria virtual en la partición donde tengamos instalado el sistema operativo. Asi que, si no es así debemos proceder a ello, en la misma ventana de Opciones avanzadas pero en el primer botón: Rendimiento / Opciones avanzadas / Memoria virtual. Para analizar el dump, vamos a usar el Debugging Tools para 32bits (o para 64bits, AMD64 si posees uno), y aunque podemos descargar los simbolos desde la web, vamos a configurar el programa para que descargue automáticamente los simbolos según los necesite. Para ello, arrancamos el WinDBG, y en el menú File / Symbol File Path pegamos lo siguiente:

SRV*dir*http://msdl.microsoft.com/download/symbols

Donde dir es la ruta donde se descargarán los símbolos (por ejemplo: c:\simbolos). Asi pues, procedemos a ejecutar la opción File / Open Crash Dump y elegir el fichero MEMORY.DMP, generado por el Windows al recibir un pantallazo, que coloca en %SYSTEMROOT% (usualmente C:\WINDOWS). Estaremos analizando el pantallazo azul si todo ha ido bien:
Microsoft (R) Windows Debugger Versión 6.4.0007.2
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\WINDOWS\MEMORY.DMP]
[...]
Use !analyze -v to get detailed debugging information.

Probably caused by : usbehci.sys
Followup: MachineOwner

En este caso, podemos ver que el causante del error es un usbehci.sys junto a mucha más información que he obviado porque sería ya demasiada, pero que explica detalladamente el error y el motivo por el que ocurre. En el caso que se quiera obtener información más concreta sobre el bsod, convendría investigar un poco más sobre los argumentos, las direcciones de memoria que nos indica el windbg y el uso del !irp. Una cuestión a tener en cuenta, es que en caso de que suframos congelaciones o cuelgues en lugar de pantallazos, existe una forma de generar el dump. Vamos a Inicio / Ejecutar / regedit.exe, a la clave HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ i8042prt \ Parameters, donde crearemos un nuevo valor DWORD con el nombre: CrashOnCtrlScroll y valor: 1. Reiniciamos el equipo para que capte la información que acabamos de introducir, y, en el caso de producirse un cuelgue o congelamiento pulsamos CTRL (derecho) + BLOQ DESPL (2 veces) para provocar la generación del dump.

Más información en: http://www.emezeta.com/articulos/bsod-pantallazos-azules-y-como-identificarlos



Antes de nada aclarar que un BSOD es un pantallazo azul. De sobra son conocidas las famosas pantallas azules de Windows que tan temidas son por el usuario y tan dificiles de interpretar son para el experto, en algunos casos dando auténticos quebraderos de cabeza por no saber identificar la causa del pantallazo. A continuación escribiré una breve guía para identificar la causa de un pantallazo azul. Lo primero que hay que conocer es que en Windows XP los pantallazos azules han sido reemplazados por la acción de reiniciar el equipo sin mostrarlo antes, quizás por la mala prensa que éstos han generado del sistema de Microsoft. Existen dos tipos de pantallazos azules, los que muestran el fichero causante y los que muestran una dirección y un error determinado, como pudiera ser PAGE FAULT IN NON PAGED AREA, IRQ NOT LESS OR EQUAL o KMODE EXCEPTION NOT HANDLED. En el caso de que el pantallazo azul nos muestre el fichero que produce el error, no hay ningún problema, porque ya sabemos quién esta generando el error, pero en el caso de que no muestre ningún fichero, procederemos a analizar el pantallazo azul. Lo primero que debemos hacer es activar la característica para que nos muestre las pantallas de error en lugar de reiniciar. Para ello vamos al Panel de Control / Sistema / Opciones avanzadas / Inicio y recuperación. Nos aparece la siguiente imágen: En ella deberemos desmarcar la opción Reiniciar automáticamente para que nos muestre el pantallazo, y Volcado de memoria del núcleo (en la información de depuración) para poder identificar el pantallazo azul en caso de que no lo consigamos en los primeros pasos. Con un Volcado de memoria pequeño (64kb) no obtendríamos suficiente información para determinarlo. En el caso de tampoco conseguirlo con el volcado del núcleo, haríamos un volcado completo. Considerar que necesitamos en éste caso, tener al menos la capacidad de nuestra memoria RAM de espacio libre en nuestro disco, ya que se va a generar un dump de nuestra memoria. He leído que para que el dump no resulte corrupto, hay que tener establecida la paginación de memoria virtual en la partición donde tengamos instalado el sistema operativo. Asi que, si no es así debemos proceder a ello, en la misma ventana de Opciones avanzadas pero en el primer botón: Rendimiento / Opciones avanzadas / Memoria virtual. Para analizar el dump, vamos a usar el Debugging Tools para 32bits (o para 64bits, AMD64 si posees uno), y aunque podemos descargar los simbolos desde la web, vamos a configurar el programa para que descargue automáticamente los simbolos según los necesite. Para ello, arrancamos el WinDBG, y en el menú File / Symbol File Path pegamos lo siguiente: SRV*dir*http://msdl.microsoft.com/download/symbols Donde dir es la ruta donde se descargarán los símbolos (por ejemplo: c:\simbolos). Asi pues, procedemos a ejecutar la opción File / Open Crash Dump y elegir el fichero MEMORY.DMP, generado por el Windows al recibir un pantallazo, que coloca en %SYSTEMROOT% (usualmente C:\WINDOWS). Estaremos analizando el pantallazo azul si todo ha ido bien: Microsoft (R) Windows Debugger Versión 6.4.0007.2 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\WINDOWS\MEMORY.DMP] [...] Use !analyze -v to get detailed debugging information. Probably caused by : usbehci.sys Followup: MachineOwner En este caso, podemos ver que el causante del error es un usbehci.sys junto a mucha más información que he obviado porque sería ya demasiada, pero que explica detalladamente el error y el motivo por el que ocurre. En el caso que se quiera obtener información más concreta sobre el bsod, convendría investigar un poco más sobre los argumentos, las direcciones de memoria que nos indica el windbg y el uso del !irp. Una cuestión a tener en cuenta, es que en caso de que suframos congelaciones o cuelgues en lugar de pantallazos, existe una forma de generar el dump. Vamos a Inicio / Ejecutar / regedit.exe, a la clave HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ i8042prt \ Parameters, donde crearemos un nuevo valor DWORD con el nombre: CrashOnCtrlScroll y valor: 1. Reiniciamos el equipo para que capte la información que acabamos de introducir, y, en el caso de producirse un cuelgue o congelamiento pulsamos CTRL (derecho) + BLOQ DESPL (2 veces) para provocar la generación del dump.

Más información en: http://www.emezeta.com/articulos/bsod-pantallazos-azules-y-como-identificarlos


Antes de nada aclarar que un BSOD es un pantallazo azul. De sobra son conocidas las famosas pantallas azules de Windows que tan temidas son por el usuario y tan dificiles de interpretar son para el experto, en algunos casos dando auténticos quebraderos de cabeza por no saber identificar la causa del pantallazo. A continuación escribiré una breve guía para identificar la causa de un pantallazo azul. Lo primero que hay que conocer es que en Windows XP los pantallazos azules han sido reemplazados por la acción de reiniciar el equipo sin mostrarlo antes, quizás por la mala prensa que éstos han generado del sistema de Microsoft. Existen dos tipos de pantallazos azules, los que muestran el fichero causante y los que muestran una dirección y un error determinado, como pudiera ser PAGE FAULT IN NON PAGED AREA, IRQ NOT LESS OR EQUAL o KMODE EXCEPTION NOT HANDLED. En el caso de que el pantallazo azul nos muestre el fichero que produce el error, no hay ningún problema, porque ya sabemos quién esta generando el error, pero en el caso de que no muestre ningún fichero, procederemos a analizar el pantallazo azul. Lo primero que debemos hacer es activar la característica para que nos muestre las pantallas de error en lugar de reiniciar. Para ello vamos al Panel de Control / Sistema / Opciones avanzadas / Inicio y recuperación. Nos aparece la siguiente imágen: En ella deberemos desmarcar la opción Reiniciar automáticamente para que nos muestre el pantallazo, y Volcado de memoria del núcleo (en la información de depuración) para poder identificar el pantallazo azul en caso de que no lo consigamos en los primeros pasos. Con un Volcado de memoria pequeño (64kb) no obtendríamos suficiente información para determinarlo. En el caso de tampoco conseguirlo con el volcado del núcleo, haríamos un volcado completo. Considerar que necesitamos en éste caso, tener al menos la capacidad de nuestra memoria RAM de espacio libre en nuestro disco, ya que se va a generar un dump de nuestra memoria. He leído que para que el dump no resulte corrupto, hay que tener establecida la paginación de memoria virtual en la partición donde tengamos instalado el sistema operativo. Asi que, si no es así debemos proceder a ello, en la misma ventana de Opciones avanzadas pero en el primer botón: Rendimiento / Opciones avanzadas / Memoria virtual. Para analizar el dump, vamos a usar el Debugging Tools para 32bits (o para 64bits, AMD64 si posees uno), y aunque podemos descargar los simbolos desde la web, vamos a configurar el programa para que descargue automáticamente los simbolos según los necesite. Para ello, arrancamos el WinDBG, y en el menú File / Symbol File Path pegamos lo siguiente: SRV*dir*http://msdl.microsoft.com/download/symbols Donde dir es la ruta donde se descargarán los símbolos (por ejemplo: c:\simbolos). Asi pues, procedemos a ejecutar la opción File / Open Crash Dump y elegir el fichero MEMORY.DMP, generado por el Windows al recibir un pantallazo, que coloca en %SYSTEMROOT% (usualmente C:\WINDOWS). Estaremos analizando el pantallazo azul si todo ha ido bien: Microsoft (R) Windows Debugger Versión 6.4.0007.2 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\WINDOWS\MEMORY.DMP] [...] Use !analyze -v to get detailed debugging information. Probably caused by : usbehci.sys Followup: MachineOwner En este caso, podemos ver que el causante del error es un usbehci.sys junto a mucha más información que he obviado porque sería ya demasiada, pero que explica detalladamente el error y el motivo por el que ocurre. En el caso que se quiera obtener información más concreta sobre el bsod, convendría investigar un poco más sobre los argumentos, las direcciones de memoria que nos indica el windbg y el uso del !irp. Una cuestión a tener en cuenta, es que en caso de que suframos congelaciones o cuelgues en lugar de pantallazos, existe una forma de generar el dump. Vamos a Inicio / Ejecutar / regedit.exe, a la clave HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ i8042prt \ Parameters, donde crearemos un nuevo valor DWORD con el nombre: CrashOnCtrlScroll y valor: 1. Reiniciamos el equipo para que capte la información que acabamos de introducir, y, en el caso de producirse un cuelgue o congelamiento pulsamos CTRL (derecho) + BLOQ DESPL (2 veces) para provocar la generación del dump.

Más información en: http://www.emezeta.com/articulos/bsod-pantallazos-azules-y-como-identificarlos


Antes de nada aclarar que un BSOD es un pantallazo azul. De sobra son conocidas las famosas pantallas azules de Windows que tan temidas son por el usuario y tan dificiles de interpretar son para el experto, en algunos casos dando auténticos quebraderos de cabeza por no saber identificar la causa del pantallazo. A continuación escribiré una breve guía para identificar la causa de un pantallazo azul. Lo primero que hay que conocer es que en Windows XP los pantallazos azules han sido reemplazados por la acción de reiniciar el equipo sin mostrarlo antes, quizás por la mala prensa que éstos han generado del sistema de Microsoft. Existen dos tipos de pantallazos azules, los que muestran el fichero causante y los que muestran una dirección y un error determinado, como pudiera ser PAGE FAULT IN NON PAGED AREA, IRQ NOT LESS OR EQUAL o KMODE EXCEPTION NOT HANDLED. En el caso de que el pantallazo azul nos muestre el fichero que produce el error, no hay ningún problema, porque ya sabemos quién esta generando el error, pero en el caso de que no muestre ningún fichero, procederemos a analizar el pantallazo azul. Lo primero que debemos hacer es activar la característica para que nos muestre las pantallas de error en lugar de reiniciar. Para ello vamos al Panel de Control / Sistema / Opciones avanzadas / Inicio y recuperación. Nos aparece la siguiente imágen: En ella deberemos desmarcar la opción Reiniciar automáticamente para que nos muestre el pantallazo, y Volcado de memoria del núcleo (en la información de depuración) para poder identificar el pantallazo azul en caso de que no lo consigamos en los primeros pasos. Con un Volcado de memoria pequeño (64kb) no obtendríamos suficiente información para determinarlo. En el caso de tampoco conseguirlo con el volcado del núcleo, haríamos un volcado completo. Considerar que necesitamos en éste caso, tener al menos la capacidad de nuestra memoria RAM de espacio libre en nuestro disco, ya que se va a generar un dump de nuestra memoria. He leído que para que el dump no resulte corrupto, hay que tener establecida la paginación de memoria virtual en la partición donde tengamos instalado el sistema operativo. Asi que, si no es así debemos proceder a ello, en la misma ventana de Opciones avanzadas pero en el primer botón: Rendimiento / Opciones avanzadas / Memoria virtual. Para analizar el dump, vamos a usar el Debugging Tools para 32bits (o para 64bits, AMD64 si posees uno), y aunque podemos descargar los simbolos desde la web, vamos a configurar el programa para que descargue automáticamente los simbolos según los necesite. Para ello, arrancamos el WinDBG, y en el menú File / Symbol File Path pegamos lo siguiente: SRV*dir*http://msdl.microsoft.com/download/symbols Donde dir es la ruta donde se descargarán los símbolos (por ejemplo: c:\simbolos). Asi pues, procedemos a ejecutar la opción File / Open Crash Dump y elegir el fichero MEMORY.DMP, generado por el Windows al recibir un pantallazo, que coloca en %SYSTEMROOT% (usualmente C:\WINDOWS). Estaremos analizando el pantallazo azul si todo ha ido bien: Microsoft (R) Windows Debugger Versión 6.4.0007.2 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\WINDOWS\MEMORY.DMP] [...] Use !analyze -v to get detailed debugging information. Probably caused by : usbehci.sys Followup: MachineOwner En este caso, podemos ver que el causante del error es un usbehci.sys junto a mucha más información que he obviado porque sería ya demasiada, pero que explica detalladamente el error y el motivo por el que ocurre. En el caso que se quiera obtener información más concreta sobre el bsod, convendría investigar un poco más sobre los argumentos, las direcciones de memoria que nos indica el windbg y el uso del !irp. Una cuestión a tener en cuenta, es que en caso de que suframos congelaciones o cuelgues en lugar de pantallazos, existe una forma de generar el dump. Vamos a Inicio / Ejecutar / regedit.exe, a la clave HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ i8042prt \ Parameters, donde crearemos un nuevo valor DWORD con el nombre: CrashOnCtrlScroll y valor: 1. Reiniciamos el equipo para que capte la información que acabamos de introducir, y, en el caso de producirse un cuelgue o congelamiento pulsamos CTRL (derecho) + BLOQ DESPL (2 veces) para provocar la generación del dump.

Más información en: http://www.emezeta.com/articulos/bsod-pantallazos-azules-y-como-identificarlos

No hay comentarios:

Publicar un comentario