Aunque he tenido algunos problemas resueltos en mi día a día laboral, no había vuelto a sacar tiempo para compartirlos; sin embargo, recién pude recuperar mi propio equipo de uno interesante, así que decidí sentarme un rato y escribirlo como en viejos tiempos.
El problema
Recién había actualizado mi Windows 10 a la compilación 17063 y necesitaba reinstalar el VMWare Workstation por un problema que hay con Advanced Installer, herramienta indispensable en mi trabajo, así que procedí a hacerlo, pero cuando reinicié el equipo para terminar la desinstalación, justo después de iniciar sesión, mi equipo empezó a arrojar pantalla verde de la muerte (GSOD):
«Your Windows Insider Build ran into a problem and needs to restart. We’re just collecting some error info, and then we’ll restart for you.»
Nota: el color verde es solo para las compilaciones del programa Windows Insider.
A pesar de que el reinicio del equipo era correcto, incluso el inicio de sesión parecía funcionar, siempre terminaba por obtener el GSOD y se reiniciaba otra vez.
La causa
¿Cómo solucionar el problema cuando no puedes ingresar a Windows? Para pensar en eso, tenía que encontrar primero qué controlador me estaba causando la pantalla verde.
Recordemos que cuando ocurren una pantalla azul/verde de la muerte, mientras nos muestra el aterrador mensaje, Windows escribe un archivo que contiene el volcado de memoria de lo que ocurría al momento del fallo; normalmente escribe uno completo, MEMORY.dmp, ubicado en la raíz del directorio de Windows y otro más pequeño, escrito en el directorio Minidumps.
Si logramos obtener alguno de estos archivos desde el equipo con el fallo, es muy probable que podamos identificar la causa raíz.
Windows PE
Como no podía extraer el volcado de memoria desde el equipo en línea, opté por recurrir al buen amigo Windows PE e iniciar desde ahí el equipo, de esta forma me aseguraba no sufrir más reinicios inesperados y poder navegar desde la consola libremente por mis archivos.
Una vez en el Windows PE, busqué en qué unidad se encontraban los archivos del sistema operativo sin conexión, en mi caso la E:\, y copié el archivo MEMORY.dmp para poder analizarlo en otro equipo con xcopy a mi memoria USB, con letra H:\, así:
xcopy E:\Windows\MEMORY.dmp H:\DumpFile
El siguiente paso fue ejecutar la última versión del Windbg en otro equipo, conectar la memoria con el volcado de memoria y abrirlo para el análisis:
El Windbg tarda unos segundos mientras prepara el ambiente y luego deja a disposición la consola de comandos. El paso básico aquí es proceder con el !analyze –v para que nos dé un resultado de cuál puede ser el controlador que falla y bastante información más, pero en este caso decidí utilizar solamente el comando kc para ver los nombres de todos los módulos y funciones que cargaron antes de que se produjera el bugcheck. Afortunádamente me encontré con algo interesante:
Aquí cabe recordar que debemos buscar de primero siempre lo que no corresponda a Windows, es decir, que no inicie con nt! Para mi caso, como pueden ver, solo había algo diferente a todo lo demás: gdrv.
Luego, desde el mismo Windbg, utilicé lmvm gdrv para ver qué información podía extraer de ese controlador, aunque no tuve demasiada:
Hasta aquí pude confirmar que efectivamente había un controlador implicado, pero con estos detalles del Windbg no podía saber a qué programa pertenecía (o no sabía cómo). ¿Qué hacer, entonces?
Autoruns y Windows PE
Como lo he mostrado en varias ocasiones durante toda la vida de este blog, Autoruns, de Sysinternals, tiene una fantástica característica que consiste en cargar todo lo que hay en un sistema operativo sin conexión para hacer análisis desde un Windows PE, por ejemplo. De esta forma podemos saber todo lo que carga con Windows y buscar posibles causas de problemas como una pantalla azul/verde que no deja arrancar.
Lo que hice fue copiar el Autoruns64.exe desde la página de Sysinternals al Windows PE, inicié nuevamente mi equipo desde ahí, ejecuté Autoruns y activé la característica desde el menú de File, Analyze Offline System.
En la ventana de Offline System solo debemos indicar el directorio en donde está Windows, en mi caso la E:\Windows, y el perfil a cargar, en mi caso E:\Users\Checho:
Una vez hecho eso, ya estaba viendo todo lo que cargaba en mi sistema operativo. ¡Todo listo para encontrar a quién le pertenecía el controlador!
Desde el cuadro de texto de Filter, ubicado en la parte superior, debajo de la barra de menú, escribí el nombre del controlador, gdrv, y para mi fortuna, encontré lo que buscaba:
Según la descripción, el controlador pertenecía a GIGABYTE Tools, es decir, a la aplicación de App Center del fabricante.
La solución
Naturalmente, si Windows no tiene activo en el inicio el controlador que falla, el problema no va a ocurrir. Desde Autoruns, deshabilité la carga de ese controlador quitando la selección, así:
Cerré Autoruns, Windows PE y reinicié mi máquina. Como era de esperarse, no tuve más la pantalla verde, aunque sí un mensaje de error del App Center por no poder cargar su controlador:
Intenté buscar una versión más actualizada del App Center, pero no la encontré en la página de Gigabyte, así que tuve que quitar la aplicación de mi equipo mientras logro reportar el problema o sale alguna versión nueva.
Saludos,