Daniel Martín's blog : Shell

¿Cómo funciona Autorun/AutoPlay en Windows 7?

dmartin — Thu, 19 Nov 2009 22:17:00 GMT

Una de las novedades de Windows 7 con respecto a la seguridad general del sistema es que en este sistema operativo está desactivada la funcionalidad Autorun para dispositivos USB. La funcionalidad Autorun recientemente ha venido siendo usada por los autores de malware para infectar dispositivos USB y a su vez intentar engañar al usuario para que ejecute código malicioso una vez inserte el dispositivo en su máquina. Por este motivo, Microsoft hizo un anuncio durante la beta de Windows 7 diciendo que la funcionalidad Autorun estaría desactivada para dispositivos USB (http://blogs.msdn.com/e7/archive/2009/04/27/improvements-to-autoplay.aspx).

En un foro una persona preguntaba qué implicaciones tendría esto sobre las posibles personalizaciones que se aplican aprovechando la funcionalidad Autorun de los dispositivos ópticos y extraíbles, tales como cambiar el icono de la unidad y cambiar su etiqueta. Aprovechando la respuesta a esta cuestión voy a describir también en qué consisten los mecanismos Autorun y Autoplay en Windows 7.

Autorun y Autoplay son dos conceptos parecidos pero no iguales, que hay que distinguir. En esta página de la documentación de Windows 7 puede ver cuáles son las diferencias entre Autorun y Autoplay: http://windows.microsoft.com/en-us/windows-vista/Whats-the-difference-between-AutoPlay-and-autorun. Cuando el usuario inserta un DVD en la unidad, un dispositivo USB, etc., una de las primeras cosas que hace el sistema es procesar el posible fichero Autorun.inf de la raíz del dispositivo. El fichero Autorun.inf tiene una serie de opciones de configuración que permiten cambiar el icono de la unidad, su etiqueta, el programa que ejecutará automáticamente, etc. Esta lista recoge los posibles parámetros y los cambios que ha habido en Windows 7 con respecto a sistemas anteriores:

Open: Programa que se abrirá automáticamente. En Windows 7 esto solo está soportado en unidades ópticas (CD/DVD).
ShellExecute: Similar al caso de la opción Open.
Icon: Icono asignado a la unidad. Soportado en Windows 7, y sobre cualquier tipo de unidad compatible con Autorun.
Action: En Windows 7 solo se tiene en cuenta para unidades ópticas (CD/DVD).
Label: Establece una etiqueta al volumen. Soportado en Windows 7, y sobre cualquier tipo de unidad compatible con Autorun.

Así pues, Windows 7 desactiva Autorun para toda unidad que no sea de CD/DVD, excepto si se trata de los inofensivos parámetros Icon y Label.

Para optimizar el rendimiento, conforme el sistema va analizando el fichero Autorun.inf, va almacenando su información en la rama de Registro HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Explorer\MountPoints2\{CLSID}\_Autorun (donde CLSID identifica a un dispositivo particular). En Windows 7 y en el caso de dispositivos USB, tampoco se almacena esta información en el Registro, excepto si se trata de los parámetros Icon y Label, como ya se ha comentado.

Una vez analizado el fichero Autorun.inf, el sistema establece en el menú contextual de la unidad el verbo (acción) por defecto, que se mostrará al usuario en letra negrita y será lo que ocurra por defecto al hacer doble clic sobre la unidad. Nótese que esto no ocurre en Windows 7 en el caso de unidades extraíbles.

A continuación se comprueba si Autorun está habilitado o no para esa unidad en particular. Para ello se examina en la clave de Registro HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer si existiera alguna de estas directivas establecidas:

NoDriveAutorun
NoDrives
NoDriveTypeAutorun

La primera directiva desactiva Autorun para una unidad en particular; la segunda oculta la unidad en Explorador de Windows, por lo que automáticamente se desactiva la reproducción automática en la misma, y la tercera desactiva Autorun para un tipo particular de dispositivos (ópticos, USB, etc.).

Si al introducir un CD/DVD/USB en su sistema no se muestra un cuadro de reproducción automática, debería examinar en primer lugar estos tres valores de Registro, tanto en la rama HKCU, como en la HKLM. Programas como VMware Workstation aplican alguna de estas directivas para evitar que la reproducción automática interfiera con el sistema que está siendo virtualizado.

Otro de los factores que se comprueban y que influyen en que la reproducción automática esté desactivada es que haya una aplicación DirectX funcionando a pantalla completa (por ejemplo un juego) o un salvapantallas. Asimismo, hay un valor de Registro que desactiva AutoPlay y que es configurable desde la interfaz gráfica, concretamente desde Inicio, Programas predeterminados, Cambiar configuración de reproducción automática, Usar la reproducción automática para todos los medios y dispositivos. Se trata del valor DisableAutoplay de la clave HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\AutoplayHandlers. Este es otro de los valores de Registro que debería consultar si AutoPlay no funcionara correctamente.

A continuación el sistema queda a la espera de que se mantenga pulsada la tecla Shift (Mayúsculas). El significado de esta tecla en versiones anteriores de Windows era el de desactivar la reproducción automática temporalmente. En Windows Vista y Windows 7 esta tecla cambia radicalmente de significado. Sirve para que temporalmente se aplique la configuración por defecto para la reproducción automática, es decir, el usuario verá un cuadro de diálogo con las posibles acciones, incluso si hay alguna aplicación que esté desactivando la reproducción automática (más adelante se explicará cómo puede ocurrir eso).

Si el sistema detecta que la tecla Shift no está pulsada, comprueba si lo que ha ocurrido es que un programa de instalación ha pedido un CD/DVD al usuario y este lo ha introducido. En este tipo de casos conviene no mostrar el cuadro de reproducción automática al usuario. El sistema comprueba esto viendo desde dónde se está ejecutando la aplicación que hay en primer plano. Si es desde el CD/DVD o desde el directorio temporal del usuario, supone que se trata de una instalación en curso y esto automáticamente desactiva la reproducción automática.

Por último, existe la posibilidad de que la aplicación que esté ejecutándose en primer plano haya desactivado la reproducción automática. Esto es útil por ejemplo en el caso de aplicaciones multimedia, de instalación, de grabación de CD, etc. Para conseguir esto la aplicación en cuestión implementa la interfaz IQueryCancelAutoPlay, tal y como se comenta en MSDN, y se añade a la clave de Registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\AutoplayHandlers\CancelAutoplay. También puede administrar el mensaje QueryCancelAutoPlay que le envía el sistema a su ventana y decidir si quiere desactivar la reproducción automática o no. A modo de ejemplo práctico, la utilidad de grabación de imágenes ISO de Windows 7 utiliza este método para desactivar la reproducción automática de la unidad seleccionada, temporalmente.

El sistema de recolección de feedback SQM (Service Quality Metrics) de Microsoft recopila información detallada acerca de las causas por las cuales está desactivada la reproducción automática en Windows, etc., con el fin de enviarlas a Microsoft para que se estudie cómo trabajan millones de usuarios en todo el mundo y así poder mejorar el producto. Es importante comentar que la participación en este programa de feedback, que oficialmente recibe el nombre de Windows Customer Experience Improvement Program es completamente voluntaria y se puede activar desde Inicio, escribiendo CEIP en la caja de búsqueda y seleccionando el ítem de Panel de control ofrecido.

En cuanto a AutoPlay, el sistema inspecciona el contenido del medio recién insertado con el fin de presentar al usuario tareas específicas con el tipo de contenido que está tratando. En un primer momento, el sistema analiza el fichero Autorun.inf por si hubiera alguna guía acerca del contenido de ese dispositivo. El fichero Autorun.inf admite una sección como

[Content]


MusicFiles = True 
PictureFiles = False 
VideoFiles = False

que le diría al sistema que el medio contiene únicamente archivos de música, por lo que se mostrarían tareas orientadas a tratar con música. Es importante resaltar que la sección [Content] es independiente de lo que haya realmente en el medio: Si el fichero Autorun.inf dice que no hay ficheros de vídeo, la reproducción automática no mostrará tareas relacionadas con el tratamiento de vídeos, pese a que los haya en el medio. Otras dos secciones del fichero Autorun.inf que están relacionadas con Autoplay son [ExclusiveContentPaths], que contiene las rutas que debe analizar el sistema para extraer el tipo de contenido que hay en el medio, e [IgnoreContentPaths], que contiene rutas que no serán analizadas, pese a que sean subcarpetas de una ruta establecida en la sección [ExclusiveContentPaths]. Estas últimas secciones son útiles y recomendables para el caso de medios con una cantidad bastante considerable de contenido, pues el sistema se demorará recorriendo directorios que no contienen datos relevantes desde el punto de vista de la multimedia. Puede obtener más información sobre estas secciones del fichero Autorun.inf en el siguiente artículo de MSDN: http://msdn.microsoft.com/en-us/library/cc144200(VS.85).aspx.

Este artículo pretende ser un repaso general de las funcionalidades Autorun/AutoPlay de Windows 7, clarificando las dudas que hay sobre el fichero Autorun.inf en unidades USB en Windows 7, y haciendo hincapié en aquellos aspectos que pueden desactivar la reproducción automática, por si en algún momento tuviera que abordar un sistema con este problema.

Sobre el error "La operación solicitada requiere elevación" que puede devolver Runas.exe en Windows Vista/7

dmartin — Sun, 04 Oct 2009 01:32:00 GMT

En un foro que frecuento un usuario tenía el siguiente problema: Al intentar ejecutar como administrador un programa en Windows 7 usando el comando Runas.exe, le aparecía el siguiente mensaje de error:

740: La operación solicitada requiere elevación.

Ciertamente el usuario estaba proporcionando el nombre de usuario y la contraseña de un usuario con privilegios administrativos así que... ¿dónde estaría el problema?

En primer lugar, vamos a analizar con calma lo que quiere decir el mensaje de error. El mensaje de error "La operación solicitada requiere elevación" está recogido en el fichero de cabecera Ntstatus.h del SDK de Windows Vista y posteriores. Concretamente está definido con el nombre de macro ERROR_ELEVATION_REQUIRED.

¿Cuándo se devuelve ese código de error durante el funcionamiento de Windows?

En Windows los procesos se crean usando la API CreateProcess. Uno de los pasos que se siguen antes de crear un proceso en Windows Vista y posteriores es comprobar si el proceso en cuestión necesita elevar sus privilegios o no. A la hora de determinar este aspecto, entran en juego, entre otros, dos parámetros: El nivel de ejecución (runlevel) impuesto por el manifiesto de la propia aplicación, y el token del usuario que está lanzando ese programa. Existen tres posibles niveles de ejecución para una aplicación:

asInvoker: El nivel de ejecución es el mismo que el del proceso padre.
highestAvailable: El nivel de ejecución es el de mayores privilegios posibles, considerando el tipo de cuenta desde la cual se ejecuta el proceso.
requireAdministrator: El nivel de ejecución es administrativo, independientemente de las demás circunstancias.

Esta tabla recoge de forma básica las posibilidades:

Nivel de ejecución de la aplicación	Token del usuario	Requiere elevación o no
AsInvoker	Cualquiera	No
highestAvailable	Administrador "elevado"	No
highestAvailable	Administrador "estándar"	Sí
highestAvailable	Otro caso	No
requireAdministrator	Administrador "elevado"	No
requireAdministrator	Otro caso	Sí

Por administrador "elevado" me refiero a aquella cuenta con privilegios administrativos pero que, o bien ya ha elevado explícitamente sus privilegios (a través de un cuadro de UAC), o bien no tiene activada la característica Modo de aprobación del administrador (Admin Approval Mode). Esta característica se puede desactivar desde Directiva de grupo, pero yo personalmente lo desaconsejo. Un ejemplo de este tipo de cuentas es la cuenta "Administrador", creada durante la instalación del sistema operativo. Recuerde que el resto de cuentas con privilegios administrativos poseen dos tokens: uno limitado, con el que "actúan" por defecto, y otro "administrativo", que pueden aplicar si el usuario así lo indica a través de un cuadro de UAC.

Una vez que CreateProcess falla (devuelve un valor distinto de 1) y el último error se establece como ERROR_ELEVATION_REQUIRED (columna "Requiere elevación o no" de la tabla anterior), es asunto del proceso padre el tratar convenientemente este error. Si no lo hace, se registrará en Visor de sucesos, apartado dedicado a UAC, un evento informando de que el proceso padre no trató apropiadamente el error ERROR_ELEVATION_REQUIRED.

¿Qué ocurre cuando se lanza una aplicación desde la línea de comandos?

Imaginemos que el usuario intenta ejecutar el desfragmentador de disco de Windows 7 usando para ello una sintaxis de Runas.exe como esta:

runas /u:UsuarioAdministrador dfrgui.exe

Básicamente la línea de comandos detecta que no se trata de un comando interno, sino que se trata del programa Runas.exe, y por tanto se dispone a ejecutarlo usando CreateProcess. Como Runas.exe no es un programa que está marcado para requerir elevación de privilegios, CreateProcess retorna éxito.

Una vez que el planificador del sistema operativo cede el control al proceso Runas.exe recién creado, este se dispone a analizar su línea de comandos. Se encuentra con una petición de ejecutar Dfrgui.exe como si fuera el usuario administrador pasado como parámetro. Sin embargo, Runas.exe es poco más que un "envoltorio" de la API CreateProcessWithLogonW, que a su vez es poco más que un envoltorio de la API CreateProcess, pero pasando otro perfil de usuario distinto como parámetro.

Durante su ejecución, CreateProcess determina que Dfrgui.exe requiere privilegios administrativos (puesto que así se lo indica su manifiesto), y por ello devuelve falso y establace el último error como ERROR_ELEVATION_REQUIRED. Como Runas.exe es una herramienta que no está diseñada para tratar apropiadamente ese error, simplemente lo devuelve por pantalla de la forma "740: La operación solicitada requiere elevación".

Una vez desvelado el misterio, resta por comentar un aspecto que a estas alturas quizá ya se haya planteado:

¿Cómo es posible que ejecutando Dfrgui.exe desde la línea de comandos -sin usar Runas.exe- sí que aparezca un cuadro de UAC?

El secreto está en que la línea de comandos, antes de llamar a CreateProcess, informa al sistema de que va a tratar los posibles ERROR_ELEVATION_REQUIRED que puedan surgir. Esto lo consigue estableciendo unos atributos no documentados a la estructura STARTUPINFOEX, que se pasa como parámetro a la familia de API CreateProcess. Esto hace que no se registre el correspondiente error en el apartado UAC del Visor de sucesos. Seguidamente, la línea de comandos, sabiendo que se trata de un programa que debe elevar sus privilegios, lo intenta ejecutar mediante la API ShellExecuteEx. Esta API sí muestra el correspondiente cuadro de UAC, así que es la vía apropiada para ejecutar una aplicación que requiera privilegios administrativos.

En resumen, me gustaría resaltar estos puntos del tema del artículo:

En Windows Vista y Windows 7 la única forma de ejecutar algo con privilegios administrativos es mediante un cuadro de UAC. No vale con poner el nombre de usuario y la contraseña de un administrador en la línea de comandos.
Todo lo que se ejecute mediante la API CreateProcess, o alguna derivada de ella, no hará que aparezca un cuadro de UAC. Un ejemplo de ello es la utilidad Runas.exe.
Runas.exe, en Windows Vista/7, sirve para ejecutar una aplicación como si fuera otro usuario, pero no sirve para ejecutarla con mayores privilegios.
Si quiere que se ejecute una aplicación que requiere privilegios administrativos, use la API ShellExecuteEx, o alguna de sus derivadas. Esta API sí permite la aparición de un cuadro de UAC para que el usuario eleve sus privilegios.

Sobre la nueva sintaxis del Panel de control en Windows Vista/Windows 7

dmartin — Fri, 11 Sep 2009 23:42:00 GMT

Quizá ya se haya dado cuenta de que en Windows Vista/Windows 7 algunos módulos del Panel de control que anteriormente estaban implementados en la clásica forma de un fichero .cpl ahora lo están en la forma de un fichero ejecutable (.exe). El motivo de este cambio es que con la introducción de Control de cuentas de usuario (UAC), se da el caso de que algunos de estos módulos requieren privilegios administrativos para ejecutarse. Veámoslo con un ejemplo:

El ejecutable DPIScaling.exe del directorio \Windows\System32 implementa la opción del Panel de control que permite cambiar la escala DPI del sistema. Este módulo requiere privilegios administrativos para ejecutarse, como así indica su fichero de manifiesto. Para verlo prácticamente, descargue Strings desde http://technet.microsoft.com/en-us/sysinternals/bb897439.aspx y abra una ventana de línea de comandos en el directorio donde la ha extraído. Introduzca este comando y pulse INTRO:

strings %SystemRoot%\System32\DPIScaling.exe | findstr /i requireAdministrator

La salida del comando, level="requireAdministrator", nos indica que el ejecutable en cuestión requerirá privilegios administrativos cuando lo invoquemos. Otros posibles valores para el atributo level son:

asInvoker: El ejecutable no requerirá privilegios administrativos.

highestAvailable: El ejecutable se ejecutará con los máximos privilegios que le permita la cuenta de usuario desde la que ha sido invocado.

Nombres canónicos en Windows Vista/Windows 7

Esta reestructuración de buena parte de los elementos del Panel de control trajo consigo una de las novedades que se introdujeron en Windows Vista y que se han mantenido en Windows 7: la posibilidad de abrir elementos del Panel de control usando un nombre canónico. Un nombre canónico es un nombre en inglés, no traducible, que describe de manera cercana al usuario el cometido de ese elemento del Panel de control. Esto evita que el usuario tenga que aprender el nombre de ficheros .cpl, muchas veces crípticos, y además permite separar el nombre del ítem de su implementación, ya sea en un clásico fichero .cpl o, ya sea en un fichero .dll o .exe.

Por ejemplo, para abrir el panel Agregar o quitar programas de Windows Vista/Windows 7, se puede usar esta sintaxis:

%windir%\system32\control.exe /name Microsoft.ProgramsAndFeatures

¿De dónde proviene ese nombre canónico, Microsoft.ProgramsAndFeatures?

Cuando el ejecutable Control.exe recibe el parámetro /name seguido de un nombre canónico, se invoca a la función IOpenControlPanel::Open, la cual en primer lugar busca el elemento correspondiente del Panel de control al que se está haciendo referencia. Cabe destacar que el Panel de control es un directorio virtual (no reside físicamente en el disco, sino que está implementado por el shell), situado en la clave de Registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ControlPanel\NameSpace. El valor (Predeterminado) de cada una de las subclaves de esa rama de Registro contiene el nombre con el que se mostrará en Panel de control (no el nombre canónico). Para encontrar la implementación de, digamos, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ControlPanel\NameSpace\{0DF44EAA-FF21-4412-828E-260A8728E7F1} (ítem de las propiedades de la barra de tareas y menú Inicio), se accede a la clave de registro HKEY_CLASSES_ROOT\CLSID\{0DF44EAA-FF21-4412-828E-260A8728E7F1}, en la cual existe un valor de registro de nombre System.ApplicationName y cuyo contenido es el nombre canónico: Microsoft.TaskbarAndStartMenu. Así pues, para abrir las propiedades de la barra de tareas y del menú Inicio ya sabemos que bastaría con ejecutar lo siguiente:

%windir%\system32\control.exe /name Microsoft.TaskbarAndStartMenu

Para ver qué es lo que realmente se ejecuta, eche un vistazo a la clave HKEY_CLASSES_ROOT\CLSID\{0DF44EAA-FF21-4412-828E-260A8728E7F1}\Shell\Open\Command.

Cada ítem del Panel de control puede implementar varias páginas

Podemos entender las páginas como subsecciones específicas del ítem del Panel de control. Para indicar una, debe usarse la sintaxis

%windir%\system32\control.exe /name Nombre_canónico /page Página

Veámoslo con un ejemplo:

Con los conocimientos que hemos adquirido, nos resulta sencillo determinar que el ítem Personalizar del Panel de control está implementado en la DLL Themecpl.dll. Es en esta DLL donde encontraremos información acerca de las posibles páginas de este ítem, en la forma, como no, de fichero XML.

Esta vez usaremos la aplicación gráfica Resource Hacker, que puede descargar gratuitamente desde http://www.angusj.com/resourcehacker/. Al abrir el fichero Themecpl.dll en esta aplicación, nos encontramos con dos ficheros XML adicionales al típico fichero de manifiesto (.manifest) que habíamos visto hasta ahora.

Este primer fichero XML especifica una serie de tareas que puede realizar el elemento del Panel de control "Personalizar". Estas tareas (cambiar los colores, el fondo de pantalla, etc.) se muestran como enlaces de texto justo debajo del elemento del Panel de control (suponiendo que esté configurado en la vista por categorías). Y lo que es más importante, estas tareas son indizables por el sistema de búsqueda de Windows Vista. Puede obtener más información en este artículo de MSDN: http://msdn.microsoft.com/en-us/library/bb776840(VS.85).aspx.

Esta segunda imagen hace referencia al segundo fichero XML, que es el que contiene la información acerca de cada una de las páginas que implementa este ítem del Panel de control. Entre las etiquetas <pagedefinition></pagedefinition> nos encontramos con una etiqueta <properties>, que hace referencia a cada una de las páginas. El atributo canonicalName nos ofrece su nombre canónico.

Como vemos, el ítem "Personalizar" del Panel de control admite como sintaxis:

%windir%\system32\control.exe /name Microsoft.Personalization /page pageColorization (para cambiar la configuración de color)

%windir%\system32\control.exe /name Microsoft.Personalization /page pageWallpaper (para cambiar el fondo de escritorio)

Ejercicio

Ahora que ya sabe cómo escudriñar en los ítems del Panel de control con el fin de construir accesos directos lo más directos posibles (valga la redundancia), le propongo como ejercicio que en un sistema Windows 7 averigüe la sintaxis para un acceso directo al Monitor de confiabilidad, que como sabe en Windows 7 está algo escondido dentro del Centro de actividades (Action Center).

Si se rinde, puede ver la solución seleccionando texto a partir de aquí: control.exe /name Microsoft.ActionCenter /page pageReliabilityView

Descubrir valores de Registro no documentados usando Process Monitor

dmartin — Sun, 16 Aug 2009 23:01:00 GMT

A mucha gente le gusta personalizar su sistema de escritorio al máximo posible. Por ello, Microsoft acostumbra a incorporar en sus sistemas operativos bastantes menús y cuadros de diálogo capaces de personalizar muchos de los detalles de funcionamiento de Windows. Sin embargo, hay ciertos detalles que no son modificables desde la interfaz gráfica, solamente desde el Registro; siempre siguiendo los pasos de algún artículo de la documentación oficial de Microsoft (KB, MSDN LIbrary, Technet Library, etc.). También hay detalles que no están documentados pero que pueden "descubrirse" utilizando herramientas de monitoreo del Registro, como Process Monitor, tal y como se explica en este artículo.

En el caso que nos ocupa, el usuario quería modificar el tiempo de aparición de la vista en miniatura de una aplicación en la barra de tareas de Windows Vista. En Windows Vista, la funcionalidad Windows Aero permite ver, a golpe de ratón, el contenido de todas y cada una de las ventanas minimizadas en la barra de tareas. El usuario intentaba buscar una forma de acortar ese tiempo de aparición de la vista en miniatura, pues le parecía excesivo. En Internet la alternativa que es más popular es la de modificar el valor de Registro MouseHoverTime de la clave de Registro HKEY_CURRENT_USER\Control Panel\Mouse. Sin embargo, este valor influye en el tiempo que tarda en reconocerse un posicionamiento del cursor del ratón, en cualquier parte de la interfaz gráfica de Windows. Era necesario buscar algún valor de Registro más específico, y para ello iba a recurrir a Process Monitor.

Antes de nada hay que comentar que no tenía la garantía de que existiera un valor de Registro que controlara ese aspecto tan específico de la interfaz gráfica de Windows. De existir, suelen ser parámetros que solo se tienen en cuenta en las versiones de depuración (checked) del sistema operativo. De todas formas, abrí Process Monitor y establecí un filtro de aquellos eventos de Registro que contuvieran en su ruta la palabra "Thumbnail". Inicié Explorer.exe y rápidamente me encontré con tres eventos bastante interesantes:

El primer evento indica el momento en que Explorer.exe examina una directiva, TaskbarNoThumbnail, configurable desde Directiva de grupo, encargada de desactivar las vistas en miniatura de la barra de tareas. La lectura de este valor me hizo pensar que los dos valores siguientes podrían estar relacionados con lo que buscaba.

Esos dos eventos siguientes hacen referencia a una búsqueda de cierta rama en el Registro (ExplorerThumbnails), tanto en la rama HKEY_CURRENT_USER como en la rama HKEY_LOCAL_MACHINE. El primer evento hace referencia al SID de mi usuario dentro de la rama HKEY_USERS (HKU) simplemente porque ejecuté Process Monitor desde una cuenta limitada, proporcionando obviamente el nombre de usuario y contraseña del administrador.

¿Qué sería esa rama ExplorerThumbnails? La verdad es que no encontré nada documentado en Internet, pero su nombre era lo suficientemente atractivo como para seguir indagando. Una de las cosas que suelo hacer en casos como este es crear la clave que busca en este caso Explorer.exe y ver qué valores o subclaves de Registro busca a continuación. Eso hice: Abrí Editor del Registro y creé la clave de Registro ExplorerThumbnails. Volví a capturar una traza con Process Monitor y el resultado ofreció otros tres valores tan interesantes como desconocidos:

Los valores InitialThumbnail, InitialTooltip y AutoPopTooltip me hacían pensar que efectivamente estaban relacionados con lo que realmente buscaba: Modificar el tiempo de aparición de la vista en miniatura. En este caso podría haber experimentado introduciendo algunos valores aleatorios para esos valores de Registro y observar los resultados, aunque en este caso recurrí a una lectura del código fuente de Explorer.

Al parecer, el valor InitialThumbnail tiene que ver con el tiempo en milisegundos que tarda en aparecer la vista en miniatura desde que se sitúa el cursor del ratón en la aplicación minimizada en la barra de tareas; InitialTooltip influye en el tiempo de aparición del texto emergente que siempre aparece encima de la vista en miniatura, un tiempo después. Por último, AutoPopTooltip influye en el tiempo que tarda en desaparecer el texto emergente. Por defecto, si no se encuentran esos valores en el Registro, el sistema supone, respectivamente, 500, 1000 y 5000 milisegundos.

Para concluir, codifiqué una aplicación gráfica que facilitara la modificación de estos valores en el Registro: http://winvista.mvps.org/Ficheros/TweakThumbnails.zip

Ya conoce otro posible uso de Process Monitor: Intentar descubrir valores de Registro (o ficheros) no documentados pero que pueden permitirnos configurar aspectos más o menos interesantes del sistema operativo.

Nota: Como indico en el margen izquierdo de este blog, toda la información que no está documentada por Microsoft es muy susceptible de cambiar e incluso de desaparecer en versiones posteriores de Windows. Este es el caso particular de esta rama del Registro, pues no es tenida en cuenta en Windows 7. Adicionalmente, deberá tomar las medidas oportunas si aplica este tip en un entorno de producción, pues de seguro se trata de un parámetro que no está tan probado como el resto de personalizaciones conocidas en el sistema operativo.

Sobre el atributo de sólo lectura aplicado a carpetas

dmartin — Tue, 02 Jun 2009 13:21:00 GMT

Si se hiciera un listado con las consultas más frecuentes en los foros de Windows, seguro que esta ocuparía una posición bastante destacada: ¿Por qué no puedo cambiar el atributo de solo lectura a una carpeta de mi sistema?

Pese a que Microsoft dispone de un artículo al respecto (KB326549), considero que mucha gente aún tiene dudas sobre este tema y por eso me he decidido a escribir este artículo.

Si un usuario hace clic con el botón derecho sobre una carpeta de su sistema y selecciona Propiedades, le aparecerá un cuadro de diálogo similar al siguiente (en un sistema XP):

Como puede observar en la imagen, la casilla Sólo lectura tiene un aspecto particular: No está marcada, pues no aparece la típica marca de verificación en el cuadrado blanco, ni tampoco está desmarcada, pues el color del cuadrado no es blanco sino verdoso. ¿Qué significa esto? Esa casilla es una casilla de tipo triestado; es decir, hay tres posibles estados para esa casilla: Marcada, desmarcada e indeterminada, que es el caso que nos ocupa. Si hace clic varias veces sobre la casilla Sólo lectura podrá ver que va cambiando el estado de la misma. Sin embargo, pese a dejar la casilla en estado marcado y pulsar Aceptar, al volver a abrir las propiedades de la carpeta la casilla vuelve al estado indeterminado.

¿Cuál es la causa de esto?

La causa de este comportamiento es que el atributo de sólo lectura no se puede cambiar, para carpetas, desde la interfaz de Windows. Microsoft tomó esta decisión porque el atributo de sólo lectura aplicado a carpetas tiene una semántica que nada tiene que ver con la del atributo de sólo lectura aplicado a ficheros. El atributo de sólo lectura aplicado a carpetas únicamente quiere decir que la carpeta es una carpeta personalizada (con un icono distintivo, con un fondo, etc.).

Debe quedar claro que el atributo de sólo lectura aplicado a una carpeta no quiere decir que la carpeta no se pueda eliminar o cosas por el estilo.

¿Para qué está la casilla Sólo lectura en las propiedades de una carpeta?

Está presente porque puede aplicarse a los ficheros que contenga esa carpeta. Si desmarca la casilla Sólo lectura en las propiedades de una carpeta y pulsa Aceptar, lo que ocurre es que se quita el atributo de sólo lectura a todos los ficheros que contenga esa carpeta, si es que contiene alguno. De igual forma, si establece el estado de la casilla como marcado (con una marca de verificación en el cuadrado blanco) y pulsa Aceptar, todos los ficheros de esa carpeta pasarán a tomar el atributo de sólo lectura.

Entonces, ¿cómo cambiar el atributo de sólo lectura a una carpeta?

Como ha podido ver, Explorador de Windows no permite que el usuario cambie el atributo de sólo lectura a una carpeta. Esto se debe a que Microsoft no quiere que los usuarios "jueguen" con este atributo, lo que podría suponer que se perdieran las personalizaciones de algunas carpetas del equipo, incluidas algunas carpetas de sistema importantes para Windows. Así pues, si un usuario quiere "jugar" con el atributo de sólo lectura aplicado a una carpeta, debe hacerlo desde la línea de comandos usando el comando Attrib.exe de un modo similar al siguiente:

attrib +r <Ruta_carpeta>

Esto aplicaría el atributo de sólo lectura a la carpeta indicada por <Ruta_carpeta>

Similarmente, el comando

attrib -r <Ruta_carpeta>

desactivaría este atributo.

Espero que este artículo sirva para aclarar de manera definitiva en qué consiste exactamente el atributo de sólo lectura cuando se aplica a una carpeta, por qué Explorador de Windows siempre muestra la casilla correspondiente como indeterminada, y qué ocurre cuando el usuario deja esa casilla en estado marcado o en estado desmarcado y pulsa sobre Aceptar.

"MMC no puede abrir el archivo". Cómo analizar el error

dmartin — Sun, 03 May 2009 14:28:00 GMT

Un problema que le ocurre a no poca gente que usa Windows XP consiste en que al intentar abrir un fichero con extensión MSC (Services.msc, Diskmgmt.msc, etc.) el sistema muestra el siguiente mensaje de error:

MMC no puede abrir el archivo C:\WINDOWS\system32\services.msc.


Puede ser que el archivo no exista, no sea una consola de MMC o fue creado por una versión más reciente de MMC. También puede ser que no tiene suficientes derechos de acceso para abrir el archivo.

El propio mensaje nos explica las posibles causas del problema, pero ciertamente la información que ofrece es algo vaga e inespecífica. El principal problema con el que se encuentra el usuario al recibir este mensaje de error es que, al tratarse de un mensaje de error genérico, es posible que la causa del problema que está experimentando no quede recogida en el texto del mensaje de error.

¿Cómo actuar en casos como este?

Hay muchas formas de actuar ante un mensaje de error de este estilo. Una manera consiste en observar si hay algún tipo de LOG que registre información detallada sobre el error (lo primero que debemos buscar es el código de error exacto). Es bastante probable que, de existir la posibilidad de registrar en un fichero LOG la información correspondiente a un mensaje de error, esta opción deba activarse explícitamente a través del registro del sistema operativo, o mediante algún otro método avanzado similar. En ocasiones, como último recurso para obtener información detallada sobre un mensaje de error tendremos que instalar una versión de depuración del sistema operativo o aplicación (versión checked). Las versiones checked son versiones que incorporan información detallada de depuración (trazas, aserciones, etc.) que son de mucha utilidad a los programadores de aplicaciones. De hecho, para adquirir la versión checked de un sistema operativo de Microsoft debe ser suscriptor de MSDN. Las versiones de depuración de los Service Packs sí están disponibles públicamente desde el Centro de descargas de Microsoft. Por ejemplo, este es el enlace para descargar la versión de depuración del SP3 de Windows XP.

En este artículo se va a describir un método menos complicado que puede sacarnos del atolladero en bastantes casos. De hecho, nos va a sacar del atolladero en el problema concreto que se describe más arriba.

En primer lugar, instale la última versión de Debugging Tools for Windows y configure el depurador Windbg apropiadamente. Para saber cómo hacer esto, siga los pasos de este tutorial.

A continuación, vamos a ejecutar la aplicación desde dentro del depurador. Para ello, haga clic sobre File, Open Executable. En la caja de texto Nombre, escriba lo siguiente: %SystemRoot%\system32\mmc.exe En la caja de texto Arguments, escriba lo siguiente: Services.msc (o el nombre del fichero MSC que no es capaz de abrir). Pulse Abrir.

Asegúrese de que Windbg le informe de que la información sobre los símbolos es correcta y pulse F5 (Go).

Cuando se muestre el mensaje de error en pantalla, active la ventana de Windbg y pulse Ctrl+Pausa o haga clic sobre Debug, Break.

Ahora tendrá que examinar la pila de ejecución de todos y cada uno de los hilos activos de la aplicación para ver si encuentra el código de error como parámetro de alguna de las funciones que allí aparezcan. Para cambiar de hilo, puede hacerlo gráficamente desde el menú View, Processes and Threads. Seleccione con un simple clic el hilo que quiera examinar (quedará marcado en negrita) e introduzca en la caja de texto de Windbg el comando kb para mostrar la pila de ejecución. En mi caso, esta es la pila de ejecución del hilo responsable de abrir el fichero MSC:

0:000> kb ChildEBP RetAddr Args to Child 0007f030 7c91df4a 7c809590 00000002 0007f05c ntdll!KiFastSystemCallRet 0007f034 7c809590 00000002 0007f05c 00000001 ntdll!ZwWaitForMultipleObjects+0xc 0007f0d0 7e3995f9 00000002 0007f0f8 00000000 kernel32!WaitForMultipleObjectsEx+0x12c 0007f12c 6c6d4b52 00000001 0007f160 ffffffff USER32!RealMsgWaitForMultipleObjectsEx+0x13e 0007f14c 6c6d4cbd 000024ff ffffffff 00000000 DUSER!CoreSC::Wait+0x3a 0007f170 6c6d4eb9 000024ff 00000000 0007f19c DUSER!CoreSC::WaitMessage+0x40 0007f180 7e3d8e33 000024ff 00000000 00000064 DUSER!MphWaitMessageEx+0x22 0007f19c 7c91e473 0007f1ac 00000008 000024ff USER32!__ClientWaitMessageExMPH+0x1e 0007f1b0 7e399418 7e3a770a 00000000 00000000 ntdll!KiUserCallbackDispatcher+0x13 0007f1e8 7e3a49c4 000301b4 00000000 00000001 USER32!NtUserWaitMessage+0xc 0007f210 7e3ba956 7e390000 000c44f8 00000000 USER32!InternalDialogBox+0xd0 0007f4d0 7e3ba2bc 0007f62c 00000001 00000000 USER32!SoftModalMessageBox+0x938 0007f620 7e3e63fd 0007f62c 00000028 00000000 USER32!MessageBoxWorker+0x2ba 0007f678 7e3d0853 00000000 00e76008 00bafeb0 USER32!MessageBoxTimeoutW+0x7a 0007f698 7e3e6579 00000000 00e76008 00bafeb0 USER32!MessageBoxExW+0x1b 0007f6b4 4754f5fe 00000000 00e76008 00bafeb0 USER32!MessageBoxW+0x45 0007f6f0 0107a216 00e76008 00002010 00e86458 mmcbase!MMCErrorBox+0x7f 0007f740 01058ce9 00000003 80040154 00000000 mmc!DisplayFileOpenError+0x191 0007f794 0104093c 0007f748 00000004 00e6e018 mmc!CAMCDoc::OnOpenDocument+0x90 0007f7e0 5f81424a 0007fc14 00000001 00038988 mmc!CAMCMultiDocTemplate::OpenDocumentFile+0x21f

Marcada en negrita está la parte importante de la traza, el error en cuestión (0x80040154). ¿Qué quiere decir ese código de error? El propio Windbg nos lo puede decir:

0:001> !error 80040154 Error code: (HRESULT) 0x80040154 (2147746132) - Clase no registrada

Un error de clase no registrada. Para sabér qué clase es la afectada, puede usar Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx), monitorizar el sistema mientras intenta volver a abrir el archivo MSC y analizar con calma los resultados NOT FOUND que hagan referencia al Registro del sistema, o bien puede seguir las pautas de este artículo referido a Explorer.exe.

Para no hacerle perder el tiempo, le diré que en este caso la clase afectada está en la librería Msxml3.dll y se puede volver a registrar con el comando regsvr32 msxml3.dll.

Otro código de error que se puede encontrar es el código 0x2 (archivo no encontrado). En este caso lo ideal es hacer uso de Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx), monitorizar el sistema mientras intenta volver a abrir el archivo MSC y analizar con calma los resultados NOT FOUND que hagan referencia, en esta ocasión, al sistema de archivos. Un caso que he analizado tenía como culpable al virus Vundo, aunque en general podría tratarse de cualquier otro tipo de malware.

Una duda que quizá tenga es, ¿cómo distinguir en la salida del comando kb lo que es un código de error de lo que no? En general yo suelo descartar en primer lugar lo que seguro sé que no es un código de error. Por ejemplo, en la traza de pila del ejemplo puede ver que 7e3a770a es un valor que está cerca de las direcciones de retorno de cada una de las funciones, por lo que probablemente no sea un código de error. Los valores 00bafeb0 y similares, es decir, un número hexadecimal no muy alto, suelen ser punteros a estructuras de datos, por lo que tampoco suelen ser códigos de error. Los valores muy bajos (00000002), o que comiencen por 8 (80040154), sí suelen ser códigos de error. Por supuesto, en este caso el nombre de la función mmc!DisplayFileOpenError+0x191, nos da la pista fundamental.

Espero que este artículo les ayude a investigar a fondo los mensajes de error en Windows en los que no aparece de manera explícita el código de error. En futuros artículos verá cómo atacar un problema similar pero esta vez causado por una excepción de aplicación, o bien por una versión incompatible de una DLL en el sistema, usando para ello la aplicación Dependency Walker.

Nuevo artículo sobre el proceso Explorer.exe

dmartin — Sat, 11 Apr 2009 02:26:00 GMT

He añadido a mi página web un artículo que explica lo que ocurre cuando se ejecuta el comando Explorer.exe tanto sin parámetros como con parámetros, en sistemas XP y Vista. Se incluye toda la casuística, lista completa de parámetros soportados, cómo forzar la creación de un nuevo proceso, etc. El artículo lo puede leer en la dirección http://winvista.mvps.org/Tema.aspx?ID=233

Cualquier duda o sugerencia la puede hacer llegar a través de la sección de comentarios de esta entrada o mediante el enlace Contact de la parte izquierda del blog.

¿Cómo agrupar de manera lógica el contenido de una carpeta?

dmartin — Fri, 05 Dec 2008 22:50:00 GMT

El artículo de hoy trata de una consulta bastante interesante sobre Windows XP que he recibido. En resumen, el usuario preguntaba si es posible organizar el contenido de una carpeta usando apartados, de manera similar a como está organizado por defecto Mi PC. En este artículo describo algunas alternativas para lograr esto.

La opción para organizar el contenido de una carpeta en apartados está presente en el menú Ver, Organizar iconos, Organizar en grupos. El criterio que se emplee para agrupar se establece también desde dicho submenú y puede incluir el nombre, el tipo, el tamaño total, etc. Cabe destacar que existe una serie de parámetros adicionales en el menú Ver, Seleccionar detalles. Simplemente marque las casillas correspondientes a los parámetros que desee añadir y ya estarán disponibles para ser seleccionados desde el submenú Organizar iconos.

Quizá el atributo más flexible sea el atributo Comentarios, que permite añadir un texto emergente a una carpeta. ¿Cómo se añade dicho texto? Debe crear (o modificar) un fichero oculto y de sistema con el nombre Desktop.ini que tenga, como mínimo, este contenido:

[.ShellClassInfo] InfoTip=Mi comentario

Para que Explorador de Windows tenga en cuenta esta personalización, la carpeta debe tener aplicado el atributo de solo lectura (o de sistema). El comando Attrib.exe logra esto a través de las sintaxis, respectivamente:

attrib +r NombreCarpeta

attrib +s NombreCarpeta

¿Qué ocurre si ninguna de las opciones del cuadro Seleccionar detalles nos convence? Es posible que queramos añadir información relativa a la propia carpeta, como su tamaño, por ejemplo. Para ello podemos crear una extensión de shell, concretamente del tipo column handler (manejador de columna). Windows no incluye ninguna columna que muestre el tamaño de una carpeta, ya que dicho cómputo es una tarea costosa, sobre todo si la carpeta reside en un servidor remoto. Sin embargo, sí existen en la red manejadores de columnas de terceros, por lo que en principio sería posible agrupar carpetas según su tamaño. Una de estas herramientas es Folder Size for Windows.

Si se animara a desarrollar manejadores de columnas, le recomiendo echar un vistazo a la documentación presente en el sitio web de MSDN: Creating Column Handlers.

Problemas con la inicialización de Explorer.exe (II)

dmartin — Wed, 17 Sep 2008 21:07:00 GMT

Completando mi artículo anterior sobre problemas durante la inicialización de Explorer.exe, este artículo se centrará en otra posible causa del problema: una infección de virus.

Es posible que se encuentre con un sistema con los siguientes síntomas: Al iniciar el sistema, no aparece ni el escritorio ni la barra de tareas. Al abrir Administrador de tareas, hacer clic sobre Archivo, Nueva tarea y tratar de ejecutar Explorer.exe no ocurre nada, al menos aparentemente. Digo aparentemente porque es posible que un virus haya modificado el registro de tal forma que al intentar ejecutar Explorer.exe se esté ejecutando un componente malicioso del virus. Este artículo tratará una posible vía de infección.

La clave de registro Image File Execution Options

En mi anterior blog tengo algo de información sobre los pasos que realiza la función CreateProcess antes de "dar a luz" al correspondiente proceso hijo en Windows NT. En dicho artículo me centré únicamente en la parte que tiene que ver con la compatibilidad con sistemas anteriores mediante la aplicación de shims. En Windows Vista la creación de procesos ha variado de manera muy considerable con respecto a Windows XP. Si le interesa saber los detalles sobre esto, reserve una copia de la quinta edición del libro "Windows Internals", donde se explican éste y otros aspectos.

En Windows existe la posibilidad de ejecutar un proceso directamente en un depurador, y una de las formas de conseguir esto es mediante la clave de Registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options. Dicha clave puede contener una subclave con el mismo nombre que el proceso que quiere depurar y, dentro de ésta, un valor alfanumérico Debugger que indique qué depurador se quiere utilizar. Dos usos prácticos de esta clave de Registro son:

Depurar procesos críticos del sistema operativo, como Lsass.exe o Winlogon.exe. Para ello lo que se suele hacer es agregar la clave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Winlogon.exe y, dentro de ella, crear un valor alfanumérico de nombre Debugger cuyo contenido sea por ejemplo "C:\Depuradores\ntsd.exe -d -g -G" Con esto, cada vez que el sistema ejecute Winlogon.exe vamos a añadir el depurador NT Symbolic Debugger, Ntsd. (La última versión está disponible en el paquete Debugging Tools for Windows).
Process Explorer emplea esta clave de registro cuando se hace uso de la opción que permite reemplazar Administrador de tareas por Process Explorer (algo bastante recomendable, por cierto). Así logra que cuando el sistema trate de ejecutar Taskmgr.exe (el ejecutable de Administrador de tareas), Process Explorer se ejecute en su lugar.

El software malicioso también hace uso de esta clave

Los autores de software malicioso pronto se dieron cuenta de las enormes posibilidades que ofrece esta clave de Registro y comenzaron a crear código malicioso que se agregara a dicha clave con nombres de ejecutables legítimos del sistema operativo, como el caso de Explorer.exe que nos ocupa. En concreto, un usuario afectado tenía en su sistema la clave de Registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Explorer, y dentro de ella, un valor Debugger con contenido "C:\Archivos de programa\Microsoft Common\Wuauclt.exe". Lo que se consigue con esto es que, cada vez que o bien el usuario o el sistema intente ejecutar Explorer.exe (algo que ocurre naturalmente durante el inicio de sesión), acabe ejecutándose ese tal ejecutable C:\Archivos de programa\Microsoft Common\wuauclt.exe, que es un troyano. Por la información que he recabado de diversas empresas de seguridad, parece formar parte de los últimamente tan populares virus del tipo "Autorun", es decir, los que infectan unidades USB y agregan ficheros ocultos Autorun.inf que apuntan a código malicioso. La documentación que he encontrado indica también que hay variantes rootkit de este tipo de virus.

Cómo solucionar el problema

La solución en este caso consiste en pasar primero un antivirus actualizado al sistema. De todas formas, la desinfección raramente es completa tras el análisis de un único antivirus. Bien porque sus firmas no son capaces de detectar el virus (ningún antivirus es efectivo al 100%), bien porque el entorno infectado impide la actuación correcta del antivirus. En estos casos se puede probar con otro antivirus (una segunda opinión), o bien abordar una desinfección manual. No comentaré en detalle los detalles de una desinfección manual entre otros motivos porque no soy experto en la eliminación de malware y además cada malware emplea sus trucos para pasar desapercibido de cara al usuario. Mi recomendación en estos casos es hacer uso de las herramientas Autoruns y Process Explorer iniciando el sistema en Modo seguro.

Prevención

Las infecciones de virus se aprovechan en gran medida de los privilegios del usuario infectado. En la mayoría de casos, al menos en sistemas XP, estos privilegios son administrativos, por lo que los daños pueden ser catastróficos. Mis recomendaciones para evitar este tipo de infecciones son las ya conocidas:

Utilizar una cuenta de usuario limitado para el trabajo cotidiano con el PC.
Mantener actualizado el sistema operativo desde Windows Update.
Activar un antivirus y un cortafuegos y mantenerlos al día.
Desconfiar del software que provenga de fuentes no oficiales.

Resumen

Dejo finalmente un resumen con los posibles problemas de inicialización de Explorer.exe. Recuerde los síntomas: El sistema llega a la pantalla de bienvenida o de inicio de sesión pero, una vez el usuario se ha autenticado correctamente, solo se muestra un escritorio vacío, sin iconos, sin barra de tareas.

Si al iniciar manualmente Explorer.exe desde Administrador de tareas (Ctrl+Alt+Supr, menú Archivo, Nueva tarea) todo funciona correctamente

Causa 1: Virus. Leer este artículo.

Si al iniciar manualmente Explorer.exe desde Administrador de tareas (Ctrl+Alt+Supr, menú Archivo, Nueva tarea) sigue fallando

Causa 1: Virus. Leer este mismo artículo para intentar localizar dónde está el componente malicioso que está interfiriendo con la carga del proceso Explorer.exe
Causa 2: Explorer.exe o algún componente relacionado con su carga está dañado o mal registrado. Este artículo ofrece pautas para depurar el problema.

Windows Sidebar no se abre correctamente

dmartin — Thu, 04 Sep 2008 13:12:00 GMT

Un usuario tenía el siguiente problema con Windows Sidebar: Al intentar iniciar esta aplicación, no ocurría nada, ni siquiera se mostraba un mensaje de error.

Ante un problema de este estilo, lo primero que suelo decirle al usuario es que abra Administrador de tareas y observe si la aplicación aparece residente en el equipo aunque no muestre su interfaz gráfica. En tal caso lo que suele ocurrir es que la aplicación está estancada esperando a que ocurra algún evento de sincronización que debe señalizar otro hilo, pero esto no ocurre nunca (interbloqueo). En el caso que nos ocupa lo que ocurría es que el proceso desparecía al poco tiempo de ser iniciado, así que los pasos a seguir serían algo diferentes.

En Windows XP y anteriores, un proceso podía generar una excepción y desaparecer de la memoria sin mostrarse un cuadro de diálogo que invitase a enviar el reporte a Microsoft. En Windows Vista, la nueva arquitectura del sistema de excepciones no manejadas en modo usuario impide que esto ocurra. Así pues, determiné que el problema de inicialización no se debía, por ejemplo, a un puntero que estuviera accediendo a una dirección inválida de memoria,

Una vez focalizado el problema, lo primero que suelo hacer es trazar la inicialización de la aplicación y comparar el resultado con una captura obtenida mediante Process Monitor en el sistema afectado. Esto me ayuda a determinar el momento exacto en el que ocurre el error para así desarrollar una solución lo más precisa y sencilla de aplicar posible. Podríamos aplicar métodos generales como reinstalar Windows Sidebar (si esto fuera posible) y quizá solucionar el problema, pero a mí me gusta llegar a la causa exacta del problema, además, este blog trata de eso, ¿no? ;-)

Al abrir la captura de Process Monitor suelo posicionarme en el evento Process Exit, que suele estar situado casi al final de la captura.

Entre otra información, Process Monitor nos proporciona el código de salida del proceso (en la columna Detail). A partir de este evento, al dirigirme hacia arriba encontré una discrepancia interesante:

Como puede ver, cierta información de Registro referente a la DLL Atl.dll apuntaba a una carpeta creada por una aplicación de terceros: Movavi. Inmediatamente después, el acceso a la correspondiente ruta tenía como resultado "PATH NOT FOUND", es decir, ruta no encontrada. Al no encontrar la DLL, Sidebar.exe finalizaba de manera imprevista. Para solucionar el problema, invité al usuario a que registrara la DLL Atl.dll con el siguiente comando (ejecutado desde una consola con privilegios administrativos):

regsvr32 atl.dll

En resumen:

El usuario había instalado la aplicación Movavi en su sistema.
Dicha aplicación incluye su propia versión de la DLL Atl.dll y la registra en su subcarpeta de %ProgramFiles%\Common Files.
El usuario desinstaló la aplicación. La desinstalación no es completa por algún motivo y el Registro aún apunta a una ubicación que no existe.
Como consecuencia de todo esto, Sidebar no se abre.

Una vez reunida toda la información sobre el problema, siempre intento reproducirlo en mis sistemas y, si procede. alerto al fabricante para que corrija el defecto en versiones posteriores de su software.

¡Caso cerrado!

Cerrar Explorer sin cerrar la sesión

dmartin — Mon, 11 Aug 2008 13:50:00 GMT

Completando la información del artículo anterior sobre Explorer, dejo por aquí un "truco" que quizá no conozca: En Windows Vista, al abrir el menú Inicio, pulsar simultáneamente las teclas Ctrl y Shift (Mayúsculas) y hacer clic con el botón derecho sobre una región libre del menú, nos aparecerá una opción adicional a la ya clásica "Propiedades": "Salir de Explorer". Esta opción es especialmente útil cuando haya realizado algún cambio en la configuración que requiera de un reinicio del explorador para que surta efecto. Hasta ahora quizá lo que haya hecho es "matar" al proceso Explorer.exe usando Process Explorer, con todos los riesgos que conlleva el "matar" a un proceso. La opción "Salir de Explorer" realiza los pasos correctos de cierre del explorador, que incluyen, entre otras cosas, el almacenar en el Registro del sistema ciertas configuraciones residentes en memoria. Al "matar" al proceso estas configuraciones se pierden irremediablemente.

Lamentablemente, esta opción no está presente en Windows XP y anteriores, por lo que tendrá que, como mínimo, reiniciar la sesión para lograr un efecto similar en esos sistemas.

Problemas con la inicialización de Explorer.exe

dmartin — Mon, 04 Aug 2008 14:39:00 GMT

Uno de los problemas más frustrantes para un usuario es que su sistema no consiga iniciarse correctamente. En general estamos acostumbrados a trabajar con una máquina "más o menos operativa", pero cuando nos encontramos con un sistema que no llega al escritorio de Windows, empiezan a sonar las alarmas y la palabra "formateo" ronda nuestra cabeza. Este artículo intentará evitar que esto sea así.

El proceso de arranque de Windows es un proceso complejo que va desde la carga del sector de arranque de la partición del sistema hasta la aparición del escritorio de Windows y la barra de tareas. Este artículo se centrará en la parte final de este proceso: la carga del shell del sistema operativo (típicamente Explorer.exe) y cómo abordar un problema de inicialización del mismo.

El proceso de inicialización de Explorer.exe podría decirse que consta de tres fases bien diferenciadas: Una fase inicial en la que se prepara el shell, otra fase central en la que se crea el escritorio y la barra de tareas (esta es la fase principal), y otra fase de postinicialización que se inicia una vez que tenemos el escritorio, los iconos y la barra de tareas en pantalla. Obviamente un fallo en alguna de las dos primeras fases va a derivar en que el sistema solo muestre un escritorio vacío en el que no podremos hacer nada más. Este artículo se centra sólo en las dos primeras fases por ser en las que influyen en que un sistema no muestre ni barra de tareas ni escritorio.

Fase de preinicialización

Una cosa que no mucha gente sabe es que Explorer.exe admite parámetros. Si ejecutamos Explorer.exe /separate, le estamos diciendo al sistema que debe ejecutar obligatoriamente una nueva instancia de Explorer.exe. Por lo regular, Explorer.exe se ejecuta sin parámetros, como así indica la clave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, valor Shell. Una de las primeras cosas que se realizan en esta fase es la creación (si no existiera ya) de la clave de Registro HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer. En ella se almacenan la mayoría de parámetros de configuración que tienen relación con la interfaz gráfica.

Posteriormente, tiene lugar la inicialización la tecnología de comunicación DDE (Dynamic Data Exchange), que pese a ser ya bastante antigua, se usa aún en algunas partes del shell, como la parte relacionada con las asociaciones de ficheros. Se establece en este momento el orden de apagado de Explorer.exe: Ante un apagado o un reinicio de la máquina, Explorer.exe terminará su ejecución en último o penúltimo lugar, dependiendo de si hay algún depurador en la máquina en ese mismo momento. Seguidamente se inicializa la cache de iconos, proceso explicado en uno de los artículos anteriores.

Quizá el momento más importante de esta fase es la ejecución automática de los programas presentes en la clave de Registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce. Estos programas se ejecutan, como su propio nombre indica, una sola vez: en el momento que un usuario con privilegios administrativos inicie sesión en la máquina. Hay un programa encargado de realizar este proceso: C:\Windows\system32\Runonce.exe. Se llama al comando "Runonce.exe /Explorer", el cual, si el usuario es administrador del equipo, se encarga de ejecutar el contenido de la clave RunOnce (que por lo regular son fases finales de la instalación de algún programa). Quizá se pregunte qué es lo que ocurre en Windows Vista, en el que todo intento de elevación de privilegios es bloqueado según el artículo KB930367. La clave RunOnce es una excepción de la regla (tenga en cuenta que sólo un proceso que haya elevado sus privilegios ha sido capaz de escribir en la clave RunOnce, por lo que esto no es ninguna vulnerabilidad). También es posible desactivar la ejecución de la rama RunOnce mediante la siguiente política: DisableLocalMachineRunOnce.

Por último, se crean (si no existieran ya), tres de las carpetas del perfil de usuario relacionadas con el shell: C:\Users\Usuario\Desktop, C:\Users\Usuario\AppData\Roaming\Microsoft\Windows\Start Menu y C:\Users\Usuario\AppData\Roaming\Microsoft\Windows\Start Menu\Programs.

Fase de inicialización del escritorio y la barra de tareas

Esta es la fase crucial. Cualquier fallo que ocurra en esta fase (y en la anterior, pero según mi experiencia es menos probable que esto ocurra) significará que Explorer.exe terminará abruptamente y no verá nada en pantalla, nada más que su escritorio sin ningún icono. Si se encuentra en una situación como ésta, primero abra Administrador de tareas pulsando Ctrl+Alt+Supr e intente ejecutar el proceso Explorer.exe. Si se ejecutara correctamente, más que seguramente se trate de un virus que ha modificado la clave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon. En mi anterior blog tengo unas instrucciones al respecto. Si al ejecutar Explorer.exe observa que el proceso aparece un instante para luego desaparecer, primeramente intente un inicio limpio de Windows: inicie el sistema en Modo seguro y compruebe si persiste el problema. Si en Modo seguro todo funcionara correctamente, vaya añadiendo elementos al inicio mediante Msconfig hasta dar con el culpable. Hay un caso en el cual detecté que el servicio Shell Hardware Detection puede ser el culpable (en tal caso, lo que ocurre es que si espera unos 3 ó 4 minutos observa que el shell se inicia correctamente). El artículo KB913630 explica el problema, pero solo ofrece un workaround.

Si nada de lo anterior le diera resultado, es posible que se encuentre ante un problema con alguno de los componentes encargado de crear el escritorio y la barra de tareas. Explorer.exe se apoya en multitud de clases COM en su mayoría presentes en librerías de Internet Explorer (como Browseui.dll, por ejemplo). Es por ello que algún que otro artículo antiguo de la KB recomendaba reinstalar Internet Explorer como medida de corrección. El problema es que las últimas versiones de Internet Explorer están más y más separadas de lo que es el shell del sistema, por lo que una reinstalación de Internet Explorer probablemente no solucione el problema. ¿Cómo detectar dónde está, pues, el fallo?

Según mi experiencia, un altísimo número de problemas con la interfaz gráfica se deben a que el método CoCreateInstance de Ole32.dll falla por algún motivo. Este motivo suele ser que la clase correspondiente no está registrada en el Registro del sistema. Una manera de abordar este problema es adjuntar Process Monitor al proceso en cuestión (en nuestro caso Explorer.exe) y filtrar por resultado "NAME NOT FOUND". Nótese que no todas las entradas que se indiquen como "NAME NOT FOUND" son posibles causantes del problema; en muchas ocasiones un proceso busca una determinada clave en el Registro y, en caso de no encontrarla, establece valores por defecto para esa configuración. En este artículo se describe una manera en la que abordé el problema de un usuario usando Windbg:

Ejecute el programa Explorer.exe desde dentro de Windbg e introduzca este comando:

0:000> bp ole32!CoCreateInstance "dt ntdll!_GUID poi(@esp+4);gu;j (@eax & 0x0`ffffffff) = 0x0`80040154 '';'gc'"

No se asuste, este comando lo que hace es crear un punto de ruptura (breakpoint) cada vez que alcancemos la función CoCreateInstance. Seguidamente nos muestra el contenido de su primer parámetro (el CLSID implicado), y avanza hasta el retorno de la función (con gu). En este momento, la instrucción condicional j compara el contenido del registro EAX (donde se almacena el retorno de la función) con el valor 0x80040154, que según MSDN quiere decir REGDB_E_CLASSNOTREG. Si lo encuentra, detenemos la depuración; si no, seguimos adelante.

Ejecutamos el proceso y vemos lo siguiente:

0:000> g ModLoad: 5cf60000 5cf86000 C:\WINDOWS\system32\ShimEng.dll ModLoad: 6fdb0000 6ff7a000 C:\WINDOWS\AppPatch\AcGenral.DLL ModLoad: 76b00000 76b2e000 C:\WINDOWS\system32\WINMM.dll ModLoad: 77bb0000 77bc5000 C:\WINDOWS\system32\MSACM32.dll ModLoad: 76630000 766e5000 C:\WINDOWS\system32\USERENV.dll ModLoad: 76340000 7635d000 C:\WINDOWS\system32\IMM32.DLL ModLoad: 773a0000 774a3000 C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83\comctl32.dll ModLoad: 74dc0000 74e2d000 C:\WINDOWS\system32\RichEd20.dll ModLoad: 58c30000 58cca000 C:\WINDOWS\system32\comctl32.dll ModLoad: 746b0000 746fc000 C:\WINDOWS\system32\MSCTF.dll ModLoad: 75160000 7518e000 C:\WINDOWS\system32\msctfime.ime ModLoad: 77b10000 77b32000 C:\WINDOWS\system32\appHelp.dll {750fdf0e-2a26-11d1-a3ea-080036587f03} +0x000 Data1 : 0x750fdf0e +0x004 Data2 : 0x2a26 +0x006 Data3 : 0x11d1 +0x008 Data4 : 8 "???" ModLoad: 76f90000 7700f000 C:\WINDOWS\system32\CLBCATQ.DLL ModLoad: 77010000 770e0000 C:\WINDOWS\system32\COMRes.dll ModLoad: 779f0000 77a45000 C:\WINDOWS\System32\cscui.dll ModLoad: 765b0000 765cd000 C:\WINDOWS\System32\CSCDLL.dll ModLoad: 58e40000 58e65000 C:\WINDOWS\system32\desk.cpl {b12ae898-d056-4378-a844-6d393fe37956} +0x000 Data1 : 0xb12ae898 +0x004 Data2 : 0xd056 +0x006 Data3 : 0x4378 +0x008 Data4 : 8 "???" ModLoad: 5ba10000 5ba83000 C:\WINDOWS\system32\themeui.dll ModLoad: 76330000 76335000 C:\WINDOWS\system32\MSIMG32.dll {4c892621-6757-4fe0-ad8c-a6301be7fba2} +0x000 Data1 : 0x4c892621 +0x004 Data2 : 0x6757 +0x006 Data3 : 0x4fe0 +0x008 Data4 : 8 "???" ModLoad: 01110000 013e6000 C:\WINDOWS\system32\xpsp2res.dll {ecd4fc4d-521c-11d0-b792-00a0c90312e1} +0x000 Data1 : 0xecd4fc4d +0x004 Data2 : 0x521c +0x006 Data3 : 0x11d0 +0x008 Data4 : 8 "???" eax=80040154 ebx=00000000 ecx=00000000 edx=80040154 esi=000ee4a0 edi=001a009c eip=01017362 esp=0146f66c ebp=0146f674 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246 explorer!BandSite_CreateView+0x3b: 01017362 85c0 test eax,eax

Marcadas en negrita están las clases CLSID pasadas como primer parámetro a CoCreateInstance. El depurador se detuvo en este caso en la función BandSite_CreateView, que es parte de la creación de la barra de tareas. Como ve, el CLSID es {ecd4fc4d-521c-11d0-b792-00a0c90312e1}, así que inmediatamente sospeché que la clave HKEY_CLASSES_ROOT\CLSID\{ecd4fc4d-521c-11d0-b792-00a0c90312e1} faltaba o estaba dañada. Mis sospechas se confirmaron:

0:004> !dreg hkcr\clsid\{ecd4fc4d-521c-11d0-b792-00a0c90312e1} Could not open subkey clsid\{ecd4fc4d-521c-11d0-b792-00a0c90312e1}. Error (2). No subkeys

Al importar dicha clave desde un sistema que funcionaba correctamente, el usuario logró solucionar su problema con Explorer sin necesidad de reinstalar Windows.

Quizá este escenario de depuración no sea aplicable a su caso, pero seguramente le habrá dado un punto de partida para enfrentarse a este tipo de problemas sin necesidad de reinstalar ni de instalar en limpio el sistema operativo.

¿Cómo funciona la cache de iconos en Windows Vista?

dmartin — Fri, 25 Jul 2008 17:27:00 GMT

Nota: Los detalles de implementación podrían variar completamente en una siguiente versión de Windows, o incluso en un próximo Service Pack. Por lo tanto, nunca base sus desarrollos en aspectos concretos de implementación. Este artículo pretende ser únicamente informativo.

En computación, el término cache se refiere a una forma de almacenamiento de muy rápido acceso pero pequeña capacidad que sirve para reducir drásticamente el tiempo de acceso a datos que están próximos en ubicación o en tiempo. Este artículo trata sobre una importante cache presente en Windows desde hace ya bastantes años, pero que no ha parado de mejorar: la cache de iconos.

En Windows Vista la cache de iconos está implementada en memoria principal y en disco, la mayoría de sus funciones residen en la DLL Shell32.dll y básicamente consta de un conjunto de listas de imágenes y varias tablas utilizadas para reducir al máximo el tiempo de búsqueda del icono correspondiente.´

Las búsquedas internamente se pueden realizar por nombre de fichero o por una cadena cualquiera, por lo que se mantienen sendas tablas en memoria. Una tercera tabla sirve como "manual" para que el shell sepa exactamente cómo extraer el correspondiente icono. Por ejemplo, una entrada de dicha tabla podría ser similar a esto:

3 Programa.exe 2

Es decir, la entrada número 3 de la tabla dice que el imagen proviene del ejecutable "Programa.exe" y concretamente es el icono de índice número 2 (consulte la documentación de la API ExtractIcon y similares para más información). Si, por ejemplo, el shell necesitara un icono para el acceso directo en el escritorio que el usuario ha hecho para "Programa.exe", lo que hará en primer lugar es generar un hash del fichero para comprobar si tiene alguna correspondencia en la primera tabla, con el mismo contenido y tamaño (de ahí la necesidad del hash). Si es así, la primera tabla le dirá exactamente en qué entrada de la tercera tabla está la información correspondiente (recuerde que las entradas de la tercera tabla almacenan la representación propiamente dicha). En este caso le dirá que es la entrada 3 y el sistema no habrá visto penalizado su rendimiento porque no ha tenido que acceder al disco a por el icono. ¿Qué ocurre cuando el icono no está en la cache? Cuando un icono no está en cache, la función de dispersión acabará por determinar que el elemento a buscar no está en ninguna de las dos tablas, ni la indizada por nombre de fichero ni la indizada por cadenas. En este caso, no queda otra opción que acceder al disco para extraer el icono correspondiente (nótese que esto es similar a lo que ocurre cuando el procesador tiene que acceder a memoria a por una instrucción porque ésta no se encuentra en su primer nivel de cache). El shell crea una nueva entrada en la tercera tabla:

4 Programa_nuevo.exe 3

y crea las correspondientes entradas en las dos primeras tablas para poder acceder rápidamente. Para terminar, con una llamada a la API GetIconInfoEx de User32.dll se obtiene la información correspondiente al mapa de bits del icono y se almacena en la cache.

Como toda cache, la cache de iconos tiene su propia política de reemplazamiento; es decir, en el caso de que esté llena y haya que introducir un nuevo elemento, ¿cuál reemplazamos? La política típica en las caches es la LRU (Least Recently Used, es decir, se reemplaza el que más tiempo hace que ha sido accedido); la cache de iconos del shell no iba a ser menos y sigue más o menos la misma política, se reemplaza el icono que más tiempo ha tardado en ser accedido.

La cache de iconos tiene apoyo en el disco

La cache de iconos reside en todo momento en memoria principal, pero en ciertas circunstancias es necesario que se almacene en el disco, para preservar su contenido cuando el usuario apague el sistema. Cuando el usuario se dispone a apagar o reiniciar su equipo, el sistema observa si la cache ha experimentado cambios desde la última vez que se trajo del disco a memoria. Se dice que una cache está "sucia" si ha ocurrido esto. En ese caso, el sistema guardará una copia de la cache en disco, en el fichero de sistema IconCache.db del directorio %USERPROFILE%\AppData\Local\. El sistema genera el tamaño final de este fichero desde un principio para evitar la fragmentación del disco.

En una fase de la inicialización de Explorer.exe (tema que se tratará en detalle en un próximo artículo), se determina si la cache de iconos almacenada en disco tiene el tamaño y profundidad de color apropiados según la configuración actual; si es así, se copiará su contenido a memoria principal y permanecerá allí hasta el próximo apagado o reinicio.

Algunas preguntas frecuentes sobre la cache de iconos:

¿Se puede ampliar el tamaño de la cache de iconos?

Es posible ampliar el tamaño de la cache de iconos, tanto en XP como en Vista, modificando la clave de Registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Current Version\Explorer, valor Max Cached Icons. Si este valor no existe, el shell tomará por defecto un valor de 500. Si usa la versión de depuración de XP/Vista (versión checked), este valor es menor (200) para poder experimentar más fácilmente con el llenado de la cache de iconos.

¿Cómo se refresca la cache de iconos en Windows Vista?

Un método sencillo de refrescar la cache de iconos en Windows Vista es cambiar momentáneamente la profundidad de color de 32 bits a 16 bits, por ejemplo. Tenga en cuenta que si tiene activada la composición de escritorio, momentáneamente se desactivará hasta que revierta la profundidad de color a 32 bits. Esto es por diseño. Eche un vistazo a este artículo para más información: http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/aero_rules.doc.