Lo que te quieren contar los pantallazos azules

Lo cierto es que no son muy comunicativos que se diga. Pero dadas las circunstancias en las que se producen me recuerdan un poco a Johnny, expresándose el pobre a través de único método a su alcance con la esperanza de dar con la enfermera regular de día que sepa entenderle.

Hay un montón de explicaciones de lo que es un pantallazo azul (bluescreen, bug check, BSOD...). Pero la mejor que yo haya visto jamás es ésta (el vídeo original lo he encontrado aquí):

Bueno, al grano.

Un pantallazo azul no es más que un problema grave que sucede en modo kernel. Los sistemas operativos de uso común suelen tener kernels monolíticos, lo que significa que todos componentes básicos del SO y los drivers de los dispositivos comparten el mismo espacio de memoria. Los procesos del usuario y los servicios del sistema, por el contrario, tienen cada uno su propio espacio de memoria virtual, lo que implica que un fallo a este nivel produzca un indeseable cierre de la aplicación, un "cuelgue" o fallos similares, que si bien pueden hacer que el sistema quede en estado inutilizable, no son del todo catastróficos. Este tipo de problemas cuando suceden en modo kernel tienen inmediatamente un efecto fatal en el sistema, que es incapaz de continuar funcionando y produce la temida pantalla azul.

Lo que sucede a continuación depende de cómo este configurado el sistema. Pero la idea es salvar a disco todo o parte del contenido de la memoria a un fichero, el famoso memory.dmp.

• Volcado de memoria completo: Habida cuenta de que tengamos espacio suficiente en la partición de arranque para albergar el fichero de paginación, y que este sea de mayor o igual tamaño que la memoria física del sistema.
• Volcado de memoria del Kernel: Solo se vuelca el espacio de memoria del kernel. Su tamaño es variable, dependiendo de lo que estuviera en ese momento haciendo el sistema. El fichero se almacena por defecto en %Systemroot%
• Volcado pequeño de memoria: Solo almacena la información mínima indispensable, el tipo de Bug Check, parametros lista de drivers cargados, etc. Tienen un tamaño fijo y se almacenan en la carpeta %SystemRoot%\Minidump

Está mucho mejor explicado aquí:

• https://support.microsoft.com/kb/254649/en-us
• https://support.microsoft.com/kb/889654/en-us

Para un pantallazo azul, nos bastará en la mayoría de las ocasiones con un volcado del kernel. Para saber qué es lo que produjo el error y tratar de que éste no vuelva a suceder, tendremos que utilizar nuestro entorno de depuración de Windows para analizarlo.

Este es el análisis de algunos pantallazos que han dado los portátiles que solemos utilizar. Los vamos guardando para "hacer guantes" con ellos. Vamos a utilizar la opción "Open Crash Dump" de WinDBG.

Análisis básico de un Kernel Dump:

Pues esto fue un Stop 0x0000007E. Y de un golpe de vista vemos que probablemente lo ha causado iastor.sys, y que no tenemos los símbolos de este módulo. Esto último indica que o bien no tenemos bien configurado el Symbols Path, o que este modulo no pertenece a Windows. Además se nos recomienda ejecutar la extensión "!analyze -v" que nos dará más información (-v suele significar "verbose"=parlanchín). No hace falta ni teclear, el inequívoco azul subrayado nos invita simplemente a hacer clic:

Humm, error code 0xc0000005 = violación de acceso. Parece que iastore.sys se ha metido en un jardín que no era suyo. Si queremos saber algo más sobre el presunto culpable le volvemos a dar al enlace, que nos ejecutará por debajo "lmvm iastor":

Todo apunta a que el culpable de la situación fue en este caso el driver iastore.sys, que corresponde al "Intel Matrix Storage Manager driver", necesario para poder usar el disco SATA de manera nativa el el portátil.

Análisis de un par de Minidumps:

Este parece ser causado por lfsfilt.sys. Es de la pila NDAS de XIMETA, un buen invento que permite montar por red un dispositivo multimedia de manera parecida a como lo harías por iSCSI, y que viene soportado en este cacharrito que Chema me regaló para regocijo de mis cachorrillos. Cuando dió el pantallazo estaba, efectivamente, defragmentando la unidad.

Este se atribuye a csrss.exe (client/server run-time). Este es un subsistema básico de Windows y cuando casca el kernel produce un bugcheck. Mirando en detalle con !analyze -v vemos que lo que parece que realmente sucedió es que mis intentos por encontrar una aplicación compatible con x64 para ver la tele en el portátil con la capturadora USB tuvo efectos no deseados.

Tres pantallazos, tres veces que no fue culpa de Windows. ¿La solución?. En mi caso no he hecho nada, pero los suyo es probar con una actualizaciones del driver en particular, o referirnos al fabricante para continuar con el análisis.

¿Te parezco muy listo?. Pruébalo tu y verás que no es para tanto. ¡Y haznos saber aquí que sacaste en claro!

NOTA: este post NO ES para que toda la comunidad de habla hispana exponga aquí su problemática particular. La gente de soporte de Microsoft se gana la vida haciendo estas cosas a diario. Ellos son los que saben.

Saludos

David Cervigón

Comments

• Anonymous
  January 01, 2003
  Hola Pablo Gracias por compartir tu experiencia aqui. En Windows Internals, Russinovich afirma que el 70% de los pantallazos azules se producen por drivers. Yo creo que la evolución de las plataformas x64 minimizará esto aun más. Sobre lo que dices, eso sería la caña. El problema es que en ese momento tienes poco margen de maniobra para analizar nada Windows Error Reporting hace hoy por hoy un pequeño análisis. Estoy por apostar que en el futuro seremos capaces de automatizar este tipo de análisis Saludos

• Anonymous
  January 01, 2003
  El hecho de que una máquina sea virtual no implica que un gran número de las operaciones que

• Anonymous
  May 29, 2008
  donde yo trabajo ya hemos analizado decenas de crash dumps de servidores windows 2000 y windows 2003 y hasta ahora nunca he encontrado un problema que fuera de windows. Siempre son drivers de las tarjetas de fibra, drivers de almacenamiento, etc... Sin embargo creo que sería mucho mas interesante que esa información se mostrase en el pantallazo azul y ese report que muestras en esta página se generase automaticamente en un TXT para agilizar la depuracion del problema.

• Anonymous
  May 30, 2008
  The comment has been removed

• Anonymous
  June 04, 2008
  Dios, que pareja haría el aparatito que referencias aquí y mi Home Server. aaaaaaarg  ( http://mp3simpsons.com.ar/wp-content/uploads/2007/08/dona_homero.gif )

• Anonymous
  June 10, 2008
  Hola David, efectivamente el sistema en ese momento tiene poca capacidad de maniobra pero esa tarea podría realizarla cuando el equipo se levantese de nuevo y en la ventana que aparece despues de hacer login, en un servidor que ha sufrido un pantallazo azul, en vez de poner que el equipo se ha apagado inesperadamente con la descripción stop error 0x092734 pues mostrara un resumen del crash como el que saca el windbg. Estoy seguro que eso callaría muchas vocas de gente que no tiene ni idea y que afirma que la culpa es de windows.