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í:
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