Daniel Martín's blog : Consultas

¿Cuándo se crea una partición de sistema durante la instalación de Windows 7?

dmartin — Mon, 14 Dec 2009 01:50:00 GMT

Antes de la primera beta de Windows 7 publiqué un artículo referido a la partición de sistema que se crea durante la instalación de Windows 7, de 200 MB (reducido a 100 MB en la versión final, como ya anticipé en el artículo), con etiqueta "Reservado para el sistema" y sin letra de unidad asignada. Como aún existen muchas cuestiones sobre qué condiciones tiene que cumplir el disco para que se cree automáticamente dicha partición, este artículo intentará detallar aún más este punto. Como ya sabe, el motivo principal por el cual se le invita al usuario a crear una partición de sistema separada de la partición de arranque es para que la utilidad de Windows 7 Bitlocker funcione correctamente y también para facilitar los escenarios en los que hay dos o más sistemas operativos instalados en una misma máquina.

Durante la instalación de Windows 7, se comprueba si existe una unidad de sistema creada con anterioridad (por ejemplo, porque se esté realizando una actualización, una instalación limpia iniciando el programa de instalación desde otro Windows, o bien se hayan creado las particiones con otra utilidad). Si es el caso, se comprueba si esta cumple con el requisito de tener al menos 100 MB de espacio libre. Si fuera además el volumen donde se va a instalar el sistema operativo, este debe tener espacio también para los archivos de instalación del sistema. Si se cumplen estas condiciones, la unidad queda asignada como volumen de sistema, marcada como activa, y el programa de instalación no hace ninguna modificación.

¿Qué ocurre si no hay ningún volumen de sistema en el equipo?

En el caso de que no haya ningún volumen de sistema en el equipo, normalmente porque se está instalando Windows 7 en un disco vacío, el programa de instalación intenta encontrar la mejor unidad de sistema posible. Para ello se siguen estos pasos, que imponen un orden de preferencia:

Se intenta encontrar una región dentro del espacio no asignado del disco donde se va a instalar el sistema operativo, que cumpla con los requisitos de espacio antes mencionados.
Si no se ha encontradado nada, se busca en el espacio no asignado del resto de discos.
Si aún así no se encontrara un candidato a posible unidad de sistema, se examinaría el espacio asignado en todos los discos.

Queda una última restricción: Si el sistema encontrara una región sin asignar que cumpliera con los requisitos de espacio de la unidad de sistema, esta solo es elegida si en el disco hay menos de 3 particiones.

Una vez que el programa de instalación ha encontrado una región que puede contener la unidad de sistema, consulta al usuario si desea crearla (si procede) y, de contestar afirmativamente, la crea y le da formato NTFS.

Preguntas más frecuentes:

Tengo una partición sin letra de 200 MB o de un tamaño superior, no de 100 MB

Es importante comentar que la versión final de Windows 7, de tener que crear una partición de sistema, siempre creará una de 100 MB. Si observa una partición de 200 MB o de otro tamaño superior, sin letra de unidad, probablemente se trate de una partición activa que ya estaba con anterioridad en ese sistema (quizá por la instalación de una versión beta de Windows 7) y que el programa de instalación de Windows 7 ha aprovechado.

¿Se puede evitar la creación de esa partición de sistema?

Es posible, pero yo personalmente no lo recomiendo. Quizá la forma más sencilla sea pulsar Mayúsculas+F10 en la pantalla de creación de particiones del programa de instalación de Windows 7 para abrir una consola de comandos. En dicha consola, teclear estos comandos para crear una partición activa que ocupe la totalidad del disco. Esta partición activa la usará el programa de instalación como partición de sistema:

Diskpart Select disk 0 Create part prim Active Exit

Es probable que al cerrar la consola tenga que pulsar sobre el botón Actualizar para ver el nuevo esquema de particiones recién creado.

Para concluir, este diagrama de flujo resume los pasos que se siguen para determinar si se debe crear una unidad de sistema durante la instalación de Windows 7:

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

¿En qué consiste una versión localizada de Windows Vista/7? [Parte I]

dmartin — Sat, 24 Oct 2009 20:24:00 GMT

Una práctica que era común en el desarrollo de software de hace unos años consistía en mezclar el código fuente de la aplicación junto con cadenas de texto y otros recursos (iconos, imágenes, etc.). El siguiente diagrama lo explica gráficamente:

Conforme el mercado comenzó a globalizarse fue surgiendo la necesidad de traducir aplicaciones a múltiples idiomas, y por ende este método acabó siendo completamente descartado por los siguientes motivos:

Para traducir una aplicación primero hay que crear una o más copias de su código fuente, con el consecuente coste añadido que supone el mantenerlas.
Los traductores, que por lo general no tienen conocimientos de programación, tienen que manipular el código fuente para traducir las cadenas de texto. Esto puede introducir errores en el funcionamiento de la aplicación.

Es en esta época cuando el uso de una versión en inglés (o en el idioma nativo de la empresa que desarrollara ese programa) sí podía ofrecer ciertas ventajas con respecto al resto de idiomas. La posibilidad de introducir errores en el código mientras se traducía un programa no era algo descabellado, todo ello debido a que la separación entre código fuente y cadenas de texto dependientes del idioma era insuficiente (en este caso particular, inexistente).

Las versiones de Windows anteriores a Vista introdujeron una nueva arquitectura de localización de binarios, con el objetivo de separar el código fuente (las instrucciones que acaba ejecutando el computador) de las cadenas de texto (mensajes informativos, errores, iconos, etc.).

Si bien esta arquitectura es válida y sigue siendo usada por muchísimas aplicaciones hoy en día, presenta algunas deficiencias que se magnifican en una empresa del tamaño de Microsoft: Por ejemplo, si se detecta un fallo de seguridad en un binario y se quiere desarrollar una actualización de seguridad al respecto, como el código fuente y las cadenas de texto están en el mismo fichero (pese a estar separados entre sí), sería necesario generar un par de decenas o más de actualizaciones de seguridad, una para cada idioma en el que está disponible Windows. Esto retarda innecesariamente el desarrollo de actualizaciones de seguridad en varios idiomas, pues por lo general los errores de seguridad afectan únicamente al código de la aplicación, no a las cadenas de texto y otros recursos que pudiera contener.

Con Windows Vista se rediseñó en profundidad la arquitectura MUI (Multilingual User Interface) que ya estaba presente en la versión Professional de Windows XP (entre otros) para que las cadenas de texto y el código de las aplicaciones estuviera completamente separado, esto es, en ficheros diferentes.

Esta arquitectura MUI introducida con Windows Vista no solo beneficia a Microsoft y al usuario, que ya puede instalar un paquete de idiomas en una versión de Windows que no esté en inglés, también beneficia a los desarrolladores de aplicaciones, pues por fín disponen de una arquitectura proporcionada por el sistema operativo para manejar recursos en múltiples idiomas, sin ser ya necesario que se construyan una desde cero.

¿Qué ocurre al instalar Windows Vista/7?

En un artículo de mi antiguo blog tengo información que explica resumidamente en qué consisten las fases de la instalación de Windows Vista. Básicamente lo que ocurre es que en primer lugar se instalan los binarios del sistema (independientes del idioma), y seguidamente se instala uno o varios paquetes de idiomas. Como ve, el inglés no recibe ningún tipo de trato preferencial, se le trata como un idioma más. La fase correspondiente a la instalación del paquete de idiomas inicial se realiza durante la fase "Instalando características".

En Windows Vista la herramienta encargada de instalar un paquete de idiomas es la denominada Package Manager (Pkgmgr.exe). En Windows 7, se usa la herramienta Dism (Deployment Image Servicing and Imaging), que integra todas las funcionalidades de Package Manager y de otras herramientas igualmente relacionadas con la administración de imágenes de instalación.

En este primer artículo se ha explicado cómo ha ido evolucionando la localización del software a lo largo del tiempo y se ha aclarado que en Windows Vista y Windows 7 los binarios están completamente separados de las cadenas de texto, con las ventajas que esto conlleva. Esto implica también que Vista/7 sean sistemas idependientes del idioma en el que se utilicen; el inglés es un idioma como otro cualquiera.

En un siguiente artículo se explicará en detalle en qué consiste exactamente un paquete de idiomas y qué es lo que conforma la infraestructura MUI de Windows Vista/7. Se explicará también cómo el sistema obtiene los recursos en el idioma establecido por el usuario. Este aspecto puede ser importante para la gente que le interese saber cómo solucionar problemas con Windows, pues me he encontrado con algún que otro sistema cuyo síntoma es que una determinada aplicación no muestra ningún tipo de interfaz gráfica (es decir, no se abre) y cuya causa es una configuración incorrecta de los recursos MUI de ese sistema.

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.

¿Cuándo crea Windows un punto de restauración automático?

dmartin — Fri, 18 Sep 2009 02:31:00 GMT

Una de las dudas que más surgen entre los usuarios de Restaurar sistema es cada cuánto tiempo se creará un punto de restauración automático. Este artículo pretende dar una respuesta precisa a esta cuestión para así esclarecer aquellos casos en los que el sistema no haya creado un punto de restauración desde hace tiempo.

Windows XP

En Windows XP cada hora una tarea interna del Programador de tareas se encarga de analizar si el sistema está inactivo, es decir, si no está haciendo uso de la CPU ni del subsistema de E/S. Si se diera el caso, se realizan dos posibles comprobaciones para determinar si se debe crear un punto de restauración automático:

Si han pasado más de 24 horas desde el último punto de restauración, se crea uno automáticamente. Este parámetro (24 horas) es editable desde el Registro del sistema operativo, concretamente en la clave HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\SystemRestore, valor RPGlobalInterval.
Si la sesión actual de trabajo con el PC está durando más de X horas y el último punto de restauración es más antiguo, se crea un punto de restauración automático. Por defecto, esta configuración no está establecida, pero puede hacerlo desde el Registro en la clave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRestore, valor RPSessionInterval.

La comprobación de inactividad se realiza por defecto cada hora pero podría variar dependiendo de los valores de ciertas políticas de energía de su equipo. Eche un vistazo a los valores IdleTimeoutDc, IdleTimeoutAc de esta página de MSDN: http://msdn.microsoft.com/en-us/library/aa373239(VS.85).aspx. Aprovechando la inactividad, Restaurar sistema realiza otras tareas, tales como eliminar aquellos puntos de restauración cuyo tiempo de vida ya haya expirado, y de paso comprimir el almacén usando compresión NTFS. Estas tareas se realizan solo si el equipo está conectado a la corriente eléctrica, para evitar que se agote la batería en el caso de portátiles.

Si quiere profundizar en el funcionamiento de la herramienta Restaurar sistema de Windows XP, eche un vistazo a esta serie de artículos de mi antiguo blog:

http://rinconwindows.blogspot.com/2007/02/cmo-funciona-restaurar-sistema-parte-i.html

http://rinconwindows.blogspot.com/2007/03/cmo-funciona-restaurar-sistema-parte-ii.html

Windows Vista/7

En Windows Vista/7 el nuevo Programador de tareas muestra información detallada acerca de la tarea programada que crea un punto de restauración automático. Abra Programador de tareas, apartado \Microsoft\Windows\SystemRestore. La tarea SR tiene como desencadenantes:

El inicio del sistema.
Diariamente a las 12 AM.

En esos instantes se ejecutará el comando %windir%\system32\rundll32.exe /d srrstr.dll,ExecuteScheduledSPPCreation.

El modificador /d de Rundll32.exe ya lo traté ligeramente en mi antiguo blog: Se trata de un modificador que le dice a Rundll32.exe "ejecuta este comando y no captures las posibles excepciones que ocurran". La función ExecuteScheduledSPPCreation es la encargada de verificar si el punto de restauración más antiguo tiene más de 12 horas (la mitad que en el caso de XP) y, si así fuese, creará uno nuevo.

Hay que tener en cuenta otras condiciones adicionales que puede observar en la pestaña Condiciones: El sistema debe estar inactivo durante al menos 10 minutos y además, en el caso de portátiles, debe estar conectado a la red eléctrica.

Espero que este artículo haya aclarado sus dudas con respecto a la creación automática de puntos de restauración por parte de Windows. En resumen, si su sistema no genera periodicamente puntos de restauración puede deberse a:

El servicio Programador de tareas no está iniciado.
El sistema no está inactivo durante los periodos de tiempo impuestos por Windows, según lo explicado anteriormente.

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.

Mostrar una lista de puntos de restauración

dmartin — Thu, 23 Jul 2009 12:54:00 GMT

Hace unos días en un grupo de noticias que frecuento un usuario que estaba utilizando este script del MVP Enrique Cortés se preguntaba por qué en el fichero de resultados las horas de cada punto de restauración no coincidían con las mostradas en el calendario de Restaurar sistema.

Esto se debe a que en la información que se guarda en el almacén de puntos de restauración (y que es accedida por WMI en el script) las fechas y horas tienen como huso horario +000 (GMT). Así pues, modifiqué el script para que las fechas se conviertan a la zona horaria del sistema en cuestión y aproveché para mostrarlas en un formato más legible. En principio el script es compatible con cualquier versión a partir de XP, pero en Vista y 7 deberá ejecutarlo con privilegios administrativos.

Puede descargar el script modificado desde esta página.

¡Que lo disfuten!

¿/Savecred, /Savedcred, /Savedcreds...? Es lo mismo

dmartin — Thu, 02 Jul 2009 18:57:00 GMT

Como quizá sepa, el comando Runas.exe de Windows XP y Windows Server 2003 sirve para ejecutar procesos en el contexto de otra cuenta de usuario. Los usuarios domésticos normalmente lo usan para ejecutar un proceso como administrador desde una cuenta limitada. Echando un vistazo al listado de parámetros de Runas.exe nos encontramos con uno que suele llamar la atención de bastante gente. Sirve para almacenar temporalmente en el administrador de credenciales (Credential Manager) el usuario y contraseña que va a ejecutar el programa. El atractivo de este parámetro es que no tendremos que introducir el nombre de usuario y contraseña para ese programa durante la sesión en curso. Sin embargo, no hay unanimidad con respecto al nombre del parámetro (incluso la propia documentación del sistema operativo creo que presenta alguna inconsistencia al respecto): Unos lo llaman /savecred, otros /savedcred, otros /savedcreds... Incluso en algunos sitios se indica que tienen semántica diferente.

Nada más lejos de la realidad. Runas.exe solo entiende el parámetro /sa (que contiene el mínimo número de letras que diferencian /savecred de los parámetros /smartcard y /showtrustlevels); lo que venga después le es indiferente. Del mismo modo, en cuanto se encuentra con /p supone el parámetro /profile; si se encuentra con /e supone /env, y así sucesivamente.

Nota: Por limitaciones del administrador de credenciales de XP Home Edition, el parámetro /savecred no es tenido en cuenta en esta versión de Windows. Este artículo no es aplicable tampoco a Windows Vista, pues el comando Runas.exe en Windows Vista es bastante diferente del de XP y será tema de un próximo artículo.

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.

¿Internet Explorer se cuelga con frecuencia?

dmartin — Mon, 16 Feb 2009 23:54:00 GMT

Aunque Internet Explorer no sea algo que conozca en profundidad, últimamente mucha gente me ha estado enviando mensajes indicando que su navegador se bloquea a menudo. He estado analizando por encima el volcado de memoria de un sistema afectado y al parecer el complemento Adobe Flash es el presunto culpable. De hecho, desactivando dicho complemento en IE, desde Herramientas, Administrar complementos, se ha solucionado el 100% de los casos que he tratado. Otra sugerencia que ha resultado útil consiste en desinstalar la versión 10 de Adobe Flash y a continuación instalar la versión 9. Así que si ha llegado a esta página buscando información sobre un cuelgue de Internet Explorer, espero que esta información le resulte útil.

Buscando en la web de Adobe, he visto que se trata de un posible bug que ya está siendo analizado, pero aún no hay solución: http://bugs.adobe.com/jira/browse/FP-1145.

Si conoce alguna web con contenido Flash que haga que el navegador se cuelgue con frecuencia, o si ha logrado obtener unos pasos que reproduzcan el problema de manera consistente, le agradecería que contactara conmigo ya sea a través de la sección de comentarios de esta entrada o a través de la página Contact de la parte izquierda de este blog. Gracias de antemano.

Actualización 25/02/2009: Gracias a todos por la información. El problema ya está solucionado en la nueva versión de Adobe Flash Player que se puede descargar desde http://get.adobe.com/flashplayer.

El caso de la instalación fallida de IIS en Windows Vista

dmartin — Wed, 07 Jan 2009 16:11:00 GMT

El caso de hoy es el de un sistema Windows Vista en el que no era posible instalar el componente IIS (Internet Information Server), que sirve para publicar páginas web tanto local como remotamente y es un requisito previo a la instalación de algún que otro programa, como por ejemplo Virtual Server. Para instalar componentes opcionales en Vista, como sabrá, hay que ir a Panel de control, Programas, Instalar o desinstalar componentes de Windows.

El mensaje de error que aparecía era el siguiente:

Una de las primeras cosas que hay que examinar cuando hay problemas para instalar un componente de Windows, un paquete de idiomas, una actualización, un Service Pack, etc. es el fichero C:\Windows\Logs\CBS\CBS.log. Es posible que el registro sea bastante extenso y por ello se haya creado un fichero CBS.persist.log con las entradas más antiguas. En tal caso, es posible que tengamos que examinar este fichero también.

Buscando en el fichero de abajo hacia arriba, encontré el error que probablemente estaba abortando la instalación:

2008-12-23 11:57:34, Error CSI 00000012@2008/12/23:10:57:34.500 (F) d:\rtm\base\wcp\sil\silp.h(2661): Error STATUS_INVALID_PARAMETER originated in function Windows::Rtl::SystemImplementation::CFile_IRtlFileTearoff::SetAttributes expression: Valid flags check failed: Attributes [gle=0x80004005]

Estas líneas quieren decir que ha fallado la comprobación de parámetros de una función del servicio de componentes de Vista. Concretamente la función es SetAttributes, que probablemente tenga como objetivo aplicar ciertos atributos sobre un fichero. La parte "[gle=0x80004005]" (gle es la función GetLastError) quiere decir que el último error surgido durante la ejecución de dicha función es un error HRESULT que básicamente quiere decir que el error es inespecífico. Obviamente necesitaba información mucho más útil, así que examiné el reporte a partir de ese punto y me encontré con esta línea, mucho más interesante:

2008-12-23 11:57:34, Error CSI 00000011 (F) STATUS_INVALID_PARAMETER #3228437# from Windows::Rtl::SystemImplementation::CFile_IRtlFileTearoff::SetAttributes(Attributes = 2048 (0x00000800))[gle=0xd000000d]

El error 0xd000000d quiere decir STATUS_INVALID_PARAMETER pero, ¿qué atributos se le estaba pasando a la función? El valor Attributes = 2048 (0x800 en hexadecimal) nos da la clave. Una búsqueda en el fichero Winddk.h del DDK de Windows devolvió el siguiente resultado:

#define FILE_ATTRIBUTE_COMPRESSED 0x00000800

Como ve, el atributo que se estaba pasando es el atributo comprimido. La compresión de ficheros es una característica del sistema de ficheros NTFS y no tiene nada que ver con los archivos .zip o .rar. Ya estaba cerca de desvelar el misterio, pero para poder aplicar una solución necesitaba saber qué fichero o ficheros estaban involucrados en el error. Observando minuciosamente el fichero CBS.log me encontré con esa información:

2008-12-23 11:57:49, Info CSI 00000013 Error STATUS_INVALID_PARAMETER while executing operation SetFileInformation on [l:138{69}]"\??\C:\Windows\System32\inetsrv\config\schema\FX_schema.xml, N/A, N/A"

Hay que tener en cuenta que el fichero FX_schema.xml no había sido servido aún al directorio C:\Windows\System32\inetsrv\config\schema\ (directorio de instalación de IIS), pues la instalación no pudo completarse, por lo que le indiqué al usuario que acudiera al almacén de componentes (C:\Windows\winsxs) y buscara allí el componente que contuviera ese fichero FX_schema.xml. El usuario me informó de dos resultados:

amd64_microsoft-windows-iis-sharedlibraries_31bf3856ad364e35_6.0.6000.16386_none_6ad14c4c7044b7ae (estaba sin comprimir)
amd64_microsoft-windows-iis-sharedlibraries_31bf3856ad364e35_6.0.6001.18000_none_6d080e486d2fc882 (comprimido, es decir, en color azul).

El primer resultado es el componente instalado por la versión RTM de Windows Vista; el segundo es el instalado por el Service Pack 1.

Así pues, el usuario descomprimió la segunda carpeta desde el panel de propiedades, botón Opciones avanzadas, y ya pudo instalar IIS.

¿Por qué estaba comprimida esa carpeta? Ciertamente lo desconozco, pero mi opinión es que algún software o el propio usuario lo hizo con el objetivo de ahorrar espacio en disco debido al elevado espacio en disco consumido por el directorio C:\Windows\winsxs en Windows Vista. Como puede leer en este blog del equipo de Windows, el espacio realmente ocupado es mucho menor y, como ya pudo comprobar, comprimirlo puede tener como consecuencia no poder instalar un componente de Windows.

¡Caso cerrado!

Actualización (27 de octubre de 2009): En según qué casos, puede ser que necesitemos echar un vistazo también al fichero de reporte específico de IIS, a saber, %windir%\iis.log.

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

Cómo analizar el rendimiento del arranque/apagado de Windows Vista

dmartin — Thu, 09 Oct 2008 20:06:00 GMT

Una de los quejas que más se ven en los foros de Windows Vista es la siguiente:

El sistema arranca/apaga/hiberna muy lentamente. Cuando inicio sesión tengo que esperar un montón de tiempo hasta que finalmente se apaga la luz del disco duro y puedo trabajar.

Como cada persona tiene su propia idea de lo que es "lento" y, ciertamente, es difícil describir de manera precisa en qué fase concreta del arranque se consume una mayor cantidad de tiempo, lo que suelo indicar es que se utilice la infraestructura ETW (Event Tracing for Windows) de Windows Vista para generar una traza detallada del arranque/apagado/hibernación para así determinar la causa del problema. Concretamente, la herramienta Xbootmgr (http://www.microsoft.com/whdc/system/sysperf/perftools.mspx), parte del kit de herramientas Windows Performance, se apoya en la infraestructura ETW para generar una traza detallada del apagado, inicio, suspensión e hibernación del equipo.

Una vez instalado el software, vamos a usar la herramienta Xbootmgr para generar una traza del arranque, por ejemplo. Antes de comenzar la prueba, es recomendable que:

No use el sistema durante la prueba, para que la medición sea lo más precisa posible.
Desconecte toda conexión de red, unidad de red, etc. que tenga en el equipo.
Configure el sistema para iniciar sesión automáticamente. Para ello, puede usar la powertoy Autologon de Windows Vista.

La sintaxis sería:

xbootmgr -trace boot -numRuns 2 -resultPath %systemdrive%\traces -prepSystem -traceflags base

El valor boot del parámetro -trace indica que queremos trazar el arranque del equipo. Podríamos poner shutdown y estaríamos trazando el apagado del equipo.

El valor 2 del parámetro -numRuns indica que queremos realizar 2 trazas consecutivas.

El parámetro -prepSystem implica que se realizará un par de arranques "preparatorios" antes de la prueba en sí.

Una vez ejecutado el comando anterior, el sistema informará de que se va a reiniciar automáticamente. Cuando finalice la traza, verá que en el directorio que haya indicado tras el parámetro -resultPath se ha creado un fichero con extensión .etl. Para extraer un resumen de la información de ese fichero en formato XML, puede usar la utilidad Xperf del siguiente modo:

xperf -i traza.etl -o resumen.xml -a boot

(Donde "traza.etl" es la traza que se ha obtenido como resultado del comando Xbootmgr).

Al abrir el fichero Resumen.xml encontrará un resumen de cada una de las fases de arranque así como los correspondientes tiempos de ejecución, entre otros datos. Es bastante más intuitivo mostrar la información de una manera gráfica. Para ello, simplemente ejecute el siguiente comando:

xperf traza.etl

Se abrirá la herramienta Windows Performance Analyzer y mostrará la información de la traza de manera gráfica. La siguiente captura de pantalla muestra una parte de la información mostrada en un sistema:

En la parte superior se puede ver un diagrama temporal de los procesos del sistema operativo, es decir, en qué momento "nacen" y en qué momento finalizan. En la parte inferior aparece el concepto "hard faults", que hace referencia a todos aquellos fallos de página que han requerido una operación de E/S hacia el disco. Como esto es una operación costosa (varios órdenes de magnitud más lenta que el acceso a memoria principal), toda herramienta que analice el rendimiento de un sistema suele proporcionar este dato. Es normal que en las etapas iniciales del arranque se produzca un gran número de fallos de página. Windows Performance Analyzer permite mostrar gráficas adicionales tales como el consumo de CPU por proceso, E/S por proceso, etc.

En general, ¿qué produce un inicio lento?

Suponiendo dos máquinas iguales o parecidas en lo que a hardware se refiere (hardware que cumpla los requisitos recomendados de Windows Vista), el que una de ellas arranque mucho más lentamente que la otra puede deberse a:

Controladores de arranque sin una firma digital embebida. Esto supone que Windows Vista debe ir al catálogo (%windir%\catroot) a buscar la correspondiente firma digital, demorándose la carga del controlador.
Controladores que responden lentamente a los eventos generados por el administrador Plug and Play de Windows. Concretamente, el cuello de botella suele encontrarse a la hora de manejar la IRP IRP_MN_START_DEVICE. Tiene información sobre la misma en el sitio web de MSDN. Como se comenta en la propia documentación, los controladores deberían devolver el resultado STATUS_PENDING y posponer el tratamiento de la IRP para así no perjudicar excesivamente el tiempo de arranque del sistema.
Un controlador de vídeo que tarda mucho tiempo en inicializarse.
Conexiones de red persistentes (una unidad de red, por ejemplo) que tardan en responder mucho tiempo.
Scripts de inicio impuestos mediante directivas (esto es más común en un dominio).
Servicios que tardan demasiado en iniciarse.

Si interpretando la información de la traza determinase que es en la fase final del arranque en la que se consume más tiempo, quizá desee desactivar servicios u otros elementos que arrancan junto con Windows. Para ello lo ideal es que haga uso de la herramienta Autoruns.

En resumen, el arranque y apagado del sistema operativo son dos procesos complejos (especialmente el primero) formados por una serie de fases bien diferenciadas. Interpretando la información proporcionada por las herramientas Xbootmgr y Xperf podrá comprender mejor qué es lo que ocurre cuando arranca o apaga su sistema y será capaz de detectar los cuellos de botella que tantos segundos de nuestro preciado tiempo nos roban cada vez que ponemos en funcionamiento nuestra máquina.

Por supuesto, si necesitara ayuda para interpretar los resultados de alguna traza, puede plantear su pregunta en los comentarios de esta entrada.

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!

No se puede instalar la actualización KB955428

dmartin — Fri, 15 Aug 2008 20:15:00 GMT

En los últimos días he recibido ya varios reportes de usuarios que no consiguen instalar la actualización KB955428, que corrige una vulnerabilidad en Microsoft Works. El error que aparece es el 0x8024002D (WU_E_FF_SOURCE_ABSENT). Este es el extracto del fichero WindowsUpdate.log de un sistema afectado por este problema:

2008-08-14 21:15:35:225 1224 bb8 AU # 1 updates detected 2008-08-14 21:15:35:225 1224 b68 Report REPORT EVENT: {B8F1D8C8-9EBA-48DB-B60C-D2B4E5E29019} 2008-08-14 21:15:18:566+0200 1 182 101 {B40E4721-6DDE-4C74-A3E0-EE1EDEB0BAF7} 104 8024002d AutomaticUpdates Failure Content Install Installation Failure: Windows failed to install the following update with error 0x8024002d: Update for Microsoft Works 8 (KB955428). 2008-08-14 21:15:35:226 1224 bb8 AU ######### 2008-08-14 21:15:35:226 1224 bb8 AU ## END ## AU: Search for updates [CallId = {68A5E66E-B57F-402C-9ABC-09D9F61BFB8A}] 2008-08-14 21:15:35:226 1224 bb8 AU #############

Lo que quiere decir todo esto es que la actualización requiere que se introduzca el CD original de Works para poder instalarse correctamente. El problema es que muchos equipos OEM preinstalan Works y el usuario no dispone del CD. En estos casos, descargue la actualización desde http://www.microsoft.com/downloads/details.aspx?displaylang=es&FamilyID=458985c3-9c6f-4049-81cd-0d0389c81f11, haga doble clic sobre el fichero .cab y seguidamente doble clic sobre el fichero .msp para comenzar la instalación.

Espero que sea de utilidad.

¿Por qué no puedo reducir más una de mis particiones desde Windows Vista?

dmartin — Wed, 30 Jul 2008 02:56:00 GMT

Una de las novedades de Windows Vista y Windows Server 2008 es la posibilidad de reducir y ampliar el tamaño de un volumen sin perder ningún dato. Hasta ahora, esto solo era posible utilizando aplicaciones de terceros. Al abrir el nuevo Administrador de discos de Windows Vista, seleccionar un volumen con el botón derecho y hacer clic sobre Reducir volumen, nos aparece este cuadro de diálogo:

Una de las consultas más frecuentes es por qué el tamaño máximo que se puede reducir es, en el caso de la figura, de 9.048 MB, si el volumen es posible que disponga de mucho más espacio libre.

A la hora de computar el tamaño máximo que se puede reducir en un volumen, se tienen en cuenta tres aspectos:

El espacio libre en el volumen.
El espacio dedicado a las copias sombra (puntos de restauración).
La posición de ciertos archivos que no se pueden mover (como el archivo de paginación).

El tamaño máximo que se puede reducir será el mínimo entre el espacio libre en el volumen y el máximo de espacio que se podría reducir teniendo en cuenta estos dos aspectos: las copias sombra (puntos de restauración) y la posición más desplazada de un archivo que no se pueda mover. Al tamaño total se le suele añadir un cierto número de MB para dar un margen de espacio tras la reducción.

Para Administrador de discos, los ficheros que no se pueden mover son los siguientes: Pagefile.sys (el archivo de paginación), Hiberfil.sys (el fichero de hibernación), Crashdmp.sys y los ficheros internos NTFS $bitmap, $mftmirr, $secure, $usnjrnl y $logfile. Por tanto, si alguno de esos ficheros se sitúa en una posición casi al final del volumen, el tamaño para reducir será muy pequeño. Vea este ejemplo:

Como observa en el diagrama, el disco tiene 25 GB ocupados, por lo que el espacio libre en disco son 95 GB. Sin embargo, dado que el fichero Pagefile.sys se sitúa casi al final del volumen, el espacio máximo disponible para reducir será de solo 9 GB.

Puede ver gráficamente la disposición de los clústers usando alguna herramienta de desfragmentación de terceros, como Diskeeper o similares.