La pantalla blanca al iniciar PES 2019, Process Explorer, Procdump, Windbg y su solución

Desde los tiempos de Winning Eleven, he sido fiel seguidor de Pro Evolution Soccer (PES), primero en la consola de Play Station y luego en el PC hasta el son de hoy. Aunque ya no lo hago todos los días, con regularidad entro en las noches para jugar un rato después de trabajo. Para mi fortuna, casi nunca tengo problemas con la plataforma de Steam, sin importar que estoy instalando todas las compilaciones que salen del programa de Windows Insider; sin embargo, ayer iba a jugar en la noche y me di cuenta de que el juego no estaba entrando, solo aparecía la pantalla blanca y se cerraba:

image

Después de revisar actualizaciones de Windows y hacer un reinicio del equipo, probé yendo a las propiedades del juego en Steam, pestaña de Local Files y utilicé la opción de Verify itegrity of ame files:

SNAGHTML12e95ca

En principio parece que iba a funcionar porque hace reparaciones si encuentra algo raro, pero la pantalla blanca solo se prolongó por unos segundos más antes de cerrarse inesperadamente otra vez. Como no estaba dispuesto a ponerme a descargar otra vez un juego tan pesado sin saber si solucionaría el inconveniente, decidí ponerme a diagnosticar para intentar encontrar la forma de volver a jugar.

Lo primero que hice fue verificar si el juego se estaba cerrando completamente, para eso abrí Process Explorer, fui al menú de Options, luego Difference Highlighting Duration y lo establecí a lo máximo, es decir, 9 segundos, para poder alcanzar a ver cuáles procesos se cerraban mientras cambiaba entre aplicaciones.

Efectivamente, me encontré con que el juego se estaba cerrando abruptamente después de que desaparecía la ventana en blanco:

image

El otro detalle importante es que también se estaba activando el reporte de errores de Windows, WerFault.exe, que me indicaba que estaba sucediendo un crash de la aplicación:

image

¿Qué estaba impidiendo la ejecución del juego? Pues bien, existen muchos motivos por los que una aplicación puede hacer crash al ejecutarse, incluso diferentes soluciones; una de las formas más productivas para encontrar la causa es obtener un volcado de memoria del proceso en el momento del fallo y proceder a analizarlo con un depurador como Windbg. No es una tarea muy sencilla por lo técnico que puede volverse, pero generalmente solo se necesitan algunos conocimientos básicos para dar con la pista del problema.

Procdump, al rescate

Procdump es una herramienta que hace parte de la suite de Sysinternals y que permite generar volcado de memoria según los parámetros que le indiquemos al proceso que debe de monitorear: excepciones, hangs, etc. Para no complicarme tanto organizando los parámetros, en parte porque no soy muy bueno con la herramienta, opté por utilizar el parámetro –i para instalar el controlador de Procdump indicando la ruta donde quería los volcados para que él mismo me escribiera uno cada que hubiese una excepción en Windows. El comando completo es:

procdump.exe –i C:\Dumps

image

La ruta final puede ser cualquiera, yo traté de mantenerlo simple.

Tan pronto intenté jugar nuevamente, la pantalla se puso blanca, la aplicación se cerró y Procdump hizo lo suyo: crear el volcado de memoria que necesitaba.

image

Windbg

Con el volcado de memoria ya creado, procedí a ejecutar Windbg, abrir el .DMP que había generado el Procdump y finalmente corrí el comando de !analyze –v para que hiciera un análisis automático:

image

Normalmente el análisis que hace Windbg se acerca mucho al controlador o módulo que ocasiona la falla, aunque puede llegar a reportar varios que no están dentro de los símbolos:

image

Lo malo de esto es que muchas veces salen falsos positivos porque indica controladores o componentes propios del sistema operativo como desconocidos.

La forma más fácil de identificar el posible causante es mostrar la pila de ejecución que había al momento del crash y empezar desde la función que le indica a Windows que debe detenerse hacia abajo hasta encontrar controladores o módulos de terceros para analizar con más detalles. En mi caso, encontré dos: NvCamera64 y nvwgf2umx.

image

Windbg permite utilizar el comando lmvm para obtener detalles de cada controlador o módulo. Al ejecutarlo con cada uno, me di cuenta de que pertenecían a NVIDIA:

image

Aunque el primero no tenía la descripción, el segundo, nvwgf2umx, indicaba que era del controlador de D3D10.

Imagino yo que no funcionaba alguna actualización de PES 2019 o la última compilación de Windows, así que mi camino fue ir al GeForce Experience y buscar a ver si existía un nuevo controlador; efectivamente, no hace mucho habían liberado otra versión:

image

Después de hacer una instalación limpia desde el asistente y reiniciar Windows, ejecuté nuevamente el juego y, para mi tranquilidad, todo había vuelto a la normalidad:

image

Una vez más, todo salvado gracias a estas maravillosas herramientas y un poco de investigación.

Saludos,

—Checho

La pantalla verde de la muerte (GSOD) al iniciar sesión, Windbg, Windows PE, Autoruns y su solución

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.»

GSOD

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

image

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:

2017-12-21_16-21-53

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:

2017-12-21_16-29-46

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:

2017-12-21_16-32-09

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:

image

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:

image

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

image

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:

image

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,

—Checho
https://twitter.com/secalderonr

Los anuncios que no dejaban navegar en IE, ProcExp, Autoruns y su solución

A pesar de haberme enfrentado a varios problemas en los últimos meses, no había tenido la oportunidad de documentar nuevamente alguno aquí en el blog. Hoy, aprovechando un pequeño Adware al que me enfrenté, quiero exponerles la solución, ya que he empezado a ver comportamientos similares. Como es costumbre, la entrada estará dividida en tres partes: el problema, la causa y su solución.

El problema

Cuando el usuario intentaba abrir cualquier página en internet o simplemente, en los casos que abría la pagina, hacer clic en algún enlace, se ejecutaban diferentes pestañas con propaganda, la mayoría haciendo referencia a una herramienta de reparación de Windows:

image

Como podrán imaginarse, esta era una falsa herramienta. Este comportamiento era además bastante molesto, pues no se podía navegar con tranquilidad.

La causa

Este tipo de Adware solía instalarse como un complemento del navegador para funcionar; por este motivo, utilicé Autoruns para ver todas las extensiones que cargaban con Internet Explorer, pero no encontré nada que pudiese ayudarme.

Si la ejecución de este software malicioso no estaba asociada a un complemento, definitivamente lo tenía que estar con algo ejecutándose en el sistema operativo. Así pues, procedí a ejecutar la herramienta por excelencia, Process Explorer.

Aunque Process Explorer me iba a dar todo el detalle de cada proceso, no iba a ser tan sencillo, puesto que este tipo de aplicaciones maliciosas se disfrazan en procesos confiables. Decidí entonces utilizar la característica de VirusTotal, función útil para enviar el hash de todo lo que se está ejecutando a la base de datos que maneja VirusTotal.com, y esta devuelve un resultado para saber si la entrada en cuestión ha sido ya puesta en lista negra.

Para habilitar el análisis de VirusTotal, fui al menú Options, VirusTotal.com y por último clic en CheckVirusTotal.com.

image

Una vez se habilita el análisis de VirusTotal, Process Explorer crea una columna adicional, VirusTotal, que muestra una comparación entre reportes de malware contra la base de datos que tienen las principales firmas de seguridad. En mi caso, pude detectar inmediatamente dos procesos muy sospechosos, y que tenían una buena cantidad de reportes como maliciosos:

image

Gracias a Process Explorer es posible hacer doble clic sobre el proceso y ver las propiedades para obtener muchos más detalles; por ejemplo, la firma digital, ubicación de instalación, línea de comandos, entre muchos otros.

image

Como pueden ver, el proceso estaba relacionado al programa HQ Video Pro 3.1, que además tenía su propia firma digital a nombre de Digit Network (Exreme White Limited). Debido a que el Autostart Location me indicaba que el Programador de tareas estaba ejecutando el proceso en cada inicio, decidí correr nuevamente Autoruns y ver la pestaña de Sheduled Tasks, y esto es lo que me encontré:

image

No solo se ejecutaban dos procesos, sino ocho relacionados al mismo programa.

La solución

Como había comprobado que HQ Video Pro 3.1 era malicioso y no habían más procesos sospechosos en Process Explorer, el camino más directo era proceder a eliminar HQ Video Pro del sistema operativo; para esto, fui hasta el Panel de control, lo identifiqué y procedí a eliminarlo:

image

Después de un par de clics, el programa se desinstaló correctamente.

image

Naturalmente, había que revisar después de un reinicio si Process Explorer detectaba otra vez la ejecución de este proceso, que Autoruns no tuviese más entradas en el Programador de tareas sospechosas y que no hubiesen quedado archivos relacionados a esta aplicación en Archivos de programa. Para mi fortuna, todo eso estuvo muy bien y el problema desapareció.

Saludos.

—Checho