El controlador de Process Monitor que causaba un remitente Pantallazo Azul; Windows PE, Autoruns y su solución.

Hola a todos,

Quizá este caso les pueda parecer un poco extraño por el posible causante, pero es una excelente oportunidad de ver que cuando hasta en el más fatal de los casos siempre quedará “algo” por hacer.

*Nota: El contenido que verán a continuación es exactamente igual al que puse en mi Blog: Checho’s Blog, por aquello de los títulos =)

Como he venido escribiendo en los anteriores artículos que guardan similitud con este, lo dividiré en “El Problema”, “La posible causa” y “La solución”. El objetivo es como siempre, poder compartir todo lo que más pueda hasta donde mi conocimiento me lo permita y claro está, dejar abierto el espacio para que compartan sus comentarios al respecto si así lo desean.

El problema

Desde hace unos días estaba escribiendo un artículo del que estoy muy agradecido porque por fin, tenía la oportunidad de ver una característica muy interesante del fantástico Process Monitor llamada Boot Logging.

Básicamente, consiste en activar el monitoreo de Process Monitor para que en el próximo reinicio de Windows, su controlador se active como uno de Arranque de inicio, lo que le permite correr como uno de los primeros en la secuencia de inicio, mucho antes que la mayoría de los demás controladores. Al poder hacer esto, Process Monitor podrá monitorear toda la primera actividad, incluyendo lo que se carga adicionalmente mientras Winlogon hace su tarea y podrá estar disponible la próxima vez que se ejecute Process Monitor.

Este log es muy útil porque podríamos llegar a diagnosticar y reparar problemas que no se podrían detectar fácilmente mientras Windows ya está en ejecución.

Para activar esta funcionalidad, basta con abrir Process Monitor, ir al menú Options y habilitar “Enable Boot Logging”:

Al hacer esto, basta con cerrar Process Monitor y reiniciar el sistema para que funcione. El problema en mi caso es que después de activarlo y reiniciar el sistema me encontré con este grata sorpresa:

*Nota: El proceso lo estuve realizando en una máquina virtual, lo que me permitió tener todas las capturas de una forma clara.

Como ven, lo que obtuve fue el famoso Pantallazo Azul o Blue Screen Of Death (BSOD) como se le conoce. En la mayoría de las ocasiones, el equipo presenta muy esporádicamente este comportamiento y por lo general al segundo reinicio Windows entra normalmente.

Lamentablemente para mí, esto no pasó y sin importar de qué forma intentara iniciar (Modo seguro, Modo de consola, Mido de depuración, sin funciones de red), siempre volvía a dar el pantallazo azul justo después de la animación inicial.

Un Pantallazo Azul como tal, realmente es un mecanimos de protección que nos indica que por lo general, se están produciendo operaciones a nivel de kernel no permitidas como que un controlador está intentando acceder a un espacio de memoria privado. Este tipo de inconvenientes por controladores causan casi un 90% o más de los Pantallazos Azules, otro pequeño porcentaje se da por fallos de Hardware como energía o cuando algun componente está dañado.

Windows entonces, para proteger su propia integridad detiene todas las operaciones, dibuja el BSOD con un formato estándar (Operación, información, código, etc) y posteriormente colecta los datos para general el Volcado de memoria (Dump File) que guarda en el próximo reinicio en el directorio de Windows con el nombre MEMORY.DMP, además de otros Minidumps que guarda en la carpeta con el mismo nombre y que son útiles para un análisis muy general puesto que el volcado de memoria completo puede llegar a ser muy pesado ya que almacena todo lo que había en RAM hasta el momento del Pantallazo Azul.

La posible causa

Así como Windows se protege así mismo con el Pantallazo Azul, también tiene una serie de herramientas embebidas para hacer diagnóstico y reparación sobre todo para casos en que el sistema operativo no inicia normalmente.

Para esto basta con presionar varias veces F8 al prender el equipo para que en las opciones avanzadas podamos entrar en la Reparación de equipo. En estos casos, como Windows es lo suficientemente inteligente, después de un reinicio forzado presenta la opción de reparación sin que presionemos alguna tecla:

Al iniciar Reparación de equipo, normalmente Windows busca problemas en los archivos de arranque de Windows, si los encuentra y está en la posibilidad de repararlos lo hace, si no encuentra sin embargo y existe un punto de restauración lo presenta para que volvamos a ese estado de imagen donde el equipo estaba funcionando correctamente:

*Nota: El entorno de Reparación de equipo está basado en un Windows PE.

Como estaba sobre un entorno virtual y no era mi prioridad reparar el problema, decidí restaurar el sistema para poder continuar escribiendo el contenido que había dejado pendiente. En efecto, Windows se restauró y estaba operacional nuevamente, así que realicé otras operaciones para el artículo y como ví que reiniciaba correctamente de nuevo pensé en activar la función de Boot Logging puesto que aún no lo había podido ver en acción y lo requería.

Confiado entonces, lo habilité reinicié mi equipo pero para mi gran sorpresa, nuevamente obtuve el mismo Pantallazo Azul, y otra vez recurrente, así que no podía iniciar Windows normalmente.

¿A qué se debía?

Definitivamente, la característica que estaba activando en Process Monitor tenía algo que ver con que al próximo reinicio de Windows siempre volviera a ocurrir el Pantallazo Azul.

Me costaba creer que la mejor herramienta que existe en mi concepto para hacer Windows Troubleshooting y que tanto me ha ayudado, esta vez estuviera en la lista negra.

A pesar de todo me inclinaba más porque fuera otro controlador pero, me acordé que cuando se activa el Boot Logging, el controlador de Process Monitor pasa a ser uno de los primeros en iniciar en el orden de arranque de Windows (Como lo describí anteriormente). En este orden de ideas, si era uno de los primeros en iniciar (Tal vez el primero) con más seguridad sí sería culpable.

Para comprobarlo debía entonces lograr desactivar ese controlador pero, con Windows impidiéndome reiniciar y la reparación de inicio sin darme muchas alternativas ya que ni el Volcado de memoria (MEMORY.DMP) se estaba creando sólo quedaba una posible forma.

Paradógicamente, para reparar el problema que estaba generando una herramienta de Sysinternals, requería otra de las que componen la suite; me estoy refiriendo por supuesto a Autoruns.

La solución

Autoruns, entre sus tantas estupendas funcionalidades provee una única que consiste en realizar un análisis de lo que está iniciando con Windows aun cuando el equipo se encuentra apagado u offline. A esta característica se le llama “Analyze Offline System” y se activa desde el menú File de Autoruns.

Para esto, debo garantizar que Autoruns tenga acceso al equipo afectado y que está Offline y como no puedo entrar a Windows requiero recurrir al mismo método que utiliza Windows para reparar el equipo y es a un Windows PE (Entorno de Preinstalación).

Como el que está en el medio de Windows y de forma embebida con su instalación puesto que no tiene ninguna herramienta de Sysinternals, Autoruns en este caso, debía proceder a crear mi propio Windows PE y asegurarme de que la herramienta estuviera disponible una vez hecha la imagen.

Esta gran ventaja me la da el Kit de Instalación Automatizada para Windows 7 (WAIK); específicamente el Deployment Tools Command Prompt que es desde donde puedo copiar los archivos necesarios para el Windows PE.

Como el Windows PE es un mini sistema operativo que carga en memoria RAM, tiene la ventaja de que sigue siendo un sistema operativo y cuenta con varias funciones como las de red, además de poder interactuar con varias aplicaciones que soporten esta ejecución. Así, podría ejecutar Autoruns desde el Windows PE corriéndolo en el Equipo afectado y podría hacer uso de su característica de análisis sin conexión para desactivar el controlador de Process Monitor y ver si en verdad había ocasionado todo.

Construyendo el medio Windows PE + Autoruns

Como dije antes, para construir el Windows PE necesitamos tener WAIK instalado, ya he mostrado cómo es todo el procedimiento en otros artículos pero lo repetiré aquí por el valor agregado de que no usaremos esto para despliegue sino para solución de problemas.

*Nota: Si no tienen WAIK, lo pueden descargar desde Aquí.

Debemos instalar el WAIK en un equipo, ir a Inicio, Todos los programas, Microsoft Windows AIK, clic derecho sobre Deployment Tools Command Prompt y seleccionar “Ejecutar como administrador”

En la consola ejecutamos: Copype.cmd x86 <DirectorioPE>

Donde <DirectorioPE> es una ruta local o de red donde queremos guardar los archivos del Windows PE. Para mi caso, no me compliqué mucho y lo creé en el directorio C:\ con el nombre WinPE, el comando quedaría entonces así: Copype.cmd x86 C:\WinPE

*Nota: Sin importar que sea para reparar un problema utilizando Autoruns en un sistema de 32 o 64 bits, se debe crear el Windows PE de 32 bits.

Dentro de la carpeta que se crea (En este artículo por ejemplo WinPE) veremos dos carpetas (ISO y Mount) y dos archivos (etfsboot.com y winpe.wim). En la carpeta ISO es donde debemos guardar todo lo que deseamos que tenga el Windows PE ya que es desde la que generaremos la imagen .ISO.

En entornos de implementación, normalmente copiabamos la herramienta de ImageX.exe desde los archivos del WAIK a la carpeta ISO, en este caso lo que haremos será copiar Autoruns.exe, por supuesto, previamente lo debemos descargar desde la página oficial.

La carpeta ISO debería verse así:

Una vez copiamos el ejecutable de Autoruns (Autoruns.exe) volvemos a abrir el Deployment Tools Command Prompt y esta vez haremos la copia del winpe.wim a la carpeta \Sources renombrandolo a boot.wim para que el Windows PE pueda arrancar correctamente cuando se cargue.

Para esto, ejecutamos:
copy <DirectorioPE>\winpe.wim <DirectorioPE>\ISO\Sources\boot.wim

Para este artículo, sería:
copy C:\WinPE\winpe.wim C:\WinPE\ISO\Sources\boot.wim

*Nota: Desde el Explorador también podemos hacer la copia, además de esto podemos verificar que la carpeta Sources sí tenga el archivo boot.wim.

Ejecutamos por última vez el Deployment Tools Command Prompt y ya que tenemos los archivos necesarios para hacer Troubleshooting (Solución de problemas) podemos crear la imagen .ISO del Windows PE con el siguiente comando:

oscdimg –b<DirectorioPE>\etfsboot.com –u2 –h <DirectorioPE>\ISO <DirectorioISO>\WinPE.iso

Donde <DirectorioISO> es también una ubicación donde deseemos guardar la imagen .ISO del Windows PE.

Para mi caso, el comando sería:

oscdimg –bC:\WinPE\etfsboot.com –u2 –h C:\WinPE\ISO C:\WinPE.iso

¡Listo! Con esto ya podemos analizar cualquier sistema offline con sólo arrancar desde el Windows PE, obviamente debemos grabarlo sea en una USB o bien en un medio CD/DVD.

Esto fue lo que yo hice, posteriormente inicié el equipo en el que tenía el Pantallazo Azul que no dejaba arrancar correctamente.

Volviendo al caso…

Una vez entró al Windows PE, lo primero que hice fue identificar cuál era la unidad que le había asignado ya que es la que contiene todos los archivos del medio. Normalmente, X: es la unidad temporal del Windows PE, C:\ la del sistema operativo y si no hay más dispositivos, la unidad D:\ será la del Windows PE.

*Nota: Si hay más dispositivos que requieran tener letras de unidad, se debe seguir buscando en orden alfabetico para hallar la del Windows PE o bien utilizar la línea de comandos de Diskpart para identificar los volúmenes que estén disponibles.

Para verificar el contenido, basta con ejecutar Dir una vez estemos en la unidad:

En mi caso, procedí a ejecutar Autoruns.exe desde la raiz de mi Windows PE, al abrir me dirigí al menú File y seleccioné “Analyze Offline System” para poder tener control de lo que estaba arrancando con Windows:

En la ventana de Offline System siempre se debe especificar el directorio donde está instalado Windows (Normalmente C:\Windows) y el directorio del usuario a analizar. Para este caso, como ocurría para todos (Ya que era antes de iniciar sesión inclusive), le indiqué el directorio donde están todos los usuarios, es decir: C:\ProgramData

Después presioné F5 para que actualizara los resultados que estaba arrojando Autoruns y me fui directamente a la pestaña de Drivers para poder ver todos los controladores que estaban iniciando con Windows.

En caso de que estemos realizando este proceso y no sepamos por qué controlador empezar, lo más normal es desactivar primero los controladores que no hacen parte de Microsoft, para hacerlo basta con quitar la selección sobre el controlador específico y cerrar Autoruns, el trabajo de él será hacer los cambios pertinentes para que Windows no tome el controlador en el próximo reinicio.

Lo que yo hice, sabiendo que algo tendría que ver Process Monitor (Más específicamente su controlador) fue utilizar la función de búsqueda (CTRL + F) e indicarle el nombre del proceso interno “procmon”:

Como pensé, el controlador estaba iniciando con Windows (Por haber activado el Boot Logging claro está):

Lo que hice fue quitarle la selección para arriesgarme a realizar la prueba otra vez iniciando Windows:

Cerré Autoruns, cerré la ventana de Consola de comandos para que Windows reiniciara automáticamente, esta vez no entré al Windows PE sino que dejé iniciar Windows normalmente y ¡Oh sorpresa!

Ahora no hubo ningun pantallazo azul, Windows entonces inició normalmente y sin ningún tipo de problema:

Quizá en este caso tuve mucha suerte puesto que pude identificar rápidamente un posible causante y de ahí tener una base, pero en estos casos suele ser muy útil deshabilitar todo lo que no sea de Microsoft al inicio (Aunque este en parte lo era) e ir probando el arranque. A menos de que sea problema de máquina, podríamos llegar a tener esta suerte en la mayoría de las ocasiones cuando ni Windows deja iniciar.

He aquí otra gran ventaja de Windows PE y de Windows Sysinternals, espero que les pueda ser de utilidad a algunos.

Estaré actualizando el post en caso de que obtenga más información sobre lo que me sucedió con Process Monitor.

Saludos,

Sergio Calderón (Checho)