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
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
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
Más información en: http://www.emezeta.com/articulos/bsod-pantallazos-azules-y-como-identificarlos
No hay comentarios:
Publicar un comentario