Checho's Blog : Process Monitor, Windows Sysinternals, Solución a problemas

El mensaje de Log file de VMware al iniciar Visual Studio 2012 en Windows 8, Process Monitor y su solución

Checho — Sat, 11 May 2013 21:17:00 GMT

Como siempre he dicho en anteriores artículos relacionados, escribir sobre alguna solución de un problema en Windows, es de lo que más me gusta hacer aquí, pues afrontar algo así, es la mayor fuente de conocimiento que uno puede tener.

Uno de los tipos de problemas más frecuentes con respecto a aplicaciones en Windows, suelen ser los misteriosos mensajes de error, que en algunas veces dicen mucho, pero otras veces, puede ser una excepción no controlada, y por ende, el mensaje no dirá nada. Gran parte de estos errores se pueden subsanar, pues muchos son causados por operaciones incorrectas que hace la aplicación sobre la actual versión del sistema operativo, o bien como en este caso específico, hay problemas de permisos.

Para fortuna de nosotros, Microsoft tiene una cantidad de herramientas y soluciones gratuitas que nos ayudarán a dar una luz a nuestro problema; entre las que más destaco, están: Sysinternals Suite y Application Compatibility Toolkit, incluida en el ADK de Windows 8. Lo más interesante, es que aunque lo ideal siempre es el conocimiento, no es extricatmente necesario tener un grado muy alto para que estas herramientas nos puedan ayudar.

El problema

Regularmente al instalar Windows, vario entre VMware Workstation y Hyper-V, pero también instalo siempre Visual Studio, que hoy por hoy está en versión 2012. VMware tiene unos componentes adicionales para Visual Studio que se pueden agregar mientras se instala la plataforma.

Lo extraño de todo esto, es que después de instalar Visual Studio y VMware con sus respectivos componentes, cada que intentaba abrir la plataforma de desarrollo, estaba recibiendo este mensaje de error:

“An error has ocurred while trying to access the log file. Logging may not function properly.”

Cuando hacía clic en el botón OK (Aceptar), Visual Studio seguía su camino sin ningún problema, pero se empezaba a volver bastante molesto tener que aceptar el mensaje cada vez que se ejecutara la suite de desarrollo.

La causa

Claramente, el complemento de VMware para Visual Studio no podía leer o escribir el archivo de log, lo que no era posible saber, era cuál archivo específico se estaba refiriendo y en qué ruta se encontraba. Para estos casos, donde hay un mensaje de error sin mucho detalle, la mejor herramienta que podemos utilizar es Process Monitor de Sysinternals.

Como Process Monitor detecta todo evento que está sucediendo en el sistema, es normal que no sepamos en estos casos por dónde empezar con millones de resultados en la traza. Para este problema, utilicé una de las características de Process Monitor que permite filtrar por categoría y resultado. Para esto, basta con ir al menú de Tools y seleccionar Count Ocurrences:

Despues de esto, Seleccionar Result dentro del menú desplegable para asegurarnos que son los resultados los que se nos mostrarán y después darle al botón de Count.

Los resultados que yo tuve, se veían así:

Una de las principales causales para este tipo de errores, suelen ser los inconvenientes con permisos NTFS en el sistema operativo, así que el resultado de ACCESS DENIED es bastante útil. Lo que yo hice, fue darle doble clic para que Process Monitor inmediatamente hiciera el filtro por todos los resultados en los que haya recibido como respuesta ACCESS DENIED.

Aunque hubo varios resultados, uno en específico fue el que me llamó la atención:

Como pueden ver en la captura, el nombre del proceso era devenv.exe, perteneciente a Visual Studio, lo que me decía que ocurría este evento mientras estaba en ejecución; lo otro, es que según Path, era un .log el que se estaba tratando de crear (Utilizando la operación de CreateFile), dentro de una carpeta temporal del usuario, pero más interesante aún, es que pertenecía a VMware. El nombre en cuestión era: vmware-vsid-1.log. Para estar más seguro, desde Process Monitor, hice clic derecho a la ruta y seleccioné Jumpt to, que permite navegar hasta el directorio automáticamente, y esto fue lo que vi:

El archivo sí estaba creado dentro del directorio, lo que indicaba que el problema quizá no estaba en su primera creación, sino más bien en la sobreescritura que hacía al iniciar Visual Studio. Para asegurarme de esto, hice clic derecho en el archivo, fui a Propiedades y finalmente a la pestaña de Seguridad para ver cómo estaban los permisos, y esto me encontré:

Windows me indicaba que no tenía permisos de lectura. Si mi usuario (Checho) no podía siquiera leer el contenido, no iba a poder hacer ningún tipo de escritura u operación básica sobre el archivo.

La solución

Ya sabiendo el problema, podía intentar dos cosas, darle los permisos al archivo para que el proceso de Visual Studio pudiera escribir en él, o como era un log, simplemente eliminarlo y esperar a ver qué sucedía al momento de crearse.

Opté por la segunda y lo quité, para posteriormente ejecutar Visual Studio y para mi fortuna, ¡No más mensaje molesto de error!

Al volver a resisar los permisos, todo había cambiado:

Uno más, gracias a Process Monitor.

Saludos,

Checho

La “Cuenta fantasma” que quería iniciar sesión, Process Monitor y su solución.

Checho — Fri, 03 Feb 2012 12:20:00 GMT

El problema

Normalmente, suelo tener algunas máquinas virtuales en las que me apoyo para los diferentes artículos que escribo aquí, o bien para las pruebas que requiera hacer, sea reproduciendo problemas, o tratando de entender comportamientos de Windows.

Las máquinas virtuales las administro desde VMware, y una de las características de éste gran Gestor, es que si se instala Windows utilizando el asistente, sea con los pasos básicos o avanzados, al darle el usuario que sea quiere crear, además de que no lo pregunta en la instalación (Lo hace de forma desatendida), es que Windows siempre hará autologon con el usuario.

*Nota: Pueden ver más a fondo los procesos de Autologon en Este artículo.

Lamentablemente, en una de las máquinas, tuve que eliminar una de las cuentas porque la dañé completamente; no tuve problema con este proceso, el problema empezó al empezar a reiniciar normalmente el equipo, ya que cada que entraba, obtenía un mensaje de error con respecto a una contraseña:

Al darle al botón Ok, mi sorpresa fue que Windows todavía estaba intentando ingresar con el usuario que yo había borrado (WinBoy):

Por supuesto, no podía iniciar de ninguna forma sesión con el usuario, por lo que siempre tenía que darle al botón de Cambiar de usuario, escribir manualmente alguno de los otros usuarios e iniciar sesión.

Lo primero que hice fue ir hasta la ventana de Administración de usuarios, pero la cuenta (Tal como debía ser), no aparecía por ningún lado:

Los archivos de usuario, a pesar de que yo pensé haberlos borrado también, seguían existiendo en el directorio de C:\Users, pero esta no debería ser razón para que iniciara, puesto que la cuenta no estaba creada.

¿Cuál era el problema entonces?

La causa

El problema estaba sucediendo antes de que se iniciara Windows, por lo menos el escritorio; sólo existe una herramienta capaz de darme un diagnóstico de lo que sucede antes, por supuesto, me refiero a Process Monitor de Sysinternals.

Process Monitor tiene una característica llamada “Enable Boot Logging” que, permite ubicar el controlador de Process Monitor (PROCMON20.SYS) para que inicie antes que todo, por lo que generará un log que irá incrementandose hasta que se abra nuevamente dentro de Windows y se guarde.

Gracias a esto, podemos ver las Operaciones que suceden incluso desde el Winlogon, cosa que no es posible ni con el mismo sistema operativo.

Para habilitar la característica, basta con Abrir Process Monitor, e ir al menú Options y seleccionar “Enable Boot Logging”:

Lo habilité, abrí Process Monitor para empezar a analizar el log, y empecé a buscar por la palabra clave que pudiera darme más ayuda, en este caso, por supuesto, el nombre de usuario: “WinBoy”.

Después de algunos resultados que me decían que las claves del usuario en ProfileList todavía existían, encontré esto:

*Nota: Clic en la imagen para verla en tamaño real.

Windows estaba abriendo la clave Winlogon que contiene todas las claves y subclaves que hacen referencia a alguna operación en el proceso de inicio de sesión; a continuación estaba haciendo unas consultas a unos valores llamados DefaultUserName, DefaultDomainName y DefaultPassword. En el artículo acerca del Autologon, vimos un poco de lo que trataban estos valores, pero básicamente, junto con AutoAdminLogon, habilitan el Inicio automático (Autologon) y además establecen el nombre de usuario, dominio y contraseña que debe utilizarse.

DefaultUserName, en este caso estaba todavía haciendo referencia a la cuenta que estaba eliminada:

*Nota: “Data” es el contenido que tendrá, en este caso “WinBoy”.

Esta era la primera respuesta del por qué intentaba iniciar con una cuenta que ya no existía, al estarla referenciando, y todavía existir sus claves correspondientes, Windows aún la referenciaba.

DefaultDomanName no tenía valor, por lo que estaba tomando el Grupo de Trabajo predeterminado que tenía Windows.

Ahora, el valor de DefaultPassword, a diferencia de los anteriores, tenía como resultado NAME NOT FOUND, esto quiere decir que, a pesar de tener el Autologon indicado, Windows no encontraba la contraseña por ninguna parte; esto nos da la respuesta del por qué el primer mensaje de que el nombre de usuario o contraseña eran incorrectos.

La solución

Ya tenía detectado el problema, la solución consistía en evitar que Windows suigiera intentando hacer el Autologon, para esto entonces, desde Process Monitor utilicé la característica de “Jump to” para ir directamente a la clave de Registro de Winlogon y ubicar los valores que estaban causando el problema:

Lo que hice fue primero, modificar el contenido de AutoAdminLogon para cambiarlo de “1” a “0” y que se desactivara, y posteriormente eliminé el valor de DefaultUserName para que no tuviera nada que buscar ahí =)

Al reiniciar el equipo, el agradable resultado fue:

El inicio de sesión común en Windows había retornado a su normalidad.

¡Problema solucionado!

Saludos,

Checho

La Subclave de Registro que no quería eliminarse, el pequeño bug de PowerShell, Process Monitor y su solución

Checho — Thu, 02 Feb 2012 13:41:00 GMT

Hola a todos,

Este no iba a ser el artículo que iba a poner de primero, pero resultó y es para mí, de lo más interesante porque personalmente, aprendí y eso le da un buen sentido.

El problema

Estoy tratando de conocer y comprender, hasta donde sea capaz mi conocimiento, un poco más a fondo el funcionamiento de la Asociación de archivos en Windows (En esta semana pondré el artículo completo refiriendome al tema).

Una de las formas más sencillas de aprender sobre Windows, es dañando y tratando de arreglar, por lo que modifiqué para reproducir el problema común de la perdida de asociación a los accesos directos, lo que causa que todo se abra con un solo programa:

A continuación, estaba tratando de utilizar PowerShell, para hacer uso de un cmdlet para eliminar la subclave de registro que causa este problema, es decir:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.lnk\UserChoice

Como PowerShell trabaja las claves de registro de la misma forma que lo hace con los archivos, bastaba con hacer referencia a una pequeña línea de comandos utilizando Remove-Item, así:

Remove-Item –Path HCKU:\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.lnk\UserChoice

El problema, es que cada que ejecutaba la línea anterior, recibía un mensaje un poco extraño de PowerShell:

Según el mensaje que PowerShell me daba, Remove-Item no podía eliminar la subclave de Registro porque no existía, aunque efectivamente la clave estaba:

Aunque PowerShell estaba reconociendo la excepción, no necesariamente estaba entregando el mensaje que correspondía, ¿Cuál era el problema entonces si la clave existía?

La causa

Como PowerShell no era capaz de indicar qué era lo que realmente le pasaba, había que pasar a preguntarle directamente a Windows, y para hacer esto, como siempre, nada mejor que Process Monitor de Windows Sysinternals.

Después de correr Process Monitor e intentar ejecutar la línea de comandos, bastó con volver a Procmon, parar el monitoreo y buscar directamente por la subclave UserChoice, como se recomienda, de abajo hacia arriba; esto fue lo que encontré:

*Nota: Clic para ver la imagen en tamaño completo.

El proceso powershell.exe estaba tratando de abrir la clave de UserChoice, pero como ven, el resultado era ACCESS DENIED, lo que llevaba a la respuesta, el problema estaba en permisos, ¡No en ausencia de la clave!

Process Monitor permite saltar directamente a la clave, así que lo hice, y después de esto entré a la ventana de Permisos de la clave haciendo clic derecho, Permisos, y en primera instancia, todo estaba bien para los usuarios de los grupos Administradores; el único y más importante problema, es que el usuario con el que había iniciado sesión, y con el que estaba tratando de eliminar la clave, tenía un permiso especial que me estaba denegando algo:

*Nota: Los Permisos Especiales en Windows contienen un filtro mucho más completo de denegación o aprobación en las operaciones que se pueden hacer a nivel de sistema de archivos, o bien sobre claves y valores del Registro de Windows.

Para poder ver los permisos especiales, basta con hacer clic en el botón inferior de Avanzado (No visto en la captura anterior), detecté el usuario que tenía los permisos especiales denegados e hice clic en el botón Editar para verlos:

Mi usuario tenía en blanco todo lo que fuera permitir, eso quiere decir que los tomaría de los permisos predeterminados, pero tenía como Denegado el permiso a establecer valores (Set Value), lo que equivale a escribir:

La solución

Con el problema detectado, ya la solución sería un poco más sencilla, al saber que tenía problemas de permisos, específicante de escritura, PowerShell no iba a ser capaz de eliminar la clave (No podía escribir nada encima); así que para no modificar mucho los permisos, símplemente cambié el de Denegar para Establecer Valor (Set Value) a Permitir (Allow):

Finalmente, volví a ejecutar la línea de comandos en PowerShell y este fue el resultado:

¡Todo blanco! Lo que indica que se había ejecutado correctamente, y además la clave se elimino en efecto sin ningun problema:

El pequeño Bug sobre los mensajes de información en las excepciones de PowerShell ya llegó al Equipo de PowerShell para mejorarlo en futuras actualizaciones.

Saludos,

Checho

La aplicación “BlenderPortable.exe” que no quería instalar en Windows 7, Process Monitor y su solución.

Checho — Thu, 26 Jan 2012 10:45:00 GMT

Ya lo he dicho en otras ocasiones (Artículos), pero no me canso de repetirlo, los Foros de Microsoft TechNet y Microsoft Answers, son el mejor lugar tanto para compartir conocimiento, aprender e interactuar con nuevos problemas al mismo tiempo que se trata de ayudar a otras personas en situaciones complicadas.

Hoy quiero compartirles un inconveniente que tuve al tratar de instalar una aplicación llamada BlenderPortable en un Equipo Windows 7, justo co la intención de investigar otro comportamiento.

El Problema

Cada que trataba de instalar la aplicación Blender Portable, al ejecutarlo haciendo doble clic, justo después de indiciar la ruta de instalación, estaba recibiendo un mismo mensaje de error:

El error indicaba que tenía problemas para escribir en la ruta de instalación, es decir en C:\Program Files\BlenderPortable\

Si le daba reintentar, ocurría el mismo mensaje de error, si le daba Ignorar, me entregaba de nuevo lo mismo pero con otro archivo diferente, por lo que el problema no era del archivo a copiar en cuestión, sino de cualquier archivo que estaba tratando de escribir en el directorio.

La causa

Como he dicho en otros problemas, suele ser una buena práctica ejecutar de nuevo las aplicaciones que presentan estos errores con privilegios elevados, es decir, haciendo clic derecho sobre el ejecutable, y seleccionando “Ejecutar como administrador”.

Como se esperaba, la aplicación pasó a instalarse normalmente, esto indicaba que el problema iba por algun tema probablemente de permisos.

Para asegurarme específicamente dónde, procedí a ejecutar Process Monitor de Sysinternals, seguir el comportamiento de Windows mientras intentaba instalar la aplicación y este fue el resltado al ver el log después:

En principio, cuando Windows hacía uso de la API con la función CreateFile para generar el directorio de C:\Program Files\BlenderPortable y empezar a escribir, no estaba encontrando la ruta, como muestra el resultado de PATH NOT FOUND.

A continuación, Windows consulta los eventos que tiene registrados, y hace el llamado del mensaje de error, junto con el típico sonido, que incluso lo consulta en C:\Windows\Media\Windows Critical Stop.wav.

Predeterminadamente, Windows debería estar en la capacidad de crear el directorio, siendo primera vez que lo consulta, la pregunta era: ¿Por qué no lo estaba creando?

Buscando un poco más a fondo en el Log, este fue el resultado:

Cuando el proceso BlenderPortable.exe estaba tratando de crear el directorio C:\Program Files\BlenderPortable estaba obteniendo un ACCESS DENIED (Acceso Denegado), ¿Qué significaba? ¡No tenía permisos!

El Control de Cuentas de Usuario (UAC) en Windows 7, entre otras cosas, es capar cuando una aplicación está intentando escribir en directorios protegidos del sistema, y mediante un engaño, les hace creer que tienen permisos de escritura y que la aplicación no tenga ningun problema.

Como muy amablemente me hizo caer en cuenta Mark Russinovich sobre este problema, seguramente la característica llamada Deteccción Heurística (Que detecte que es un instalador), no estaba funcionando con esta aplicación en cuestión.

La solución

Por seguridad, no es prudente entonces permitirle a la aplicación que escriba a su antojo en el directorio, sin embargo, la solución consisitió en crear manualmente la carpeta BlenderPortable en el directorio C:\Program Files, a continuación entrar a las Propiedades de dicha carpeta, pestaña de Seguridad, botón Editar y darle a los usuarios estándar permisos de escritura sobre la carpeta:

Después de esto, procedí a ejecutar la aplicación nuevamente con doble clic, y para mi fortuna, ¡Caso solucionado! La aplicación instaló correctamente.

Espero que si tienen algun problema similar, se animen a intentar segurilo, se darán cuenta de que es sumamente grato y productivo lo que se puede aprender al lograr solucionarlo.

Saludos,

Checho

El icono de la función “Crear carpeta” en el menú contextual que no se encontraba, Process Monitor y su solución

Checho — Thu, 05 Jan 2012 17:35:00 GMT

De nuevo estamos por aquí, esta vez quiero compartirles un pequeño problema que tuve hace poco en un equipo con Windows 7 que, aunque no interfería en el funcionamiento normal, no podía dejar pasarlo.

El problema

Una de las tareas que uno más realiza en Windows, es utilizar el menú contextual que se despliega al hacer clic derecho con el mouse, el comportamiento de éste depende de donde estemos, es decir, una página web, una aplicación, etc.

Normalmente en Windows, se pueden realizar una serie de tareas predeterminadas y básicas que nos dan acceso rápido a características o a funciones.

En este caso, estaba tratando de crear una simple carpeta haciendo clic derecho en un espacio vacío, seleccionando Nuevo, y Carpeta.

No tenía problema para crear la carpeta, sin embargo siempre que trataba de escoger la opción, el icono de la función de “Carpeta” no era el que Windows trae de forma predeterminada:

Como ven, el icono era el de una hoja en blanco con unos pequeños signos encima, y no el de la carpeta en miniatura.

La causa

Comparar este con otro tipo de problemas que seguramente ustedes han visto, o que he escrito aquí, no sería la gran cosa, sin embargo, ¿Por qué aceptarlo si no debería funcionar así?

Cuando se pierden los iconos que identifican una aplicación o función, indica que hay un problema con su asociación, aunque en este caso tenía que investigar cuál era. Para esto, como siempre, corrí Process Monitor de Sysinternals y a continuación reproducí el comportamiento, es decir, crear una carpeta cualquiera.

Lo siguiente era llenarme de paciencia y empezar a buscar en la traza que arroja Process Monitor e intentar identificar qué era lo que causaba que Windows no encontrar el problema.

En principio busqué por “folder”, pero eran demasiados resultados y no pude acomodarme fácilmente, así que decidí empezar a buscar por “new” en separado, hasta que después de unos minutos, di con la clave que podría ayudarme a entender un poco más el inconveniente:

Windows estaba intentando hacer una consulta a la clave HKEY_CLASSES_ROOT\Folder\ShellNew\IconPath con un resultado de SUCCESS.

La razón por la que era importante esto a pesar de que diera exitoso el resultado, es que en HKEY_CLASSES_ROOT se alojan todas las asociaciones que administra el sistema operativo, aunque en HKEY_CURRENT_USER guarda gran parte por usuario.

Aquí además se estaba refiriendo específicamente a la de “Folder” por lo que estaba en la asociación correcta.

El valor IconPath referencia a la ruta interna dentro de Shell32.dll donde Windows puede extraer el icono necesario, pero al dar resultado exitoso descarté de que estuviera faltante o algo similar.

Lo que me llamó la atención, son las dos operaciones un poco ilógicas que intentaba hacer Windows después de hacer el Query al anterior valor, ambas utilizaban la función de CreateFile, la primera para intentar crear un directorio con nombre “Windowssystem32shell32.dll” y la segunda para intentar crear el archivo Shell32.dll dentro de la carpeta de C:\Windows. Ambos sin embargo, tenían un resultado de NAME NOT FOUND.

A primera vista, si se divide con el signo de Backslash (\) los directorios que intentaba crear Windows, existen realmente, es decir C:\Windows\System32\Shell32.dll, pero ¿Por qué sin los signos?

Decidí entonces seguir el comportamiento en un equipo que tuviera el icono de la carpeta asociado correctamente, y este fue el resultado en la misma clave y valor:

También tiene SUCCESS, pero esta vez, inmediatamente hace la consulta en el valor de IconPath, utiliza la función de RegCloseKey para terminar la operación en la clave HKEY_CLASSES_ROOT\Folder\ShellNew.

¿Por qué en el sistema funcional no intentaba crear también estos directorios?

La respuesta la tenía Process Monitor por supuesto, desde la misma herramienta en la columna siguiente a Result “Detail”, se puede ver todos los detalles de la operación que se está haciendo, pero se puede ir mucho más a fondo si se hace clic derecho sobre la operación y se selecciona Properties, o bien con hacer doble clic que abre la misma ventana.

Casi todas las operaciones a nivel de Sistema de archivos o de Registro, manejan algun contenido, cuando son consultas por supuesto, tiene que hacer referencia al contenido que consultó, esto lo muestra en un campo llamado “Data”.

Para mi sorpresa, esto fue lo que vi y que me dio la respuesta al abrir las propiedades tanto de la operación en el sistema funcional, como en el que no mostraba el icono correctamente:

Sistema funcional:

Sistema NO funcional:

“Data”, era la misma ruta en ambos, pero como ven, en el primero hacía referencia correctamente a la ruta, es decir a %SystemRoot%\System32\Shell32.dll,3, en cambio abajo trataba de buscar en el mismo directorio pero sin que estuviera separado por el backslash correctamente: %SystemRoot%system32shell32.dll,3

Si Windows no puede encontrar el directorio que está buscando, presentará los iconos (Si es de asociación) genéricos cuando no puede determinar el que le corresponde.

La solución

Sambiendo esto, desde Process Monitor utilicé la característica de “Jump to” para ir directamente a la clave de Registro implicada:

Hice doble clic en el valor IconPath y corregí correctamente la ruta de forma manual haciendo doble clic sobre ésta, es decir, de %SystemRoot%system32shell32.dll,3 a %SystemRoot%\system32\shell32.dll,3

Cerré el Registro y después de unos segundos, hice nuevamente clic derecho para abrir el menú contextual, el item de Nuevo y para mi fortuna, ¡Mi icono estaba de vuelta!

Lo importante, a mi forma de ver, el solucionar un problema que aparentemente no es muy dañino, no sólo permitirá garantizar el nivel funcional como debe ser, sino lo más importante, siempre podremos aprender mucho del gran mundo de Windows con los detalles más mínimos y tal vez insignificantes.

Claro esta, con una herramienta igual de increible que Windows como lo es Process Monitor.

Saludos,

Checho

La aplicación “DLTCAD 2010” que no corría en Windows 7, Process Monitor y su solución.

Checho — Thu, 17 Nov 2011 14:31:00 GMT

Hola a todos,

Realmente me da alegría volver a escribir por aquí después de algunos días, especialmente cuando tengo algo que me haya ayudado a mi aprendizaje y que quiero compartir.

En este caso, como en muchas ocasiones, se trata de un problema reportado con una aplicación llamada DLTCAD 2010 desde los estupendos Foros de Microsoft Answers en Español, me tomé el trabajo entonces de descargar un trial de la aplicación en cuestión y probar yo mismo, afortunádamente, también me dio un error y pude solucionarlo.

A continuación, como siempre divido en: El problema, La causa y su Solución.

El problema

Cuando se instala la aplicación en Windows 7, después de tratar de ejecutarla por primera vez, estaba recibiendo un Crash de la aplicación, es decir, que dejaba de responder sin ni siquiera haber iniciado:

“dlt2010D.exe dejó de funcionar”

Al intentar cerrar la aplicación, inmediátamente recibía un mensaje de error bastante extraño:

Estaba ocurriendo una Excepción y, según el mensaje, no se podía encontrar el archivo Config.tmp en la ruta de instalación: “C:\Program Files (x86)\DLTCAD2010 DEMO\”

Al aceptar el mensaje (OK), la aplicación no terminaba de iniciar. Sin importar cuántas veces la tratar de ejecutar, siempre era el mismo procedimiento, crash y posterior mensaje de error para finalmente cerrar el proceso y no abrir nada.

La causa

Lo primero que intenté hacer fue buscar el archivo Config.tmp pero por supuesto, no apareció por ningún lado, a juzgar por su extensión y nombre además, parecer ser algún tipo de archivo temporal que se ejecuta antes de iniciar la aplicación y que tal vez, pueda contener la configuración o los parámetros iniciales necesarios para que la aplicación arranque correctamente.

*Nota: Claro está, sólo estoy suponiendo porque la verdadera respuesta, la tiene sólo el fabricante implicado en el desarrollo.

En la compatibilidad de aplicaciones con Windows 7, suele ser práctico como primera instancia, intentar con dos alternativas, pestaña de compatibilidad que hará una “Mentira sobre la versión” haciéndole creer a la aplicación que está en una versión anterior de Windows o bien Ejecutarla como administrador elevando los permisos por el cambio en materia de seguridad que sufrió Windows desde XP a Windows 7 ya que todos los usuarios en Vista y 7 trabajan predeterminádamente como usuarios estándar.

Sin embargo, aplicando el modo de compatibilidad con Windows XP Service Pack 3 o inferior, de una vez el ejecutable pasa a pedir elevación de privilegios para que se cambie el token de acceso y sí se esté ejecutando realmente como un administrador (Tal cual se hacía en Windows XP).

Esto fue lo que hice con el ejecutable, fui a las propiedades (clic derecho, propiedades), pestaña de Compatibilidad y seleccioné Ejecutar este programa en modo de compatibilidad para Windows XP (Service Pack 3):

A continuación, ejecuté el programa, elevé los privilegios y de sorpresa, la aplicación estaba corriendo perfectamente:

Aquí había una gran incógnita, realmente la aplicación sí era compatible con Windows 7, pero pudo haberla hecho funcionar o la mentira sobre versión o la elevación de privilegios.

En un escenario emergente, ésta solución podría bastar, pero no en todas las empresas están dispuestas a dejar que se eleven permisos aunque sea para un proceso porque entonces tendrían que garantizar una cuenta que lo haga, además de que si la aplicación originalmente no pide elevación de privilegios es porque parece estar hecha con el fin de funcionar bajo un token estándar.

Cambié nuevamente el modo de compatibilidad a como estaba presentando el problema, y llamé a la mejor herramienta que me podía ayudar en ese momento, me refiero a Process Monitor de Sysinternals.

El proceso es el mismo de siempre, ejecutarlo, limpiar el primer log que genera, ponerlo a correr nuevamente y ejeacutar la aplicación hasta recibir el mensaje de error.

El siguiente paso es buscar qué puede darnos Process Monitor, de nuevo, como siempre, la recomendación es hacerlo de abajo hacia arriba y utilizando primero palabras que estén relacionadas con el problema, para este caso por supuesto, la primera sería: Config.tmp

Para activar el filtro de búsqueda, basta con ir al menú Edit y seleccionar Find, ejecutarlo desde la barra de comandos de Procmon o bien presionar CTRL + F

Para mi fortuna, bastó con los primeros y únicos resultados para encontrar tal vez la clave del problema:

Si vamos más a fondo, Windows está utilizando la función CreateFile para tratar de crear el archivo Config.tmp en la ruta: C:\Program Files (x86)\DLTCAD2010 DEMO\, pero como resultado está obteniendo un ACCESS DENIED; esto significa que la ruta existe, que se intenta hacer la operación pero que no se consiguen los permisos necesarios sobre la ubicación en este caso para escribir y que el archivo quede.

Lo interesante está en que en Windows XP, la aplicación funciona perfectamente, y si hago lo mismo con Process Monitor, veré que el trabajo con el archivo Config.tmp se comporta diferente:

Como ven, es exactamente la misma operación, pero esta vez con un resultado de SUCCESS, lo que difiere de que tuvo los permisos necesarios para escribir.

Esto es apenas lógico y es donde está la raíz del problema, los permisos NTFS cambian completamente junto con todo el esquema de seguridad como había comentado antes, la aplicación en Windows XP, tiene todos los privilegios para escribir sobre cualquier ruta porque la cuenta predeterminada es de Administrador. En Windows 7 por otro lado, aunque la cuenta esté dentro del grupo de administradores en modo de aprobación, desde que esté el Control de Cuentas de Usuario (UAC) activo, todo lo que se corra se hará bajo el mismo token que el Explorer.exe (Proceso padre), es decir, como si se estuviera corriendo sobre un usuario limitado.

Al yo elevar los permisos en la ejecución dentro de Windows 7, le está diciendo al proceso que cambie de token de usuario estándar a usuario administrador, por lo que los permisos pasarán hacer idénticos a como si se estuviera ejecutando en Windows XP, por eso sigue sin problemas.

La solución

Como el problema estaba en los permisos, es decir, acceso denegado para escribir en la carpeta DLTCAD2010 DEMO, tenía que revisar cómo estaban establecidos de forma predeterminada para el usuario actual, para esto, basta con ir al directorio implicado, hacer clic derecho, Propiedades, ir a la pestaña de Seguridad y hacer clic en el botón Editar:

En la edición de Seguridad sobre los permisos NTFS en Vista y en 7, se puede ver cada usuario implicado en los directorios o unidades que hayamos seleccionado, así como cada permiso que tienen sobre los objetos.

En este caso, me situé sobre mi usuario WinGuy del grupo Users (Usuarios) y esto fue lo que me mostró Windows:

Como ven, el permiso de Escritura (Write) no estaba seleccionado para Permitir (Allow), lo que quiere decir que mis usuarios estándar, no pueden crear nada en este directorio (DLTCAD2010 DEMO).

Hay una diferencia notable con respecto a los Administradores de la máquina:

Todos los permisos están habilitados, incluyendo los de escribir, ¡Aquí la clave de todo!
Esto resolvía el por qué elevando los privilegios que pasa de estar entre los Usuarios a los Administradores, la aplicación estaba funcionando bien.

Para finalizar entonces, sólo tuve que asignar el permiso de escritura sobre mi usuario y aplicar todos los cambios con sólo seleccionar el grupo de Users (Usuarios) y después habilitar Write (Escritura):

Por último y para confirmar la teoría, ejecuté la aplicación sin elevar los privilegios (Haciendo doble clic sobre el acceso directo) y .. ¡Aplicación funcionando!

Como hemos visto, no todos los problemas son culpa de Windows =)
Espero pueda ser de utilidad, sea por como en mi caso, aprender algo nuevo o bien porque tengan un problema similar con esta aplicación como es el caso que se planteó en los Foros y de donde surgió todo esto.

Saludos,

Checho

El mensaje “…Inició sesión con un perfil temporal…” al intentar ingresar en Windows 7, Process Monitor y su solución.

Checho — Mon, 10 Oct 2011 12:11:00 GMT

¡Hola!

Me alegra mucho estar de nuevo por acá, y espero traerles en estas próximas semanas un par de artículos de detalles que he podido aprender en los últimos meses y que tal vez les pueda ser de utilidad.

No empiezo con eso porque afortunádamente, mientras preparaba uno de esos artículos me encontré con un problema que mucho había visto pero que no me había tocado enfrentar.

No sobra decirlo, como siempre nos iremos por diferentes fases, El problema, La causa y La solución, el que desee puede pasar a lo último para que compare e intente solucionar el problema si es que es el mismo comportamiento. Esta vez no hay Fix para descargar porque aunque puede ser la misma solución varían varios aspectos que se darán cuenta en el artículo.

El problema

Pues bien, el adelanto es que estaba haciendo una serie de pruebas sobre diferentes escenarios que tiene la Redirección de carpetas de usuario pero en una de todas, reinicié el equipo y al intentar ingresar a la cuenta, el inicio era como si fuera primera vez que estuviera entrando, por lo que tardó más y recibí el siguiente mensaje:

“You have been logged on with a temporary profile.
You cannot access your files and files created in this profile will be deleted when you log off. To fix this, log off and try logging on later.
Please see the event log for details or contact your system administrator.”

“No se cargó correctamente su perfil de usuario. Inició sesión con un perfil temporal.
Los cambios que se efectúen en este perfil se perderán cuando se cierre la sesión. Consulte el registro de eventos para obtener información detallada o póngase en contacto con el administrador.”

El funcionamiento de Windows en general se comportaba bien, excepto porque aunque tenía el mismo nombre de mi perfil no era mi perfil y por más que volviera a reiniciar siempre me creaba uno temporal.

Lo extraño era que el perfil de Administrador integrado estaba iniciando bien por lo que el problema se estaba causando sólo en este perfil en particular.

La causa

*Nota: Este problema está documentado en una KB de Microsoft para Windows Vista que debería ser muy similar en Windows 7: http://support.microsoft.com/kb/947242/es

Lamentablemente, la solución propuesta no me sirvió, por tanto tenía que encontrar alguna por mi cuenta si quería recuperar mi perfil.

Sólo existe una herramienta lo suficientemente estupenda para que me hubiera podido ayudar, por supuesto estoy hablando de Process Monitor de Sysinternals.

No había nada que pudiera encontrar en Windows puesto que una vez iniciado ya el problema estaba ocurriendo, pero como cada vez se creaba una cuenta nueva, pensé que podría encontrar pistas si analizaba qué estaba ocurriendo en el inicio de sesión, ¡Process Monitor sabe qué hacer!

Hace un tiempo en el problema de los Remitentes pantallazos azules con el controlador de Procmon comenté que Process Monitor tiene una funcionalidad para habilitar Boot Logging que, básicamente carga un controlador en el inicio de Windows antes que casi todos por lo que me permite monitorear lo que sucede antes de que se inicie una sesión, basta con ir al menú Options, seleccionar Enable Boot Logging:

Procedí, reinicié el sistema y al ingresar nuevamente me encontré con el mismo mensaje, sin embargo ejecuté Process Monitor y efectivamente ya tenía toda la traza generada al ingresar, era el turno de empezar a buscar.

Considero una buena práctica utilizar la función de búsqueda en Process Monitor (En varias de las herramientas de Sysinternals en realidad) y tratar de encontrar resultados con palabras clave referentes al problema, en esta ocasión mi búsqueda fue por : profile

*Nota: Como dije en otro artículo, recomiendo en estas búsquedas utilizar los nombres en inglés porque internamente Windows siempre los referenciará así cuando existen.

Después de pasar algunos eventos que no se relacionaban mucho, encontré la clave de todo:

*Nota: Hacer clic en la imagen para verla en tamaño completo.

Como verán, hay varias operaciones que se están realizando, todas con resultados exitosos (SUCCESS), pero detengámonos a analizar un poco:

La primera operación que referencio está abriendo en la clave de Registro ProfileList una subclave que hace referencia a un SID (Identificador único) en:
HKLM\Software\Microsoft\Windows NT\CurrentVersion

La clave completa es:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-817817061-500146855-1629396408-1003

*Nota: Recordemos que HKLM hace referencia a HKEY_LOCAL_MACHINE.

Un SID se reconoce por una serie de números que tienen un comienzo muy similar (En este caso S-1-5-21-), existe SID por usuario y por máquina, en este caso, estaba referenciando a un usuario, el problema es que no sabía a quién todavía.

*Nota: El SID varía por usuario y por máquina por lo que si tienen el mismo problema verán otro número diferente en caso de que decidan analizarlo igual.

Para saber si esto tenía algo que ver con lo que buscaba, aproveché a Process Monitor así que hice clic derecho sobre la clave que se estaba abriendo y seleccioné Jump To (Para ir directamente a la ubicación en el Registro de Windows).

En el Registro me encontré con dos cosas sumamente interesantes, por el lado del Arbol de registro esto fue lo que vi:

La primera subclave que tengo encerrada (S-1-5-21-817817061-500146855-1629396408-1003) era la que me hizo referencia Process Monitor y su contenido era el siguiente:

Efectivamente los valores estaban relacionados con un perfil de usuario, el valor específico de ProfileImagePath que además está referenciado en la captura de Process Monitor y al cual hace consultas (RegQueryValue) está indicando la ruta de un perfil Temporal:

C:\Users\TEMP.WIN-07Q5QALI9TH.008

Lo que no entendía es que este no era mi usuario, aquí estaba utilizando su nombre real pero en Windows yo seguía apareciendo con mi nombre de usuario (Demo).

Me devolví hasta el arbol de Registro y para mi sorpresa detallé que la otra subclave que está subrayada en la captura que mostré más arriba tenía exactamente el mismo SID que la anterior (S-1-5-21-817817061-500146855-1629396408-1003), con excepción de que éste terminaba en .bak que hace referencia normalmente a Backup.

Esta fue mi sorpresa cuando decidí ver su contenido:

Como verán, también hace referencia a un perfil de usuario, pero esta vez el contenido del valor ProfileImagePath sí hace referencia a mi usuario (E:\Users\Demo), además difiere del anterior en que está tratando de buscarlo en otra unidad (E:\), aquí pensé en la Redirección de carpetas que estaba trabajando (Ya tocaremos el tema en específico en otro artículo).

Obviamente no quería renunciar a la redirección de carpetas y perfiles puesto que ya había especificado que quería escribir en E:\, sin embargo no entendía:

¿Por qué dos cuentas con el mismo SID?

¿Porqué está iniciando con el temporal y no con el real?

Para tratar de responder esto volví al Process Monitor para ver un poco más las tareas posteriores y si detallamos la primera captura, hay algo que me llamó la atención y que hace justo después de terminar estas tareas en el Registro:

Había una operación exitosa a nivel de sistema de archivos (Se reconoce por el icono de la lupa sobre la carpeta amarilla) que estaba creando, consultando y cerrando justo en la carpeta del perfil que hace poco había detallado en el Registro y que estaba como primario: C:\Users\TEMP.WIN07Q5QAL19TH.005

Me pareció extraño sin embargo que la terminación fuera diferente, así que fui a la carpeta de Perfiles de usuario desde el Process Monitor y encontré que había una carpeta de perfil temporal por cada usuario que se estaba creando al reiniciar Windows:

Ahí estaba mi carpeta anterior sin embargo de “Demo” pero haciendo referencia a su primera ubicación original (C:\Users\Demo), como yo había cambiado de unidad busqué en Process Monitor para ver si también se estaba creando la nueva carpeta en la unidad E: pero:

Mi carpeta no se estaba creando cuando cargaba Windows.

Me devolví al Registro de Windows gracias a que vi que en la traza de Process Monitor había dicho que la referencia a estas carpetas estaba en la clave ProfileList, ésta contiene toda la redirección de perfiles de usuario, incluyendo la de ProgramData que se refiere a ubicación general para todos los perfiles:

Hasta aquí se podía entender que no se creaba la carpeta del nuevo perfil “Demo” en la unidad E:\ que era la que trataba de buscar pero sí se creaba un perfil temporal, la ubicación era en C:\Users\ porque el valor ProfilesDirectory de la clave ProfileList especifica %SystemDrive%\Users.

*Nota: %SystemDrive% es una variable de entorno que hace referencia a la unidad donde está instalada Windows, en la mayoría de los casos en C:\

A parte de esto, puedo asegurar que Windows es suprémamente inteligente porque es autosuficiente para valerse de cuentas temporales y poder ingresar al sistema, aunque obvio se borraba todo el contenido al volver a reiniciar.

No me iba a dar por rendido sin embargo, así que pensé que si yo creaba la carpeta explícitamente en la unidad E:\ de nombre Users\Demo, Windows debía encontrarla y así podría iniciar con el perfil nuevamente.

Para mi mala fortuna, aunque la creé, esto no fue así y Windows seguía creando perfiles temporales.

Me acordé que que la carpeta del perfil con todo el contenido normal sí seguía en la ubicación original y predeterminada de C:\Users, así que pensé que si era porque no encontraba su ubicación, volviendo a poner la unidad en el valor ProfileImagePath en vez de E: a C: se debía reparar el problema:

Reinicié el sistema y ¡Oh sorpresa! Ya no había más perfil temporal, y funcionaba.

Me alegró esto porque ya sabía que era a la carpeta específica que se había creado originalmente la que se debíe referencia para que el perfil cargara pero no entendía qué tenía esa carpeta que no se volviera a referenciar en la otra unidad si después de todo los Documentos, Imágenes, Música y demás son para almacenamiento.

Aquí es donde me detuve y pensando un poco me acordé de algo suprémamente importante, cuando se crea un perfil no sólo se le establecen estas ubicaciones sino que además sele asigna una plantilla que tiene toda la configuración a nivel de usuario, es decir a NTUSER.DAT, además de otros archivos que pemanecen ocultos y que no se podían crear tan fácilmente, esto dio luz a mi solución.

La esperada Solución

No me iba a quedar con las ganas de que la ubicación de perfil se referenciara a la unidad E:\ que era donde la requería para las pruebas que estaba realizando.

Estos son los pasos de cómo conseguí entonces solucionarlo a la medida:

1. Navegué hasta la clave que referenciaba mi perfil de usuario debajo de la clave ProfileList:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-817817061-500146855-1629396408-1003

*Nota: El SID pueden saberlo viendo algun proceso con Process Monitor en la pestaña Seguridad, aunque también pueden ir hasta la ubicación HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\

Allí buscar entre todos los SID cuál corresponde a su usuario.

2. Hice doble clic en el valor ProfileImagePath y cambié la ruta de C:\Users\Demo a la que originalmente quería: E:\Users\Demo

3. Como sabía que dejándolo así iba a tener otra vez el famoso problema de los perfiles temporales, había que darle a Windows lo que estaba buscando (La verdadera carpeta “Demo” que tenía todos los archivos referentes a mi perfil como NTUSER.DAT propio) así que inicié sesión con otro usuario que tuviera privilegios, fui hasta C:\Users copié la carpeta “Demo” desde el Explorador de Windows hasta la carpeta “Demo” de mi ubicación en E:\

Básicamente, para remplazar todo el contenido vacío de Demo en la unidad E:\ por el originario del perfil de usuario.

El resultado final de mi carpeta en E:\ sería similar a este:

4. Reinicié el equipo, inicié sesión con el usuario Demo y ahora felizmente cargaba el perfil como siempre lo había hecho y además estaba ahora apuntando a donde yo había querido desde el principio.

¡Problema solucionado!

*Nota: La verdadera solución realmente es asegurarse de que el valor ProfileImagePath esté apuntando a donde se creó la carpeta de Perfil originalmente, el valor de ProfilesDirectory en la clave ProfileList puede asegurar con certeza dónde se están guardando los perfiles de usuario, una vez identificada la ruta de la carpeta del perfil se debe hacer referencia completa a ella y así Windows dispondrá de todo lo que requiere para cargar y mostrar el perfil.

Mover estas carpetas de Perfiles de usuario no es una muy buena práctica completa, siempre es mejor dejarlos en C:\Users\ y así también estar seguros de que estos valores apuntan a su respectivo perfil para que este tipo de problemas no suceda.

Si este problema les llega a pasar a nivel de Dominio y tienen redirección de carpetas o de Perfiles de algun modo con gran seguridad siempre Windows estará buscando una carpeta de perfil donde no existe así que se deben asegurar de que sepa dónde está.

Como vieron además, vuelvo a decir que Windows es demasiado inteligente porque él mismo al saber dónde tenía el perfil verdadero borró y hizo uso del perfil temporal más.

Espero les pueda ser de utilidad y pueda haber podido lo poco que pude aprender de esto.

Saludos,

Checho

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

Checho — Wed, 31 Aug 2011 08:25:00 GMT

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.

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,

Checho

El archivo (.pps) de Office 2007 y 2010 que no mostraba campos dentro de las Propiedades en Windows 7, Process Monitor y su solución.

Checho — Thu, 07 Jul 2011 12:28:00 GMT

Hola a todos,

Hace unos días, en los espectaculares Foros de Microsoft TechNet, específicamente en el Foro de Windows 7 , un usuario abrió un hilo con un aparente problema que resultó siendo (Por lo menos para mí) un caso sumamente interesante a pesar de que no representaba un fallo en el funcionamiento de Windows como suele suceder normalmente pero que, como con casi todos entrega una gran cantidad de conocimiento al intentar resolverlo.

A continuación, quiero compartirles como siempre en varios items (El problema, la causa y la posible solución) todo este caso con el fin de ver qué tanto nos puede ayudar Sysinternals cuando todo lo demás parece haberse agotado.

El problema

El inconveniente se presenta cuando trabajamos con Office 2007 u Office 2010, específicamente cuando guardamos una presentación de PowerPoint en formato .pps (Para Office 97 y 2003). Cuando queremos acceder a las Propiedades del archivo, pestaña Detalles veremos que no se puede agregar o editar campos adicionales como el Título y el Asunto entre otros, sólo nos permite visualizar unas propiedades estándar del mismo:

¿Cuál es el problema? Que si este mismo archivo se guarda con el formato predeterminado para Office 2007 y 2010 (.ppsx) podremos ver todos los campos que especifican los detalles del archivo en cuestión y además se podrán editar:

Esto solo pasa (Y estaba pasando) con este tipo de extensión (.pps) que es la que maneja predeterminadamente PowerPoint 2003 pero que utilizan las versiones superiores para mantener esta misma compatibilidad con versiones inferiores.

Sin embargo, no pasa lo mismo con las demás extensiones que maneja PowerPoint. Esto por supuesto para muchas personas les puede parecer algo a lo que no haya que prestar mucha atención porque quizás ni lo utilicen pero para el usuario en cuestión y para una gran cantidad de personas que hacen uso de estas características puede llegar a convertirse en algo muy importante porque no hay razón (Aparente por lo menos) para que no siga comportándose igual.

La causa

En este tipo de casos, cuando no es un error que uno pueda investigar pero que tiene un punto de comparación, resulta mejor tratar de entender cómo se comporta Windows cuando cuando no hay nada “extraño”. Para el caso, tenía que entender qué es lo que estaba ocurriendo cuando se quería visualizar los Detalles de la presentación en las Propiedades del archivo con formato de Office 2007 y 2010, es decir con extensión (.ppsx) que era cuando presentaba todos los campos correctamente.

Después de esto, como comenté antes, debía revisar este mismo proceso abriendo el archivo con extensión (.pps) que corresponde a Office 97 y 2003 y ver cuál era la diferencia para intentar llegar a la causa.

Para intentar entender esto por supuesto, no hay otra herramienta que nos pueda ayudar mejor que la que se debe utilizar cuando todo lo demás está perdido, Process Monitor de Sysinternals.

Lo que hice fue correr Process Monitor sin aplicar ningun filtro puesto que no sabía qué proceso sería el correcto a seguir (el de PowerPoint o Explorer); después abrí las Propiedades del archivo con el formato (.ppsx) de Office 2007 y 2010 haciendo clic derecho sobre el mismo, Propiedades y pestaña Detalles. Por último abrí nuevamente Process Monitor y terminé el monitoreo con CTRL + E o bien en el menú File, Capture Events…

Como tampoco sabía por dónde empezar a buscar (Casi siempre es así), resulta una buena práctica iniciar desde abajo hacia arriba que es donde muestra los últimos eventos y que realmente son los importantes, sin embargo también me ha resultado muy útil hacer en primera búsquedas que contengan palabras relacionadas con el problema.

En este caso como estaba accediendo a los Detalles y observando los campos que más interesaban como el título, lo que hice fue abrir el cuadro de búsqueda de Process Monitor presionando CTRL + F (También se puede en el menú Edit, opción Find), a continuación le indiqué el parámetro de búsqueda que fue “Title” (Es conveniente poner los nombres en Inglés) e indicándole que la dirección fuera hacia arriba seleccionando “Up” debajo de “Direction” y finalmente clic en el botón Find Next:

El resultado fue bastante satisfactorio, pues Process Monitor me arrojó una serie de eventos en donde estaba la clave de lo que buscaba:

Lo que hice fue tratar de entender lo que ocurría en esta serie de eventos de arriba hacia abajo para determinar la causa, a continuación lo detallo un poco algunos de los resultados más importantes:

Internamente, Windows o cualquier aplicación desarrollada que utilice su API para trabajar con el Registro utiliza una serie de Funciones predefinidas para hacer sus operaciones; es primordial que siempre que se abra el Registro, igualmente se cierre para finalizar el proceso que se acabó de hacer.

En este caso, Windows está utilizando la función RegOpenKey para abrir la clave asociada a la extensión .ppsx de Office 2007 y 2010 (HKCR\SystemFileAssociations\.ppsx), como resultado fue SUCCESS (Exitoso), utiliza la función RegQueryKey para poder consultar las respectivas claves (Ver el primer y segundo evento de la captura), como también entrega resultado de SUCCESS (Exitoso) indica que la clave principal está creada pero además puede hacer uso de sus subclaves que también se encuentran.

Debemos notar que todo esto lo está haciendo bajo la rama de Registro de HKCR (HKEY_CLASSES_ROOT) que es donde Windows consulta para la asociación de todo tipo de archivos y extensiones globalmente. Normalmente además siempre tiene mayor prioridad lo que esté en HKEY_CURRENT_USER (HKCU) que es por usuario pero para este caso al intentar abrir la respectiva clave (HKCU\Software\Classes\SystemFileAssociations\.ppsx) el resultado fue NAME NOT FOUND que indica que la clave no está creada o no se encuentra, volvió a consultar en la que estaba en HKCR para proceder a las operaciones posteriores.

Ahora, después de saber que debía utilizar las claves bajo la rama de HKCR, vemos que Windows utilizó la función de RegQueryValue para hacer la consulta de un Valor de Registro, específicamente el de FullDetails con un resultado de SUCCESS (HKCR\SystemFileAssociations\.ppsx\FullDetails).

Aquí es donde me paré a observar qué tenía este Valor que es el que había consultado, sobre todo por el nombre que hacía referencia a todos los Detalles, para esto hice clic derecho sobre la clave y seleccioné Jump To para que Process Monitor me llevara directamente al valor en el Registro de Windows:

Al entrar a editar el Valor que era una Cadena, me encontré con otro resultado bastante satisfactorio:

Básicamente estaba haciendo llamado a unas especies de clases que contenían sus propios métodos: System.PropGroup.Description que me mostraba el nodo de Descripción en la pestaña Detalles dentro de las Propiedades del archivo, System.Title y System.Subject entre otros que me mostraban todos los campos que normalmente podía ver y editar.

*Nota: Para comprobarlo, se puede quitar alguno de estos y al abrir nuevamente las Propiedades del archivo .ppsx ya no se visualizará el que se haya removido del valor de registro.

En resumen entonces, había podido descubrir y aprender que al abrir las Propiedades del archivo .ppsx Windows abría la clave HKEY_CLASSES_ROOT\SystemFileAssociations y utilizaba el valor de FullDetails para mostrar todos los campos correspondientes en las propiedades dentro la pestaña de Detalles.

Con esto ya tenía una base de cómo funcionaba con el formato de Office 2007 y 2010, lo que quedaba era revisar cuál era el comportamiento con el formato para Office 97 y 2003 (.pps).

Lo que hice entonces fue guardar el log actual del Process Monitor para comparar, limpiarlo presionando las teclas CTRL + X, activar otra vez el monitoreo preisonando CTRL + E y reproduciendo el “problema” que era ir a las propiedades, pestaña Detalles pero del archivo con formato (.pps) que era el que no mostraba todo.

Volví nuevamente al Process Monitor, detuve el monitoreo y ¡Empecé a buscar!

Desafortunadamente, en este no era tan sencillo buscar porque por ejemplo el campo Título no aparecía por lo que el log me arrojaría que no encontraba resultados con esto, afortunadamente teniendo en cuenta el anterior log que había capturado busqué por el mismo valor que representaba todos los detalles, es decir: FullDetails para saber qué resultados obtenía, y encontré esto:

Básicamente, el valor de FullDetails lo estaba obteniendo de la clave HKEY_CLASSES_ROOT\* con un resultado exitoso (SUCCESS), decidí entonces ir de nuevo hasta el valor desde Process Monitor y consultar qué había en su interior:

Si detallamos, los métodos que trae esta clave hacen referencia a los que se muestran en las propiedades del archivo como el Nombre para mostrar, el tipo de archivo, el nombre del equipo, etc.

Como la consulta no la hacía en la extensión específica de (.pps) deduje entonces que el (*) de la rama de Registro se refería a los atributos predeterminados que mostraba para todos los archivos en su pestaña de Detalles por lo que si nuestro archivo lo estaba tomando de aquí se refería a que no existía en los Valores de su extensión.

Ya creía saber porque no aparecían todos los detalles al igual que en el formato de 2007 y 2010, lo que no sabía era por qué razón no se comportaba igual que en el equivalente en su extensión superior, por lo que seguí buscando y finalmente encontré lo que estaba buscando:

Como ven, en esta traza me mostraba que también estaba intentando abrir la clave de HKCR\SystemFileAssociations\.pps pero el resultado era NAME NOT FOUND lo que indicaba que la clave no existía, si no existía tampoco iba a poder consultar el Valor de FullDetails por lo que obviamente no se mostraría todo en la pestaña Detalles de las Propiedades del archivo en cuestión así que tendría que buscar en otra clave diferente.

*Nota: Recordemos que HKCR son las siglas abreviadas que utiliza Process Monitor para referirse a la rama de registro de HKEY_CLASSES_ROOT, así mismo con las demás ramas.

Pensé que si Windows consultaba la clave, podría crearse y lograr emular el mismo comportamiento que con los archivos con formato de Office 2007 y 2010.

Como no sabía qué valores y claves debía tener, exporté la clave de la extensión (.ppsx) desde el Registro de Windows y posteriormente modifiqué la extensión de .ppsx a .pps para que cuando se volvier a importar creara esta clave tal cual estaba la de (.ppsx):

Al ejecutar la clave de Registro y asegurarme de que quedara creada, volví a abrir las Propiedades del archivo (.pps) en la pestaña Detalles vi que aparentemente había funcionado ya que podía ver todo lo que faltaba:

En un primer vistazo, pensé que el problema se podría dar por solucionado con esta clave de registro creada, para mi mala fortuna, a parte de que no mostraba lo que contenían los atributos, tampoco dejaba editarlos, es decir, sólo podía visualizar los nombres de todos los campos que se deberían poder modificar más no lo podía hacer. El problema continuaba aunque ya tenía un primer avance y era que definitivamente debía existir esta clave para que se pudieran visualizar los detalles completos, ahora tenía que encontrar cómo los podría ver y modificar.

El haber creado y probado esta clave me aseguraba de que la característica de edición no se encontraba aquí por lo que tuve que volver a Process Monitor y ver qué más había en común en las llamadas que se hacían.

Investigando un poco más en la traza para ambas extensiones encontré otra llamada que se completaba a una clave de registro cerca de los eventos ya mencionados:

En el archivo con extensión (.ppsx) de Office 2007 y 2010:

En el archivo con extensión (.pps) con compabilitdad para Office 97 y 2003:

Ambos estaban utilizando la clave de su extensión ubicada en la raíz de la rama de HKEY_CLASSES_ROOT, como el resultado era SUCCESS (Exitoso) me indicaba que de “algo” estaban haciendo uso, para saber de qué, abrí las dos claves de registro, las exporté a un archivo .REG y pude comparar un poco las diferencias (A parte de su extensión como tal puesto que esta vez si existían en el Registro):

Archivo de Registro para la extensión (.ppsx):

Archivo de Registro para la extensión (.pps):

Como ven, a parte de la extensión y del número para el SlideShow que le correspondía a cada uno (12 para Office 2010 y 8 para Office 2003) las diferencias eran menores pero al parecer bastante notorias puesto que la extensión (.ppsx) tenía algunos valores y Claves adicionales en la raíz y en ShellEx que no tenía la clave de registro de la extensión (.pps).

La esperada Solución o Workaround

Algunas veces, hay que probar y arriesgarse a dañar para poder aprender o lograr salir de este tipo de inconvenientes, decidí modificar la clave de la extensión (.pps) para que tuviera el mismo comportamiento que la que funcionaba (Extensión .ppsx), para esto agregué entonces las claves y valores que le hacían falta para que quedara idéntica.

A continuación entonces, detallo el proceso detallado para dejar el comportamiento de los formatos (.pps) iguales a los de los formatos (.ppsx) y que se puedan ver y editar los Detalles en las propiedades:

*Nota: Antes que nada, aconsejo hacer respaldo de las claves de registro que se vayan a modificar para tener cómo volverlas a su estado original por si hay problemas, además en primera hacerlo en un ambiente controlado.

1. Creamos la Clave de registro para que los detalles aparezcan completos en el formato de (.pps), para esto descargamos el siguiente fichero de registro, se debe descomprimir e importar asegurándonos que finalice correctamente:

*Descargar el archivo CreatePPSAssociation

2. A continuación modificamos la clave de Registro ubicada en la raíz de la rama de HKEY_CLASSES_ROOT\.pps, para asemejarlo al de la extensión (.ppsx) ubicada en HKEY_CLASSES_ROOT\.ppsx. Les dejo también la descarga del Fichero de registro que se debe descomprimir y ejecutar, luego asegurarse de que haya importado correctamente:

*Descargar el archivo ppsModificado

3. Reiniciamos o Cerramos sesión en el sistema para que los cambios efectuados en ShellEx se puedan visualizar y se puedan editar los campos en la pestaña de Detalles.

*Nota: Si no se reinicia o se cierra sesión, seguiremos viendo los detalles faltantes pero no se podrán modificar todavía, es primordial que se haga el tercer punto.

4. Accedemos a las propiedades del archivo con formato (.pps), pestaña Detalles y veremos que ya se comporta tal cual lo hace con los formatos posteriores (.ppsx), es decir, ya se puede ver todo bien y finalmente editar:

Espero que si hay alguien que desee que se le comporte así le ayude este artículo, para las demás el mensaje que quiero dar es que veamos todo lo que se puede aprender con un problema que parece no tener mucha importancia y cuánta ayuda nos brinda el fantástico Process Monitor.

*Nota final: Ignoro si el comportamiento es normal por temas de compatibilidad o seguridad pero es algo que en cuanto pueda, trataré de investigar ya que mis pocos conocimientos hasta ahora no me dan para entenderlo.

¡Cualquier comentario o corrección es bienvenido!

Saludos,

Checho

La perdida de asociación de accesos directos y ejecutables en Windows 7. Process Monitor, Process Explorer, PsExec y su solución.

Checho — Sat, 18 Jun 2011 14:25:00 GMT

Hola,

En artículos anteriores ya hemos visto problemas relacionados con Asociación de iconos en Windows 7 o Asociación de Carpetas y Directorios pero, Windows maneja internamente distintos tipos de asociación y aun nos falta la de archivos o extensiones en general pues están implicadas diferentes claves o subclaves de Registro.

En este post exploraremos uno de los problemas más frecuentes con respecto a la Asociación de archivos que se refieren a los Accesos directos (.lnk), Ejecutables (.exe) y diferentes formas de solucionar el inconveniente que van desde la más fácil hasta la que se vuelve un poco más compleja acudiendo a Sysinternals.

*Nota: El Artículo puede estar extenso por lo que se planteará cada solución al detalle posible, la idea es que puedan encontrar diferentes caminos para solventar el problema.

El problema

Cada aplicación que se instala en Windows puede manejar un tipo de extensión de archivo propia para identificar que los archivos se ejecutan y trabajan con esa aplicación, por ejemplo la extensión PDF es propia de Adobe Reader aunque la extensión puede estar dentro de un estándar general para que otras aplicaciones también puedan administrar estos archivos como la misma .PDF o por ejemplo .ISO

Cuando se instala el Software, automaticamente toma posesión de sus extensiones pero, Windows puede cambiar este comportamiento para nosotros decidir con qué aplicación queremos abrir el archivo determinado. El problema está cuando por accidente o desconocimiento cambiamos una extensión que administra Windows por ejemplo o que es desconocida para la áplicación como la de los Accesos directos (.lnk).

El resultado será entonces que los iconos cambian al de la aplicación seleccionada y además todo lo que tenga esa extensión .lnk intentará abrirlo sin resultado.

Si por ejemplo, afectamos la asociación de accesos directos (.lnk) para que se abra con Windows Media Player, podremos tener una visualización de nustros accesos así:

Al ejecutar el archivo, a menos de que sea de tipo audio o video (Para este caso), recibiremos un mensaje de error que nos indica que no se puede reproducir esa extensión:

“El archivo seleccionado tiena una extensión (.lnk) que <Aplicación> no reconoce”

La causa

El primer paso si no se sabe qué está sucediendo sería recurrir a Process Monitor de Sysinternals y a continuación comparar el comportamiento de un equipo que esté funcional con respecto al equipo del problema cuando se trata de abrir el Acceso directo.

Analizando con calma, podemos ver una gran diferencia en una operación relacionada con la clave de Registro: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.lnk\UserChoice

Equipo Funcional:

Equipo NO Funcional:

Como ven, en el Equipo funcional trata de abrir la clave de registro HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.lnk\UserChoice, al obtener como resultado NAME NOT FOUND (La clave no existe) procede a cerrarla, mientras que en el equipo NO funcional, a parte de que sí obtiene un resultado exitoso indicado con SUCCESS (La clave existe) hace una consulta a una de las subclaves “Progid” también con un resultado exitoso y finalmente cierra la operación.

En definitiva, esta clave tiene que ver con el problema, si vamos más a fondo con el Process Monitor haciendo clic derecho y Jump To para abrir el registro, la agradable sorpresa sobre el valor “Progid” es:

Progid (Identificador de aplicación) es el valor que se encarga de asociar la aplicación que se haya seleccionado accidental o no accidentalmente (UserChoice) por el usuario para que abra esas extensiones, en este caso la de los Accesos directos.

Para este artículo, el afectado fue el Windows Media Player (wmplayer.exe).

*Nota 1: La clave implicada será la misma, lo unico que variará para cada persona con el problema será el programa asociado.

*Nota 2: Este tipo de problemas por lo general afectan sólo por configuración de usuario, por eso están ubicados en la ruta de HKEY_CURRENT_USER (HKCU)

Primera solución – Para accesos directos (.lnk) -

Si sólo tenemos afectados los Accesos directos, el procedimiento para volver a las asociaciones funcionales y originales es:

- En el Equipo NO funcional, clic en el botón Inicio, teclear Regedit y sobre el resultado, clic derecho y Ejecutar como Administrador:

- En el Registro de Windows, navegar hasta la clave:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.lnk

- Expandimos la clave .lnk (>), clic derecho sobre la subclave UserChoice y seleccionamos Eliminar:

- Después de eliminar la subclave, reiniciamos el sistema y los Accesos directos deberían estar funcionales nuevamente.

El problema extendido – Con perdida de asociacion de ejecutables (.exe)-

Recordemos que cuando algo está mal, ¡Se puede poner mucho peor!
Para este caso, se da mucho que al perder la asociación de los Accesos directos también se pierde la de los ejecutables (.exe) y es ahí cuando surgen preguntas como ¿Y cómo entro al Registro si no puedo abrir ningun ejecutable? ¿Cómo lo soluciono?

De lo que podemos estar en la mayoría de las ocasiones seguros es de que la causa no cambia, y en términos generales la solución tampoco ya que, se trata de eliminar la asociación que sea crea en el registro pero además de la de accesos directos diriginos a la de ejecutables que está ubicada en:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.exe

El problema ya mencionado por supuesto, es que al estar afectada la asociación de ejecutables (.exe) no se puede entrar ni siquiera al Registro de Windows – Recordemos que es Regedit.exe-

La solución extendida – Para Accesos directos (.lnk) y Ejecutables (.exe)-

No todo está perdido y es que si en la solución anterior aprovechamos el buen estado de la asociación de ejecutables para arreglar la de accesos directos, en este caso aprovecharemos la asociación de la que quizás sea una de las mejores herramientas que integra Windows: El blog de Notas (Notepad) en conjunto con los archivos de registro (.reg).

Si bien también es un ejecutable (Notepad.exe), para crear un archivo de texto plano no es necesario invocar a la aplicación, aprovecharemos esto entonces para generar una clave de registro desde el texto plano (Cambiando a extensión .Reg) para borrar las claves de registro implicadas en el problema (Aunque suene un poco contradictorio).

¿Cómo hacerlo?

- Sobre el Escritorio o cualquier directorio de preferencia del equipo NO funcional hacemos clic derecho y seleccionamos Nuevo > Documento de texto

*Nota:

La estructura general de un archivo de Registro se compone de la siguiente forma:

versiónEditorRegistro
línea en blanco
[rutaRegistro1]
"nombreDato1"="tipoDatos1:valorDatos1"
nombreDato2"="tipoDatos2:valorDatos2"
línea en blanco
[rutaRegistro2]
"nombreDato3"="tipoDatos3:valorDatos3"

Por ejemplo, si quisieramos crear una nueva clave llamada “Demo” dentro de HKEY_CURRENT_USER teniendo en cuenta la versión del Registro en Windows 7 y la ruta, quedaría así:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Demo]

Se guarda con el nombre que se quiera y la extensión .REG y al ejecutarlo e importarlo la clave quedará creada.

Así mismo, como se puede crear generando la clave, se puede eliminar claves, subclaves y valores, sólo se debe anteponer el signo de menos (-) dependiendo de lo que se quiera quitar.

Por ejemplo, si quisiera quitar la Clave que acabé de crear previamente “Demo” dentro de la rama de registro HKEY_CURRENT_USER quedaría así:

Windows Registry Editor Version 5.00

[-HKEY_CURRENT_USER\Demo]

Igualmente, se guardaría con extensión .REG y al ejecutarlo e importarlo ya no existiría esa clave den el Registro de Windows.

En este orden de ideas, para eliminar la clave que nos está generando el problema en las dos asociaciones (.lnk y .exe) debemos agregar el signo de menos (-) antes de toda la clave correspondiente, como podemos de una vez integrar las dos ejecuciones en un mismo archivo, nuestro Blog de notas tendría que quedar así:

Windows Registry Editor Version 5.00

[-HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.lnk\UserChoice]

[-HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.exe\UserChoice]

Ahora, clic en Archivo, Guardar como, le pones cualquier nombre y no podemos olvidar la extensión .REG, para este artículo yo le puse FixLNKEXE.REG:

*Nota: Si no se le pone el signo de menos (-), lo que hará es crear otra vez la clave de registro (Cosa que no nos servirá).

Si desean, pueden descargar el Fichero de Registro que realiza esta operación (Eliminar las claves afectadas) desde aquí:

*Nota: Este fichero de registro es válido para reparar el problema con sólo una de las dos asociaciones afectadas también, por ejemplo la de Accesos directos (.lnk) por lo que lo pueden descargar y ejecutar en vez de seguir la solución manual documentada anteriormente.

Al ejecutar el fichero, importarlo y reiniciar o cerrar sesión en el equipo, los iconos y las aplicaciones deberían volver a su estado funcional nuevamente.

El problema en el peor de los casos

Por lo general, este problema no llega hasta este punto pero por supuesto ¡Se puede dar! y, ¿Cuál es el peor de los casos?

¿Qué sucede si además de los Accesos directos (.lnk) y los Ejecutables (.exe) ni siquiera la extensión de Texto plano (.txt) y de Registro (.reg) están funcionales?

Para este punto, así se afecte uno de los dos (txt ó reg) ya se vuelve algo bastante complejo de solucionar y de hecho desde la cuenta de usuario afectada ya no se podría y es ahí cuando uno podría en primera instancia pensar en restaurar sistema o hasta reinstalar Windows.

Afortunadamente, como comenté en el principio del artículo, el fallo de asociación en la mayoría de las ocasiones afecta por perfil sólamente, es decir en la rama de registro que cada usuario nuevo creado tiene con configuraciones únicas (HKEY_CURRENT_USER).

Lo que indica esto es que en la mayoría de las veces, creando o accediendo a otra cuenta local, podremos tener acceso a la funcionalidad que debe tener Windows para abrir estos tipos de archivos.

Esto sin embargo, no significa que ya nos resignemos y pasemos todo para la nueva cuenta, significa que podremos hacer uso de esta ventaja para acceder y reparar el registro de otro usuario local.

Aquí es donde finalmente damos paso a Sysinternals, específicamente PsExec.

La solución para el peor de los casos

PsExec nos permite básicamente ejecutar procesos y aplicaciones de forma remota en otros equipos o hasta en otras cuentas de usuario locales, lo interesante es que es portable y no es necesario instalar ni realizar configuraciones adicionales, sólo ejecutar y trabajar!

*Nota: PsExec requiere específicamente entregarle credenciales para darle los permisos de ejecución de acuerdo a la tarea que se vaya a realizar.

Volviendo al caso…

Como desde la cuenta NO funcional ya no se puede hacer nada más, debemos Cambiar de usuario e iniciar con otra cuenta que pertenezca al Grupo de Administradores en modo Aprobación de administrador.

Lo que haremos es ingresar al Registro en la rama HKEY_CURRENT_USER pero equivalente al usuario no funcional (De nuevo recordemos que el HKCU varía por usuario) y eliminar las claves de UserChoice en todas la extensiones afectadas.

En realidad, a parte del PsExec, hay otra forma para realizarlo directamente desde Windows por lo que a manera de conocimiento, explicaré las dos aunque enfatizando y recomendando que es mucho más fácil proceder directamente con PsExec.

Forma manual:

Entre todas las ramas que existen en el Registro, hay una específica que contiene la de HKEY_CURRENT_USER entre otras por usuario, específicamente la rama de HKEY_USERS, el problema es que la identificación por usuario lo hace con el SID (Identificador único de usuario) por lo que a simple vista sería complicado determinar cuál es la del perfil que necesitamos arreglar:

¿Cómo identificar entonces el SID que pertenece a nuestra cuenta afectada?

¡Aquí es donde entra Process Explorer de Sysinternals!

Como hicimos cambio de usuario (Si no fue así, entren a la cuenta afectada y hacen clic en Inicio, clic en la flecha del botón apagar y Cambiar de usuario) los procesos que están activos en la cuenta NO funcional se visualizarán en Process Monitor, si no habían procesos abiertos, siempre se visualizará el proceso padre: Explorer.exe.

Como predeterminadamente, el usuario al que pertenece no se visualiza debemos hacer clic en el menú View y Select Columns:

En la ventana de Select Columns en la pestaña de Process Image debemos seleccionar User Name para poder ver esta información y clic en Aceptar para que se visualice en Process Explorer:

Ahora, en Process Explorer podremos ver en cuál de los dos procesos de Explorer.exe corresponde al usuario afectado con la columna de User Name:

Hacemos doble clic sobre el proceso y nos abrirá la ventana de Propiedades, allí nos pasamos a la pestaña de Seguridad y podremos ver la información que necesitamos:

Como ven, debajo de "User” tenemos el “SID” correspondiente a ese proceso que previamente aseguramos que correspondiera al Explorer.exe del usuario NO funcional, específicamente el SID es: S-1-5-21-1231788061-2787996694-3405420119-1006

Teniendo esto en cuenta, procedemos a solucionar el problema, para esto:

Hacemos clic en Inicio, tecleamos Regedit y sobre el resultado clic derecho y Ejecutar como administrador.

Expandimos la rama de HKEY_USERS y posteriormente expandimos la que corresponde al SID que nos entregó Process Explorer del usuario NO funcional. Pueden haber más de 4 que correspondan con el SID, debemos buscar en la primera.

Una vez hecho esto, símplemente buscamos la Clave que corresponde a cada asociación como si lo estuviéramos haciendo desde el Regedit del usuario en cuestión.

Como hay varias extensiones afectadas, debemos ubicar la clave que contiene todas nuevamente y después empezar a reparar una por una. Recordemos que la clave de Asociación de archivos por usuario está en:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.exe

Para este caso, variarían la primera por HKEY_USERS y a continuación el SID, por ejemplo si fuera a buscar por el Acceso directo (.lnk) sería:

HKEY_USERS\S-1-5-21-1231788061-2787996694-3405420119-1006\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.lnk

Aquí de nuevo, procedemos por extensión afectada (Por ejemplo .lnk, .exe, .txt, .reg) a borrar la sublcave de UserChoice haciendo clic derecho y Eliminar.

Después de esto, reinciamos el equipo y al entrar de nuevo pero en la cuenta NO funcional, todo debe estar asociado correctamente.

Utilizando PsExec:

Como escribí en la descripción de PsExec, nos permite ejecutar procesos pensandos más para una máquina remota pero como todas las herramientas de Sysinternals tiene sorpresas estupendas y es que también lo puedo utilizar para ejecutar procesos en otras cuentas locales.

Desde aquí pueden descargar PsExec y además ver una descripción directa del autor:
http://technet.microsoft.com/es-es/sysinternals/bb897553

Si no queremos complicarnos más de lo que ya estamos con este problema, debemos cerrar sesión desde la cuenta NO funcional (También se puede cambiar de usuario), a continuación Iniciar sesión con una cuenta que esté en el Grupo de Administradores en modo aprobación de administrador y allí descargar PsExec en el Escritorio o en un Directorio de preferencia.

Hacemos clic en Inicio, tecleamos CMD y sobre el resultado clic derecho y Ejecutar como administrador:

Desde la consola de Comandos debemos situarnos en el directorio donde se haya descargado PsExec utilizando el comando “cd”, por ejemplo, para este artículo que descargué la herramienta en el Escritorio, el comando sería:
cd “C:\Users\Administrador\Desktop” donde “Administrador” es el nombre de usuario de la cuenta que iniciaron sesión y ENTER:

Ahora, como PsExec está en este directorio, podremos conectarnos al Regedit del otro usuario NO funcional, para esto utilizaremos este comando:

PsExec –u <UsuarioActual>\<UsuarioNOFuncional> –p <PasswordNOFuncional> –h –i C:\Windows\Regedit.exe

Donde <UsuarioActual> es la cuenta del Grupo de Administradores con la que iniciamos sesión y descargamos PsExec, <UsuarioNOFuncional> es el nombre de la cuenta que tiene el problema de asociación que deseamos corregir, <PasswordNOFuncional> es la contraseña del usuario NO funcional (El del problema), –h es para que haga la elevación del Token de usuario (Por el UAC) con las credenciales que le estamos enviando e –i es para que ejecute el programa con la ventana interactiva del usuario actual (Para que veamos el Regedit corriendo en el usuario Administrador).

Para este caso por ejemplo sería:

PsExec –u Administrador\Demo –p demopass –h –I C:\Windows\Regedit.exe

(Hacer clic para ver la captura para verla en tamaño real)

Sin darle mucha importancia al “Acceso denegado”, en unos pocos segundos se debe abrir una ventana de Regedit y para estar seguros de que pertenece al otro usuario NO funcional, podemos abrir Process Explorer, entrar en sus propiedades y ver que tanto el usuario como el SID pertenecen al perfil con problemas:

Desde la ventana de Registro ahora ya no tenemos que expandir HKEY_USERS sino que hacemos la búsqueda en la rama de HKEY_CURRENT_USER como si estuviéramos logueados en la cuenta con el problema buscando las claves que originan el problema (Para este artículo por ejemplo .lnk, .exe, .txt, .reg):

Aquí, como en todo el artículo, clic derecho sobre la subclave UserChoice y seleccionamos Eliminar, hay que repetir todo esto para cada extensión afectada debajo de la clave:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts

Reiniciamos el sistema, volvemos a iniciar sesión pero desde la cuenta afectada y el problema ahora debería estar resuelto.

¡Todo listo!

La otra posibilidad de que se empeorara el problema es que afectara por máquina y eso sería a nivel de HKEY_CLASSES_ROOT cosa que en realidad ocurre poco.

Espero les sea de utilidad y puedan ayudarse o disfrutar tanto como yo lo hice.

Saludos,

Checho

El Malware “Umgqgk.exe”, la carpeta “RECYCLER” que se creaba al conectar USB, Process Monitor y su solución.

Checho — Mon, 13 Jun 2011 07:28:00 GMT

Hay algo que personalmente me molesta y son los diferentes tipos de Malware en los que puede resultar infectado un Equipo por culpa de un dispositivo USB y es que lamentablemente, están los que a pesar de ser muy comunes los Antivirus por ejemplo no los detectan y por supuesto el dispositivo en sí es el que resulta más afectado.

Problema y Solución

En este caso, al conectar cualquier dispositivo USB al equipo en cuestión, me encontraba con una no tan grata sorpresa y es que se creaba una carpeta oculta llamada RECYCLER que incluía un archivo .ini y un ejecutable en su interior:

Los archivos se denominaban “b845ef76.exe” y “Desktop.ini”.

Además de todo esto, cada carpeta que incluyera la USB se modificaba como Acceso directo por lo que al portar esto la USB, fácilmente podía infectar otro equipo con sólo intentar abrir los directorios.

Por más que analizara el dispositivo con la solución de seguridad (Microsoft Security Essentials) o le diera formato al dispositivo, cuando se reconectaba volvía a reproducirse.

Es ahí entonces cuando decidí ejecutar la mejor herramienta que se puede tener cuando lo demás siempre está perdido, Process Monitor de Sysinternals.

Como no sabía qué proceso analizar (El más opcionado a lo mejor sería Explorer.exe) corrí el monitoreo completo del sistema, di formato al USB previamente y reproducí todo el comportamiento, al terminar paré Process Monitor y empecé a revisar el Log.

Como en estas situaciones de novato con la herramienta, lo que empecé a buscar fue patrones o nombres que tuvieran relación con el problema, por ejemplo RECYLCER y el nombre en cuestión del ejecutable “b845ef76.exe”.

Es normal que en toda la Traza que captura Process Monitor hayan múltiples llamadas y operaciones con estos mismos nombres pues las Aplicaciones o Windows puede verificar siempre que la llave o el registro exista y después realizar las consultas.

Tenía entonces que tratar de subir hasta donde empezaba el llamado y desde ahí ver los comportamientos y bajando un poco me encontré con esto:

La creación de la carpeta no lo podía impedir ya que era un proceso de Explorer.exe y se completaba satisfactoriamente (No sé cómo impedir que haga algo que no se esté llamando por Registro todavía ) , sin embargo, como ven hay una serie de consultas a un directorio del sistema: C:\Users\Hader\AppData\Roaming\Umgqgk.exe

Después de esto era que se completaba satisfactoriamente la creación a b845ef76.exe lo que indicaba que ya el dispositivo quedaba infectado y con los archivos dentro de la carpeta.

Ahí estuvo mi primera pista, lo que hice fue entonces desde el Process Monitor hacer clic derecho y Jump To para ir a ese directorio y en efecto habían dos Aplicaciones de extraña procedencia:

Supuse que éstas eran las que estaba ocultando la carpeta y que además estaban creando tanto los directorios como los archivos que incluían.

Verificando primero con Autoruns que estos archivos no estuvieran arrancando con Windows, procedí a eliminarlos de este directorio.

A continuación, le di formato otra vez al dispositivo, lo desconecte y reconecté para ver si se volvía a reproducir el problema.
Para mi fortuna, ya no se hacían los accesos directos en las carpetas que incluyera el dispositivo y no había nada oculto pero la carpeta “RECYCLER” seguía creándose aunque ya sin ningun archivo.

Afortunadamente, las llamadas a los ejecutables y demás archivos ya no se encontraban por lo que había salido ya de algo pero, aún me faltaba descubrir el por qué la carpeta se seguía creando (Esto indicaba además, que la infección en parte seguía).

Volví a correr Process Monitor, reproducí el comportamiento y de nuevo ¡A buscar!

Por más que trataba de encontrar otra llamada a algun ejecutable o que fuera extraño (Dentro de mis pocos conocimientos) no logré tener un buen resultado por lo que se empezaba a volver más complicado de lo que había pensado en un primer momento.

Es aquí cuando recordé que una práctica que puede ayudar con Process Monitor en estos casos es ver dónde empieza a reproducirse el problema (Ya encontrado) y monitorear qué operaciones se estaban realizando antes y esto fue lo que encontré:

Lo primero que hacía antes es realizar unas consultas a controladores de dispositivos USB (La lista era larga antes de que empezara el problema).

No sabía realmente qué hacer, pero, algunas veces el “probar” suele traer buenos resultados, lo que supuse es que la infección podría venir de un controlador USB de los tantos que se estaban llamando y que se activaba al conectar el dispositivo y hacer la consulta.

Por este motivo, abrí el Administrador de dispositivos, localicé todos los Controladores USB y empecé a desinstalarlos uno por uno desde el controlador de Raíz:

Además de esto, también desinstalé el Controlador USB en el nodo de Controlador de Disco más abajo, le di formato (Otra vez) al dispositivo USB, reinicié el equipo, lo volví a conectar y ¡Wualá! Ya no se creaba la carpeta ni se reproducía comportamiento extraño dentro del dispositivo.

Probé en todos los puertos puesto que en cada uno se reproducía pero para mi alegría, el Malware se había ido!

Queda la duda de cuál controlador en cuestión estaba cargando el Malware sin embargo, quedó un buen aprendizaje de todo esto y es primero siempre tratar de encontrar el origen del problema para poder aprender que considero lo más importante y en ocasiones se vale seguir nuestras propias teorías.

Por supuesto… ¡Continuar aprendiendo Sysinternals!

Espero que le pueda ser útil a alguien el procedimiento que seguí por si tiene un comportamiento similar.

Saludos,

Checho

La previsualización de ventanas (Aero Peek) no funciona y aparece desactivada en Windows 7, Process Monitor y su solución.

Checho — Wed, 27 Apr 2011 14:40:00 GMT

Windows 7 incorporó unas características mejoradas a su aspecto visual conocido como Aero (Entre muchas otras funcionalidades en diferentes aspectos).
Estas características se conocen como Aero Shake, Aero Snap y Aero Peek.

La última (Aero Peek) integra la posibilidad de tener una previsualización completa de nuestro escritorio sin tener que minimizar todas las ventanas abiertas y además, desde la Barra de tareas también podremos visualizar cada ventana abierta en su tamaño de previsualización o bien en su tamaño completo volviendo transparentes las demás ventanas con sólo pasar el mouse por el icono de la aplicación abierta o minimizada.

Se vuelve bastante útil una vez que te acostumbras, interactuando por supuesto con las demás funciones visuales. Pueden ver más detalle de cada una en Este artículo.

*Nota: A continuación describo el procedimiento empezando desde el problema hasta su solución, al final del artículo en “Descarga de Registro” podrán bajar el fichero para solucionar el inconveniente.

El problema

Cuando se modifica estos comportamientos incluyendo la Previsualización o no de las ventanas junto con los colores de Windows y temas en general puede desactivarse la característica del Aero Peek. Es decir, al pasar el Mouse por las ventanas minimizadas aunque podremos ver la previsualización de la ventana en miniatura no podremos interactuar con ella en su tamaño normal.

Este comportamiento se puede regular haciendo clic derecho en el Botón de inicio, seleccionar Propiedades y en la pestaña Genera asegurarse de que esté seleccionado “Utilizar Aero Peek para previsualizar el escritorio”.

El inconveniente está cuando no se puede utilizar el funcionamiento y además aparece deshabilitado y sin posibilidad de habilitar en las Propiedades:

A pesar de que se modifiquen los cambios manuales nuevamente, el Aero Peek no se puede volver a habilitar.

La causa

Para determinar qué estaba causando que la opción apareciera deshabilitado procedí a correr una de las mejores herramientas que conozco Process Monitor otra vez y poder hacer seguimiento a lo que estaba ocurriendo “por debajo”.

Como la personalización se hace gráficamente, el primero a seguir es el proceso padre de todos Explorer.exe.

Ejecuté Process Monitor y lo primero es detener el trace actual, para esto se debe presionar CTRL + E o bien ir al menú File y Capture Events.

Para hacer el filtro dentro del monitoreo basta con presional las teclas CTRL + L, hacer clic en el botón de la barra de herramientas de la aplicación o bien en el menú Filter y seleccionar Filter…

Especificamos “Process name” en el primer “ListBox”, “is” en el segundo y finalmente en la caja de texto el nombre del proceso a seguir, en este caso Explorer.exe

Clic en el botón Add y por último clic en los botones de Apply y OK para que se integre el filtro al Process Monitor.

Sobre el Process Monitor como recien ejecutado mantiene un monitoreo predeterminado de todo, antes de proceder se debe siempre limpiar todo el rastro actual, para esto se presionan las teclas CTRL + X o bien en el menú Edit y seleccionar Clear Display:

Por último se debe reproducir el problema para iniciar el Monitoreo, así que presionamos de nuevo CTRL + E o bien menú File y Capture Events…

Debía hacer el mismo procedimiento como si quisiera activar el Aero Peek para saber qué llamadas se hacen a nivel de registro y operaciones internamente, así que hice clic derecho sobre el menú de inicio, pestaña General y hasta ahí volví a detener el monitoreo de Process Monitor con CTRL + E.

En esta ocasión (Y en realidad casi siempre) no sabía por dónde empezar a buscar, pero como he dicho en artículos anteriores he considerado buena estrategia comenzar con patrones y nombres reconocidos, para este caso lo que hice fue buscar en dónde se estaba haciendo referencia a la palabra “Peek” y este fue mi agradable resultado:

Windows entre sus operaciones mientras monitoreaba el proceso para habilitar Aero Peek abría una llave de registro: HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM

Además de esto hacía una consulta a una clave “EnableAeroPeek” lo que me daba una gran pista!

El problema sin embargo era que el resultado debajo de la última columna “Result” era “Success” (Exitoso) por lo que la llave de registro existía y si analizamos hasta ahí no tendría por qué estar fallando el Aero Peek si encontraba las claves correspondientes.

Para indagar más a fondo tuve que abrir la Llave de registro para tratar de entender un poco más, para esto sobre la llave en el Process Monitor se puede ir directamente haciendo clic derecho y seleccionar “Jump to”:

De nuevo encontré una gran sorpresa y lo que sería la causa por la que el Aero Peek no estaba funcionando:

La clave tenía un valor de cero ( 0 ) que para el Registro de Windows, dependiendo de las variables (Y en general para valores booleanos) se refiere a Desactivado!

Windows estaba consultando a la clave, pero como contenía este valor debe trabajar como se lo indica así que el Aero Peek no trabajaría.

La solución

Lo único que tuve que hacer fue cambiar el valor a ( 1 ) correspondiente a Activado:

Cerré el Registro de Windows y ahora, aparte de que el Peek funcionaba, podía reconfigurar a gusto su comportamiento:

Descarga de Registro

Para las personas que tengan el mismo inconveniente, pueden seguir los pasos anteriores para modificar el Registro pero si desean hacerlo más rápido pueden descargar el fichero que activa otra vez el Aero Peek desde aquí:

Lo deben descargar, descomprimir y ejecutar.
Después de aceptar y confirmar la importación del Registro revisen en las Propiedades del menú inicio y además el comportamiento de la característica, debería estar reparado.

Saludos,

Checho

Windows Media Player no abre y al ejecutar archivo indica “Error en la ejecución del servidor”. Process Monitor y su solución

Checho — Tue, 29 Mar 2011 12:46:00 GMT

Hola,

Navegando de nuevo un poco en los Foros, por los últimos días se ha vuelto más constante un problema con Windows Media Player 12 específicamente en Windows 7, a continuación como he tratado siempre les mostraré la reproducción del problema y el proceso a su posible solución.

*Nota: La llave de registro para solventar el inconveniente se puede descargar al final del artículo pero se DEBE seguir el procedimiento descrito en “La solución” dependiendo de la arquitectura que se tenga (32 ó 64 bits) antes de aplicar la llave para que pueda funcionar.

El problema

En Windows 7 al tratar de abrir Windows Media Player desde la barra de tareas (Predeterminádamente está anclado en la instalación del sistema operativo) o desde su ubicación en Todos los programas “trata” de abrir pero no muestra interfaz, y se desvanece:

Además de esto si se trata de reproducir un archivo de audio o video después de unos segundos Windows indica un error que indica error en la ejecución del servidor similar a este:

“Error en la ejecución del Servidor (Server execution failed)”

Indentificando la causa

En primera instancia como casi siempre es bastante complicado determinar qué está causando el problema y mucho menos el por qué.

Por lo general un buen camino es identificar qué se hizo antes cuando la aplicación funcionaba correctamente, algunas veces se debe a instalación de ciertas aplicaciones y se resuelve con sólo desinstalarlas.

Sin embargo en casos como este que puede no ser la solución desinstalar lo que había hay que indagar más a fondo puesto que el mensaje de error (Como muchas veces) no es muy claro en el problema. Para llegar al fondo por supuesto recurrí al famoso Process Monitor de Windows Sysinternals puesto que requería saber qué estaba sucediendo a nivel de entradas y salidas internamente cuando ejecutaba Windows Media Player.

Como Process Monitor identifica absolutamente todo lo que hay por debajo debemos “filtrar” lo que necesitamos, para esto al ejecutarlo, clic en el menú Filter y seleccionar Filter.. o símplemente la combinación de teclas CTRL + L

En la ventana de Process Monitor como estamos siguiendo al Windows Media Player debemos hacer el filtro Por proceso y especificando el del propio reproductor que es wmplayer.exe

En la primera columan seleccionamos “Process name” y en el cuadro de texto digitamos wmplayer.exe, posteriórmente clic en el botón Add, Apply y finalmente en el botón Ok para guardar los cambios.

Por último hay que detener el monitoreo actual que está haciendo Process Monitor con la combinación de teclas CTRL + E o en el menú File y seleccionar Capture Events…
Después de esto hay que limpiar los resultados actuales con la combinación CTRL + X para que todos los resultados al empezar el monitoreo pertenezcan sólo a la operación que se esté realizando.

Una vez limpio todo volvemos a ejecutar CTRL + E o Capture Events desde el menú File y a continuación “reproducirmos el problema”, pero como en este caso en principio no lo tenía lo que hice fue símplemente ejecutar el Windows Media Player así abriera normalmente para saber cuál era el proceso correcto de ejecución “por debajo”.

Al abrir el Media Player (o para otras personas al reproducir el error, es decir tratar de abrirlo) se debe volver a detener el monitoreo para poder tener el Log preciso desde que se inicio hasta que se terminó y que no registre más tareas, para esto basta con volver a presionar CTRL + E.

Ahora, personalmente como no tenía el error, para saber la solución primero tenía que reproducirlo por lo que la búsqueda se hace un poco más dificultosa.

Lo primero que tuve en cuenta en esta ocasión es que probáblemente no se refería a un problema de configuración ni de máquina ni de usuario del Media Player puesto que el proceso ejecutaría y aunque hubiera error la interfaz abriría por lo que quedaron descartadas todas las llaves que provinieran de HKCU (HKEY_CURRENT_USER) y HKLM (HKEY_LOCAL_MACHINE) que se refieren a configuración por usuario y por máquina respectivamente en cuanto a Windows y aplicaciones.

Para variar además no seguí el consejo y la mejor práctica que es empezar a analizar la Traza de abajo hacia arriba sino que esta vez fui bajando poco a poco hasta encontrar la operación en registro que no estuviera ligada a estas dos llaves, para mi fortuna o sorpresa lo que encontré:

Como ven la primera referencia diferente llevaba a: HKEY_CLASSES_ROOT\Interface\{00000134-0000-0000-C000-000000000046}

*Nota: Como ven hay referencias a HKCU (Que antes la había obviado) pero el resultado aquí si hacen el monitoreo verán que es NAME NOT FOUND por lo que no está creada esta llave en este directorio y pasa a la llave “Padre” HKCR que sí daba resultado SUCCESS.

Además de esto, tal cual sucede con un trabajo sobre una base de datos habían varias operaciones sobre una subclave en especial ProxyStubClsid32 que incluía abrir, consultar, validar y cerrar por lo que definitívamente algo bueno debía traer esta llave.

Para ir diréctamente a la llave basta con hacer clic derecho desde el Process Monitor y seleccionar Jump to…

Como en mi equipo estaba funcionando bien el Media Player tenía que buscar la forma de reproducir el error tal cual, por supuesto procedí a la forma más práctica, dañando!
Lo que hice fue borrar esa llave del Registro de Windows con el Media Player previamente cerrado y después tratar de ejecutar el Reproductor.

Para mi fortuna, ¡Problema reproducido! no me abría el reproductor y además al ejecutar archivos me encontraba con el error de fallo en la ejecución del servidor.

En conclusión la causa entonces podría ser falta de registro de esa interfaz del Media Player, o bien que ya se encontraba corrupta (Basta con cambiar algún parámetro en la clave).

*Importante:

Si buscan este mismo comportamiento en un equipo Windows 7 de 64 bits encontrarán que la ruta de registro varía un poco con respecto a la anterior agregando antes de \Interface el \Wow6432Node:

HKEY_CLASSES_ROOT\Wow6432Node\Interface\{00000134-0000-0000-C000-000000000046}

La explicación es que Windows 7 de 64 bits utiliza el componente de WOW64 para virtualizar aplicaciones de 32 bits en sistemas de 64 bits, y aunque el sistema operativo predeterminádamente tiene el Reproductor y otras aplicaciones en 64 bits lo hace por temas de compatibilidad principalmente.

Teniendo en cuenta lo anterior, la solución a continuación va a tener un proceso similar pero unico dependiendo de si tienen sistema de 32 ó sistema de 64 bits.

La solución (Para sistemas de 32 bits):

1. Abrimos el Registro de Windows haciendo clic en inicio, tecleando Regedit y clic derecho sobre el ejecutable, “Ejecutar como administrador” o bien desde el Process Monitor vamos diréctamente a la llave haciendo clic derecho y Jump to.

- Navegamos hasta la llave:
HKEY_CLASSES_ROOT\Interface\{00000134-0000-0000-C000-000000000046}

2. Clic derecho sobre la llave y seleccionamos Permisos (Permissions):

3. En la ventana de Permisos hacemos clic en el botón Avanzado (Advanced):

4. En la ventana de Configuraciones avanzadas de seguridad clic en la pestaña Propietario (Owner) y debajo de Cambiar Propietario actual (Change Current owner) debemos seleccionar el usuario local nuestro que pertenece al grupo de administradores (Para este artículo DemoMig):

Clic en el botón Aplicar (Apply) para que se cambie el Propietario actual (Current owner) y posteriormente clic en el botón Aceptar (Ok) para guardar cambios y cerrar la ventana.

5. De vuelta en la ventana de Permisos seleccionamos el grupo de Administradores (Que es donde debe estar nuestra cuenta de usuario) y debajo de Permisos para los Administradores debemos seleccionar la ficha de Control total, luego el botón Aplicar y Aceptar para guardar los cambios:

6. Ahora que la llave principal tiene permisos totales debemos asegurarnos que las subllaves tengan los mismos permisos, es decir, control total.
Expandimos con el icono (>) sobre la llave de Interface en la que estamos y repetimos los pasos del 2 al 5 nuevamente.

*Nota 1: Puede que no tengan que cambiar permisos pero sí asegurarnos que el propietario sea el usuario actual, aunque en teoría modificando la llave primaria las demás obtienen los mismos permisos.

*Nota 2: Puede (Y sería normal) que algunas personas que tengan el problema no posean las mismas subllaves, en este caso el proceso se hace a las que hayan.

7. Ahora que tenemos el control total sobre la llave afectada debemos proceder a cambiarla para importar una que tenga los componentes de interfaz registrados corréctamente, para este caso de 32 bits he subido la llave de Registro a mi Skydrive para que la descarguen, descompriman y ejecuten, la pueden bajar desde aquí:

*Importante:

Para tener buenos resultados, al ejecutar la llave de registro les debe informar que se importó todo satisfactóriamente:

*La ruta que se muestra y nombre de registro varía en cada máquina.

Si les indica que NO se pudieron escribir registros correctamente deben repetir de nuevo los pasos anteriores para tomar propiedad sobre la llave y asignar permisos ya que indica que no todas las llaves obtuvieron los cambios, posteriormente volver a ejecutar la llave hasta que el resultado sea satisfactorio.

Después de esto ejecutamos nuevamente el Reproductor de Windows y esta vez debería abrir sin problemas =)

La solución (Para sistemas de 64 bits)

- Navegamos hasta la llave:
HKEY_CLASSES_ROOT\Wow6432Node\Interface\{00000134-0000-0000-C000-000000000046}

2. Repetimos los mismos pasos especificados anteriormente en “La solución (Para sistemas de 32 bits)” desde el punto 2 hasta el punto 6

3. Ahora que tenemos el control total sobre la llave afectada debemos proceder a cambiarla para importar una que tenga los componentes de interfaz registrados corréctamente, para este caso de 64 bits he subido la llave de Registro a mi Skydrive para que la descarguen, descompriman y ejecuten, la pueden bajar desde aquí:

*Nota: Aunque es casi el mismo procedimiento los registros a descargar y a aplicar son diferentes!

*Importante:

Para tener buenos resultados, al ejecutar la llave de registro les debe informar que se importó todo satisfactóriamente:

*La ruta que se muestra y nombre de registro varía en cada máquina.

Después de esto ejecutamos nuevamente el Reproductor de Windows y esta vez debería abrir sin problemas =)

Espero que les pueda ser de utilidad, si alguien entra aquí, sigue el procedimiento y puede solucionar el problema, así también como si no puede solucionar el problema ¡Comentarios bienvenidos!

Saludos,

Checho

Al ejecutar Internet Explorer 9 se abren dos pestañas simultáneamente, Process Monitor y su solución.

Checho — Fri, 18 Mar 2011 00:52:00 GMT

Hola,

¡Seguimos trayendo problemas y soluciones!
Y realmente es fascinante porque no hay mejor forma de aprender Sysinternals que llevando la Suite a la acción.

El “problema”

Seguramente todos ya se dieron cuenta que hace unos días (Dos exáctamente) se lanzó a nivel mundial la última versión del navegador de Microsoft, Internet Explorer 9, en mi concepto siguiendo muy bien su estrategia de “La web más hermosa”.

Por ahorros de tiempo y facilidad decidí Integrar Internet Explorer 9 a una imagen de Windows 7 utilizando Dism para poder grabarla y que me incluyera tanto el SP1 como el IE9.

El “problema” por llamarlo así es que al ejecutar el Internet Explorer en esta instalación limpia, después del pequeño y renovado asistente que ahora sólo pide la activación o no activación del SmartScreen se abrían las dos pestañas, la primera que era mi página de inicio y la que lanza normalmente este asistente que se dirige a la página de Microsoft referente a IE9.

En esa primera ejecución es normal, pero seguía y seguía pasando sin importar que restableciera las configuraciones o bien que cambiara mi página de inicio:

Como la imagen era personalizada, empecé a pensar que seguramente eso había sido la causa (Teniendo en cuenta que en otro equipo la instalación la había hecho actualizando y no inyectando IE) así que hice la más fácil pero lamentablemente la más larga.

Volví a bajar el sistema, el IE9, de nuevo monté la imagen, inyecté el IE y creé el .ISO que posteriórmente grabé para reinstalar.

Confiado de esto volví a probar pero, el problema no se solucionó.

Causa y solución

Como no sabía qué estaba sucediendo se empezaba a volver algo complicado, pero afortunadamente iba recogiendo pistas como un primer “descarte” de que la inyección de la actualización o la instalación hubiera quedado corrupta (Aunque la primera habría que validar más a fondo qué tanto pesa en el inconveniente).

La única forma de buscar qué estaba pasando era por supuesto seguir la traza en la ejecución de Internet Explorer 9 y buscar qué podría estar generando la doble instancia de pestañas repetidamente.

Para eso entonces ejecuté Process Monitor!

Como siempre lo que hice fue hacer un filtro sólo al proceso de Internet Explorer (iexplore.exe) yendo al menú Filter y seleccionando Filter, después hacer la relación “Process name”, “is” y “Iexplore.exe” y clic en los botones de Apply y OK para guardar los cambios:

Ahora, lo recomendable es borrar el monitoreo actual con las teclas CTRL + X, y reproducir el problema para que todo se haga siguiendo el proceso y que al terminar sea más cómodo (Entre tanto resultado!) poder encontrar el culpable.

Después de reproducir el problema no sabía la verdad cómo empezar a buscar el posible causante, aunque en principio podría imaginarme una doble llamada a páginas web desde el registro, pero es engorroso buscar entre tanto cuando no hay certeza de dónde empezar!

Para mi fortuna antes de buscar seguí un poco de consejos de Windows Internals referentes a Process Monitor y de Daniel Martín que se referían a utilizar un poco el sentido lógico, y empezar del último registro hacia el primero (Abajo hacia arriba).

El sentido común de esto estaba en que la unica forma de que Internet Explorer (En esta y desde IE 7) muestre la página principal del navegador era cuando corría el Primer asistente que permitía configurar características como SmartScreen, Proveedor de búsqueda, etc.

En IE9 aunque sólo se configura el filtro, sigue siendo el primer asistente de ejecución, y era como si así se le haya indicado la finalización, no se estuviera guardando internamente esto y siguiera lanzando la pestaña con la página al abrir sesión en el explorador.

Lo que hice entonces fue detener el monitoreo con las teclas CTRL + E, bajar completamente y aplicar una búsqueda de abajo hacia arriba con iniciales de lo que estaba buscando (Primer asistente de configuración), y un buen comienzo es indicarlo en inglés que es como normalmente las claves de registro se nombran para alguna tarea, para este caso sería: “FirstRun”

Para hacer la búsqueda recordando en Process Monitor basta con presionar CTRL + F o ir al menú Edit y seleccionar Find.

En la ventana de búsqueda se le indica el parámetro referente al Primer arranque o asistente que buscaba (FirstRun), y además como estamos en el último registro la búsqueda se debe hacer hacia arriba seleccionando el item “Up”:

Al hacer clic en Find Next afortunádamente el resultado fue bastante conciso (Grande Process Monitor!):

Específicamente, se hacía un Query o consulta a una clave en HKEY_CURRENT_USER\Software\Clasess\VirtualStore\SOFTWARE\Microsoft\Internet Explorer\MAIN\ llamada DisableFirstRunCustomize

A pesar de todo la clave tenía un resultado normal NAME NOT FOUND, y es que estaría SUCCESS si previamente se le hubiera deshabilitado ese primer arranque al Internet Explorer 9.

Pero, como para este caso no estaba totalmente seguro de qué causaba que siguiera con el comportamiento como si el asistente seguía activo, tenía que aprovechar esta referencia para pararlo!

Desde el Process Monitor hice clic derecho en la clave anterior (La que llegaba hasta MAIN) puesto que para llegar a una llave correctamente el resultado debe ser satisfactorio y seleccioné “Jump to”

En la llave de registro como veía que llamaba a DisableFirstRunCustomize que al traducirla sería algo como “Desactivar el primer arranque personalizado” la creé tal cual asignándole el valor de “1” que indica siempre una bandera de “Verdadero”, osea que se activa la llave como tal.

Para crear la clave dentro de la llave, basta con hacer clic derecho y seleccionar New > DWORD (32-bit) Value

El aspecto quedaría así:

Con esto se supone que el resultado en el registro sería satisfactorio, por lo que tendría que deshabilitarlo, lo que seguía era entonces abrir de nuevo el navegador!

Para mi fortuna, efectivamente, el Workaround funcionó y ahora sólo abría por fin una sola pestaña:

Fix:

Si alguien más experimenta este problema, dejo el registro a continuación para bajar, descomprimir y ejecutar:

Espero esto pueda servir, y los invito realmente a probar el Internet Explorer 9, para mí fantásticamente superior a sus versiones anteriores! =)

Saludos,

-Checho-

Error al abrir carpeta “Este archivo no tiene ningun programa asociado para ejecutar esta acción..”, Process Monitor y su solución

Checho — Thu, 27 Jan 2011 21:40:00 GMT

¡Hola!

En el que para mi es un formidable espacio de aprendizaje los Foros de TechNet y Answers (MSDN también por supuesto!) constantemente se producen y se siguen problemas en Windows y en general todos los productos que se vuelven muy interesantes por lo complejos y muy satisfactorios al encontrar entre todos una solución porque no sólo el que crea el hilo aprende sino que todos los que tratamos de ayudar también lo hacemos.

Hay un problema que se ha estado presentando con bastante frecuencia últimamente, y es que al intentar abrir una carpeta ubicada en cualquier directorio obtienen el siguiente mensaje de error:

“Este archivo no tiene ningun programa asociado para ejecutar esta acción. Por favor instale el programa o si lo tiene cree una asociación en el panel de control de programas predeterminados”

El problema como el planteado en el artículo pasado pasa por la asociación de archivos que tiene Windows. Este mensaje es muy similar cuando se pierde la asociación de extensiones de algún ejecutable (.exe, msi) o incluso cualquier otro tipo de archivo que reconozca el sistema operativo.

Puntualmente aquí el problema sólo se presenta abriendo carpetas y no ejecutando algun otro tipo de archivo.

Afortunadamente para mí logré reproducir el problema en un equipo y digo “afortunadamente” porque estos problemas se presentan por lo general porque Windows hace la búsqueda en el registro por la asociación de la extensión o tipo de archivo pero cuando falta o está corrupta obviamente debe informarlo.

Para saber qué está pasando entonces procedí a llamar al mejor recurso que se puede tener con estos inconvenientes, de nuevo Process Monitor!

Recordemos que esta Herramienta de Sysinternals nos ayuda a monitorear todo lo que está pasando a nivel de I/0 en disco, red, registro entre muchas otras y que por supuesto nos dan una gran mano.

Lo que hice (Todavía bastante novato con Sysinternals!) fue hacer un trace en la máquina que tenía el problema abriendo la carpeta y en una máquina donde todo estaba funcionando muy bien, posteriormente guardar el Log y empezar a comparar todas las operaciones que se estaban haciendo para saber cuál era la que invocaba la asociación a las carpetas.

Lo primero que encontré es que se hacían unas llamadas a HKCR\Directory y a varias claves internas pero los resultados tanto en el equipo con el problema (Captura derecha) como el que procedía correctamente (Captura izquierda) eran muy similares.

Seguí buscando minusiosamente descartando operaciones que podía filtrar fuera del problema hasta que encontré otra referencia a HKCR\Folder (HKEY_CLASSES_ROOT\Folder) y de nuevo a varias claves dentro de esta carpeta, así que de nuevo comparé los resultados de los dos equipos:

Mirando cada línea encontré que la mayoría de los resultados eran de nuevo similares exceptuando uno: HKCR\Folder\Shell\Open\Command

En el Equipo que estaba funcionando entregaba un resultado de SUCCESS:

Pero, en el Equipo que presentaba el error tenía como resultado NAME NOT FOUND:

Cabe aclarar que el resultado NAME NOT FOUND no siempre se refiere a un problema puesto que Windows puede intentar realizar consultas en un registro “padre” y al no tener resultados, pasa a realizar la consulta en un registro “hijo”.

Aquí por supuesto no pasaba esto ya que claramente en la máquina funcional estaba teniendo un resultado de exitoso pero en la otra no podía hacer referencia a la clave.

Decidí entonces ir hasta la llave del registro, desde Process Monitor, para esto basta con hacer clic derecho sobre la llave y seleccionar Jump to…

Como era de esperarse, en el equipo que entregaba un resultado satisfactorio la clave existía y funcionaba:

Al hacer este mismo proceso en el Equipo no funcional encontré que la clave no existía:

La solución…

Windows para el caso de abrir una carpeta, entre muchas operaciones referencia a esta clave para establecer la asociación con Windows Explorer y además para que la ventana sea mostrada en el directorio donde se está ejecutando.

Actualización:

Para solucionar el problema tenemos dos opciones:

Descargar FixAss®, una pequeña aplicación que desarrollé para reparar automáticamente la asociación de Carpetas y Directorios. Para esto descargan el archivo, descomprimen el ejecutable y lo ejecutan para recibir el cuadro de confirmación de la tarea, al cerrar el cuadro pueden revisar nuevamente la apertura de carpetas.

Lo pueden bajar desde aquí:

Descargar FixAss®

Solución manual:
Si el problema persiste pueden haber otras claves corruptas o perdidas dentro de HKCR\Folder o HKCR\Directory.

Para este caso la solución más inmediata sería exportar estas claves desde un equipo funcional y posteriormente importarlas en el equipo que tiene los problemas.

También pueden hacer si desean ustedes mismos el Trace con el Process Monitor!

Para los que puedan ver este artículo buscando solución y la anterior no la proporcionó, les dejo el enlace a mi Skydrive con las dos llaves de Registro (Folder y Directory) para que las descarguen, descompriman y ejecuten para solucionar el problema:

Espero les pueda servir y de nuevo los invito a que se den un pasón por los Foros de Microsoft TechNet y Microsoft Answers.

Saludos,

-Checho-

Mi dilema con la Asociación de iconos en Windows 7 y la gran ayuda de Process Monitor!

Checho — Tue, 18 Jan 2011 22:03:00 GMT

Hola!

Bueno, sinceramente no esperaba poder escribir este artículo puesto que pensé que no podría llegar a la solución =)

¡El dilema!

Windows 7 incluye una función que puede ser de mucha utilidad, y se trata de las Herramientas para administrar la asociación que tienen las extensiones de los programas instalados con la respectiva aplicación, básicamente para ayudarnos a decidir qué aplicaciónes utilizar a la hora de abrir algunos tipos de archivos, por ejemplo decidir que todos nuestros archivos de audio con extensión .MP3 se abran con otra aplicación diferente a Media Player.

Para acceder a los Programas Predeterminados, basta con hacer clic en el menú Inicio y seleccionar Programas Predeterminados (Default Programs):

Desde aquí podremos establecer los Programas predeterminados sea estableciendo la asociación por aplicación o por extensión entre otras herramientas para personalizar la forma en que actúa la reproducción automática entre otros:

No profundizaré en lo que se hará puesto que no es la intención del Post, pero era necesario porque desde aquí empezó lo que llamé Mi dilema.

Explorando un poco las posibilidades para arreglar la asociación de archivos desde aquí y no tener que ir al registro puesto que es un problema bastante común en los Foros de Answers tenía abierto Live Meeting, Microsoft Lync y Adobe Reader X.

Al estar estableciendo la aplicación inesperadamente el icono que se visualiza en la barra de tareas para estas tres aplicaciones cambió, ahora la visualización parecía como si hubiera perdido esa asociación (La que estaba tratando de ver cómo arreglar!):

Lo primero que hice fue por supuesto tratar de restablecer la asociación haciendo clic derecho sobre el PDF y dentro de las Propiedades clic en el botón Cambiar, y de nuevo seleccioné Adobe Reader x (De hecho ya estaba) pero el “problema” persistía.

Procedí entonces a reasociar la extensión y los iconos creando la llave de registro pero de nuevo no funcionó.

Lo extraño de todo es que las tres aplicaciones (Adobe, Lync y Live Meeting) abrían perfectamente con el programa que administrara esas extensiones, pero el icono no cambiaba, lo que me llevó a pensar que el problema estaba en la asociación del icono como tal al tipo de archivo y no de extensión al programa predeterminado.

Mientras intentaba diferentes métodos me di cuenta de que si yo Anclaba el icono a la barra de tareas y después lo Desanclaba el icono se visualizaba bien, pero al volverle a dar clic derecho de nuevo cambiaba!

Dentro de la desesperación por ver estos iconos que no correspondían, fui hasta una de las carpetas que contenían los archivos propios de la aplicación a buscar posibles respuestas.

En la de Adobe encontré el ejecutable (AcrodRd32.exe), así que lo ejecuté y también se visualizaba mal, sin embargo al hacer clic derecho sobre este y Crear un acceso directo que predeterminadamente lo lleva al Escritorio sorprendentemente al abrir cualquier PDF el icono ahora se veía como debía (Vaya cosa!).

Hasta ahí creí que todo se había solucionado, pero al quitar el acceso directo del escritorio de nuevo el icono se veía mal en la barra de tareas.

Pensé entonces que podía deberse a la Caché de los iconos (Alguna vez me pasó algo similar por este causante en Windows XP) así que fui hasta la carpeta que pertenecía a mi usuario (C:\Users\Checho\AppData\Local) y borré el archivo de base de datos que contiene el caché de los iconos IconCache.db

Con la esperanza de que esto hubiera podido funcionar reinicié el sistema pero al entrar todo seguía igual.

En este punto ya se me habían acabado las ideas para encontrar la solución al problema, obviando la restauración del sistema y la reinstalación de la aplicación que en realidad no me dirían el por qué y sólo lo arreglarían (Se hubiera perdido la gracia!).

Procedí entonces a pedir ayuda, y planteé el inconveniente en los Foros de WinTecnico que dirige Daniel Martín (MVP Windows Expert).

Por supuesto Daniel me ayudó, y además me entregó la pista que en últimas me llevó a la solución y es que en el Registro de Windows dentro de HKCR\.pdf era donde normalmente tomaba el valor para definir el icono predeterminado de la aplicación, pero casi siempre Windows lo toma del Caché que tiene por rendimiento.

El icono lo busca dentro de los componentes que tiene el acceso directo la aplicación, pero además en Windows Installer por ejemplo esta ruta cambiaba y era un poco más difícil de encontrar.

De igual forma volvimos al Caché de iconos (No estaba tan perdido), así que por recomendación de nuevo de Daniel traté de forzar la actualización de este caché cambiando la arquitectura de colores a 16 bits y volviéndolo a 32.

Pero… sin ningún resultado positivo =)

Pensé entonces que para aprovechar y empezar a darle la cara a Sysinternals podría hacer un Trace de lo que pasaba “por debajo” mientras abría alguna de las aplicaciones, así que me fui por la que ya estaba explorando Adobe Reader X.

Para esto llamaría a Process Monitor

¡La gran ayuda de Process Monitor!

Realmente recurrí a esto por última opción, puesto que aunque es el próximo reto, entender y trabajar estas herramientas creo que puede ser algo complejo acostumbrarse.

Explorando un poco los resultados de lo que pasaba en el Registro ví que efectivamente hacía consultas y trabajo con las claves que habían en HKCR\.pdf en otras como HKCU\Software\Classes y HKCR\AcroExch.Document.7

Lamentablemente no ví nada muy extraño pero pensé ¿Y si lo comparo con otro equipo que tenga la versión de Adobe Reader, Sistema Operativo y Arquitectura?

Comparé estos resultados con mi Equipo pero la verdad no variaban en casi nada, exceptuando algunas llaves más repartidas durante el Trace que se hacía.

Process Monitor me entrega entre sus miles de funciones la posibilidad de seguir directamente la entrada en el Registro de Windows y ver lo que contiene.

Para esto basta con hacer clic derecho sobre la llave que se desee seguir y seleccionar Jumpt to…

Por esto, mi segundo paso aquí fue Abrir algunas de estas entradas (Empezando por la que debía provenir el icono asociado) y compararlas con el Equipo donde todo se estaba visualizando bien.

En la primera no encontré mayor diferencia, sólo que no estaba creada la carpeta con el nombre del ejecutable “AcrodRd32.exe” en el equipo que se visualizaba mal (Una pequeña esperanza?) así que procedí a crearla y asegurarme de que en los dos estuviera exactamente igual:

La entrada en sí era: HKEY_CLASSES_ROOT\.pdf

A pesar de todo, al reiniciar el equipo nuevamente todo seguía viéndose mal…

¿Y la solución?

La segunda entrada y finalmente LA QUE ME CONDUJO A LA SOLUCIÓN fue seguir el registro de HKEY_CLASSES_ROOT\AcroExch.Document.7 en ambos equipos que contenía además una serie de carpetas dentro:

*Nota: Lo primero que traté de detallar era si había algun tipo de diferencias de nuevo en esta y las otras claves (Incluyendo sus rutas) en los dos equipos, el del problema y el del que me basaría para la solución.

Lamentablemente sin cambios.

Desconozco la función de esta estas entradas, pero me llamó mucho la atención la clave de DefaultIcon ya que según recordé de la ayuda de Daniel este determinaba la famosa ruta del icono que se visualizaría finalmente.

Abrí la clave y para mi sorpresa me encontré algo bastante interesante:

Como ven el String creado predeterminadamente “Default” entregaba una ruta que al final se refería a un archivo con extensión .ico (De icono!!):

C:\Windows\Installer\{AC76BA86-7AD7-1033-7B44-AA0000000001}\PDFFile_8.ico,0

Lo primero que me acordé es sobre el tipo de instalador (Windows Installer!) y al parecer ya me iba acercando, lo presentía! :P

Seguí entonces la ruta en los dos Equipos esperando todavía encontrar algo de qué pegarme y que pudiera ser la gran diferencia, para mi sopresa en esta carpeta oculta están todos los iconos que maneja Adobe para los tipos de archivos pero incluyendo (Lo noté de casualidad) el que se ve en la barra de tareas:

En los dos equipos (Para mi desfortuna) estaban todos exactamente iguales por lo menos en nombres e iconos que se hacían referencia dentro del Registro de Windows, pero (Para mi fortuna!) sí había una diferencia no tan notable:

En el Equipo en que se estaba visualizando mal, al ver la propiedad de cada icono encontré que su aplicación asociada y predeterminada para abrir era Microsoft Paint:

Por el contrario, en las mismas propiedades que tenía el Equipo que se visualizaba correctamente el Equipo estaba predeterminadamente el Visor de imágenes de Windows:

¡Aquí tenía que estar el problema!

En efecto, lo que hice fue darle al botón Cambiar en el Equipo que estaba predeterminadamente Paint y cambiarlo de nuevo al que debía tener que era el Visor de imágenes de Windows (Windows Photo Viewer)

Al aplicar y aceptar me lancé a la prueba (Quizás la que sería la final) y decidí abrir otra vez un documento en PDF y me encontré con la mejor sorpesa de la noche:

¡Así es! Todo se había arreglado y ahora el icono había vuelto a su visualización original, y no solo este sino que el de Lync y Office Live Meeting también retornaron al que les correspondía predeterminadamente!

Y así, gracias a molestar tanto, a Daniel Martín y al increible Process Monitor de Sysinternals descubrí qué estaba pasando y arreglé el problema que aunque mínimo me entregó buenas enseñanzas (Que siempre es lo que considero importa) y muchas ganas de explorar más a fondo Sysinternals.

Para finalizar, desconozco y quedo en deuda la razón por la que situando el acceso directo en el escritorio los iconos se visualizaban bien (Si alguien tiene la respuesta lo invito a compartirla para todos!), aunque considero que quizás al estar el acceso directo, la aplicación o el documento estaba buscando directamente en esa ruta.

Para tener en cuenta a la hora de tener problemas:

Foros Microsoft TechNet en Español

Foros Microsoft Answers en Español

WinTecnico – Daniel Martín

Windows Sysinternals – Mark Russinovich

Gracias por tomarsen el tiempo de leer y por supuesto espero si a alguien le pasa lo mismo pueda llegarle a servir!

Saludos,

-Checho-