Daniel Martín's blog : Funcionamiento

¿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

Mecanismos de protección de integridad en Windows 2000/XP/Vista y 7: Windows File Protection y Windows Resource Protection

dmartin — Sun, 07 Jun 2009 16:36:00 GMT

Desde que salió a la luz Windows Vista, y ahora con las versiones preliminares de Windows 7, me he dado cuenta de que el número de problemas cuya solución implica el registro de una DLL (mediante el comando regsvr32 nombreDLL) ha descendido notablemente en estos dos últimos sistemas operativos. Una de las causas de esto, para mí, es la inclusión de Windows Resource Protection (WRP), mecanismo que garantiza la integridad de los componentes vitales del sistema operativo y que supone una tremenda mejora con respecto a Windows File Protection (WFP), sistema de protección de archivos de sistema presente en Windows 2000 y XP.

Windows File Protection (WFP)

Windows 2000 y XP incorporaron una característica denominada WFP (Windows File Protection), encargada de proteger los archivos más importantes del sistema operativo para evitar que sean modificados o eliminados.

Su funcionamiento se basa en uno o varios hilos de tipo centinela residentes en el proceso Winlogon e implementados en la DLL Sfc_os.dll. Es decir, estos hilos están al tanto de cualquier tipo de modificación que se realice sobre directorios del sistema (típicamente \System32 y \System32\drivers). Si hubiera cambiado alguna DLL de estos directorios, se registra dicho suceso en una cola destinada a tal efecto. En ese momento se señaliza un evento que despierta a otro hilo encargado de realizar la verificación del correspondiente archivo y su recuperación desde la cache (carpeta oculta \WINDOWS\System32\dllcache). Si no estuviera en cache, se mostrará una interfaz al usuario informándole de tal situación e invitándole a introducir el CD de Windows 2000/XP para intentar recuperar la versión original del archivo.

Windows Resource Protection (WRP)

La llegada de Windows Vista supuso que la estructura interna del sistema operativo cambiara radicalmente. Ahora el sistema operativo está formado por componentes, claves de Registro, manifiestos XML y ficheros binarios, entre otras cosas, por lo que la aproximación empleada en versiones anteriores de Windows ya no podía seguir siendo válida. Este aspecto puede ser interpretado como una ventaja, pues si se desarrolla un sistema de protección para cada uno de los componentes del sistema operativo, ya no solo estaremos protegiendo ejecutables y DLL, como en Windows 2000/XP, sino que estaremos protegiendo también claves de Registro y otro tipo de recursos que son igualmente vitales para el correcto funcionamiento del equipo. Este sistema de protección recibió el nombre de Windows Resource Protection (WRP).

Cada uno de los componentes que conforman el sistema operativo Windows Vista/Windows 7 contiene un fichero denominado manifiesto. Un manifiesto es un fichero de tipo XML que contiene información específica sobre el componente, es decir, archivos que lo componen, archivos de los que depende, claves de Registro, privilegios con los que se ejecutará por defecto, idioma, etc. Uno de estos posibles parámetros (etiquetas XML) es la protección del recurso en cuestión, etiqueta <systemProtection></systemProtection>. Existen distintos valores posibles para el parámetro behavior (comportamiento) de esa etiqueta:

readOnlyIgnoreWrites: El recurso solo puede ser modificado por el sistema operativo, durante una instalación (servicio TrustedInstaller). Cualquier intento de escritura por parte de una aplicación será descartado; es decir, se le informará de que la escritura se realizó con éxito pero el fichero no se verá modificado.
readOnlyFailWrites: El recurso solo puede ser modificado por el sistema operativo, durante una instalación (servicio TrustedInstaller). Cualquier intento de escritura por parte de una aplicación tendrá como consecuencia que reciba un error.
OSOnlyIgnoreWrites: Similar a readOnlyIgnoreWrites, pero las modificaciones las puede hacer cualquier componente del sistema operativo.
OSOnlyFailWrites: Similar a readOnlyFailWrites, pero las modificaciones las puede hacer cualquier componente del sistema operativo.
applicationVirtualized: Cualquier cambio que se haga sobre el recurso supondrá que el sistema operativo cree una copia privada a la aplicación que lo ha modificado. El recurso global no se ve modificado.
userVirtualized: Similar a applicationVirtualized pero la copia privada es por usuario, no por aplicación.

En el mismo fichero de manifiesto se indica también qué descriptor de seguridad usar para dicho componente. Por ejemplo, la carpeta Winsxs de Windows Vista tiene este descriptor de seguridad:

O:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464

G:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464

D:PAI

(A;OICI;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)
(A;OICI;0x1200a9;;;BA)
(A;OICI;0x1200a9;;;SY)
(A;OICI;0x1200a9;;;BU)"

Donde S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 es el SID de TrustedInstaller, un servicio encargado de instalar actualizaciones y componentes en Windows Vista y Windows 7.

Vamos a explicar un poco el descriptor de seguridad: Las dos primeras líneas indican que el propietario (O, de owner) como el grupo (G, de group) es TrustedInstaller. La línea D:PAI quiere decir que el DACL es protegido (es decir, que no hereda listas de control de acceso o ACL) y además se hereda automáticamente. A continuación se indica que TrustedInstaller tiene acceso total al recurso (FA, de full access); el grupo de administradores, sistema y usuario (BA, SY y BU, respectivamente) tienen acceso genérico de lectura/escritura. Así pues, ni siquiera un administrador podrá modificar el contenido del directorio Winsxs. Tan solo TrustedInstaller, con motivo de la instalación/desinstalación de actualizaciones, Service Packs o componentes opcionales de Windows podrá modificar ese directorio.

Si quiere saber más sobre ACL y DACL le recomiendo el libro Windows Internals, escrito por Mark Russinovich y David Solomon, ya sea en su cuarta o su quinta edición.

Veámoslo con un ejemplo

Abriendo el fichero de manifiesto del componente Bloc de notas de Windows Vista podemos observar entre otras cosas lo siguiente:

<dependentAssembly> <assemblyIdentity name="Microsoft-Windows-Kernel32" version="6.0.6001.18000" processorArchitecture="x86" language="neutral" buildType="release" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS" /> </dependentAssembly>

Aquí se hace referencia a que Bloc de notas depende del componente Microsoft-Windows-Kernel32 (que contiene entre otras cosas la DLL Kernel32.dll) para funcionar correctamente.

<systemProtection xmlns="urn:schemas-microsoft-com:asm.v3" behavior="readOnlyFailWrites" perUserVirtualization="Disabled" />

Aquí se hace referencia a que cualquier intento de escritura sobre el componente Bloc de notas dará como resultado un error y no se llevará a cabo la modificación. La virtualización está desactivada, por tratarse de un componente de Windows.

<shortCut arguments="" destinationPath="$(runtime.documentsSettings)\Default\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Accessories" destinationName="Notepad.lnk" targetPath="$(runtime.system32)\notepad.exe" iconPath="$(runtime.system32)\notepad.exe,0" windowStyle="normal" workingDirectory="%HOMEDRIVE%%HOMEPATH%" description="@%SystemRoot%\system32\Shell32.dll,-22563" displayResource="$(runtime.system32)\shell32.dll,22051" />

Aquí se hace referencia a la configuración del acceso directo al bloc de notas que hay en el menú Inicio.

<registryKey keyName="HKEY_CLASSES_ROOT\Applications\notepad.exe\shell\open\command" owner="false"> <registryValue name="" valueType="REG_EXPAND_SZ" value="%SystemRoot%\system32\NOTEPAD.EXE %1" operationHint="replace" owner="true" />

Aquí se hace referencia a una de las claves de Registro gobernadas por Bloc de notas, la correspondiente a las asociaciones de ficheros.

Como puede observar, la integridad del sistema operativo fue uno de los objetivos principales para Microsoft mientras diseñaba Windows Vista. La protección de todos y cada uno de los recursos vitales del sistema operativo mediante Windows Resource Protection (WRP) hacen que Windows Vista y Windows 7 sean sistemas mucho más estables y robustos que sus predecesores.

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 funciona la herramienta Reparación de inicio de Windows Vista (Parte III)

dmartin — Sun, 01 Mar 2009 14:58:00 GMT

En este artículo se va a describir el arranque de los sistemas operativos Windows Vista y Windows 7. Antes de comenzar, es necesario que veamos unas pinceladas del arranque de sistemas operativos anteriores, para poner el nuevo sistema de arranque en contexto.

El proceso de arranque en Windows XP y anteriores

El proceso de arranque comienza cuando la BIOS de la máquina lee el primer sector del disco duro. Este sector (el sector de arranque), típicamente contiene una porción de código denominada MBR (Master Boot Record), pero podría contener cualquier otro código ejecutable. En sistemas Windows XP y anteriores sistemas NT, dicho código apunta al fichero Ntldr mediante una cadena de tipo Unicode situada en una posición fija de dicho primer sector del disco duro. El archivo Ntldr es el encargado de leer el fichero Boot.ini, que contiene información importante sobre los sistemas que están instalados y cómo se debe arrancar cada uno de ellos. Si procede, Ntldr muestra al usuario una lista de sistemas operativos para que elija alguno mediante las flechas de dirección.

La nueva arquitectura de arranque

El problema principal de este esquema primitivo de arranque es que se trata de un esquema enormemente dependiente del hardware. Este problema se hizo patente cuando Intel desarrolló, a mediados de los años 90, una nueva especificación para sus máquinas Itanium, con el objetivo de evitar las limitaciones impuestas por el ya vetusto sistema PC BIOS. Esta especificación se denominó EFI (Extended Firmware Interface) y básicamente consiste en una interfaz entre el sistema operativo y el firmware de la máquina. EFI soporta tanto el esquema clásico de particiones basado en MBR como el nuevo esquema GPT (Guid Partition Table). La principal ventaja de este nuevo esquema es que no se ve afectado por las limitaciones de MBR, tales como el límite de 4 particiones primarias por disco y los 2TB como máximo por partición.

Con la salida al mercado de Windows Vista, Microsoft introdujo un nuevo almacén de configuración de arranque denominado almacén BCD (Boot Configuration Data). Podríamos decir que este almacén realiza las mismas funciones que el fichero Boot.ini realiza en sistemas Windows XP o anteriores. La diferencia fundamental reside en que el almacén BCD es independiente del hardware y es capaz de arrancar tanto sistemas PC BIOS tradicionales como sistemas basados en EFI. En el futuro podría darse soporte a nuevos esquemas de arranque.

La arquitectura del BCD está formada por tres componentes bien diferenciados: almacén BCD, objeto BCD y elemento BCD.

Almacén BCD

El almacén BCD es un contenedor de objetos BCD, entidad que a su vez contiene elementos BCD. Físicamente es un fichero binario con una estructura similar a los ficheros binarios que representan ramas del Registro del sistema. Su nombre es BCD y está situado en el directorio \Boot (en un sistema PC BIOS) o \EFI\Microsoft\Boot (en un sistema EFI) de la partición activa del disco.

Objetos BCD

Por defecto, el almacén BCD contiene los siguientes objetos BCD:

Administrador de arranque de Windows: Este objeto contiene entradas correspondientes a cada uno de los sistemas operativos instalados en la máquina. También existen parámetros adicionales, tales como el tiempo de espera hasta que se seleccione la entrada por defecto de dicho menú o la ordenación de la lista de sistemas operativos. Podríamos decir que este objeto BCD reemplaza la funcionalidad de la porción [boot loader] del fichero Boot.ini.
Cargador de arranque de Windows: Existe un objeto BCD de este tipo por cada sistema Windows Vista/Windows 7 que esté instalado en el equipo. Se podría decir que este objeto reemplaza la funcionalidad de la sección [operating systems] del fichero Boot.ini.
Ntldr: Este objeto BCD es opcional y contiene la información necesaria para arrancar sistemas Windows XP o anteriores. Nótese que el fichero Ntldr no sirve para nada en Windows Vista/Windows 7, excepto para arrancar sistemas anteriores.

Además de estos objetos BCD, las aplicaciones pueden crear sus propios objetos utilizando la interfaz de programación del almacén BCD. Por ejemplo, la utilidad de comprobación de memoria RAM incluida en el entorno de recuperación de Windows Vista/Windows 7 programa un análisis de RAM mediante el ejecutable Mdsched.exe, que crea un nuevo objeto BCD que apunta al ejecutable \Boot\Memtest.exe (en sistemas PC BIOS) o \EFI\Microsoft\Boot\Memtest.efi (en sistemas EFI). Otras aplicaciones de terceros podrían crear sus propios objetos en el BCD.

Elementos BCD

Los elementos BCD guardan los parámetros de configuración de cada uno de los objetos BCD. Estos parámetros, como ya se ha comentado, pueden ser la existencia de un depurador de kernel, el sistema operativo que iniciará por defecto, si se han activado las PAE (Physical Address Extensions), etc.

Este diagrama proporciona una visión global de la arquitectura del BCD:

Cada uno de los objetos BCD anteriores enlaza con un ejecutable diferente. Como ya se comentó, el objeto BCD correspondiente al análisis de memoria RAM enlaza con el ejecutable Memtest.exe o Memtest.efi. La entrada correspondiente al arranque de un sistema Windows Vista/Windows 7 enlaza con el ejecutable Winload.exe o Winload.efi, encargado de inicializar el núcleo del sistema operativo mediante Ntoskrnl.exe y cargar algunos controladores de arranque. Si el sistema hibernó por última vez, un objeto BCD apuntará al ejecutable Winresume.exe o Winresume.efi, que es el encargado de reanudar el sistema operativo para dejarlo tal cual estaba antes de ser hibernado.

¿Qué hace la herramienta Reparación de inicio si se encuentra con algún problema?

Si alguna de las estructuras comentadas anteriormente se ha dañado, el sistema no podrá arrancar. La herramienta Reparación del inicio habrá obtenido toda la información mediante su conjunto inicial de pruebas. Si la tabla de particiones, sector de arranque o almacén BCD estuviera dañado, el ejecutable BCDMD (Boot Critical Disk Meta-data Repair) se encarga de regenerar toda esta información. Esta herramienta básicamente realiza un análisis en busca de sistemas operativos, a la vez que compara esta información con la residente en el almacén BCD. Si la información del BCD no fuera coherente, esta herramienta es capaz de modificarla para que lo sea. Si los ficheros Winload.exe o Bootmgr no estuvieran o estuvieran dañados, Reparación de inicio puede recuperarlos en ciertas circunstancias, como ya vimos, mediante el comando Bfsvc.exe /nosetupcheck.

Otro de los problemas que puede afectar al arranque del sistema, como ya vimos, es una corrupción de los ficheros de sistema o bien un problema de permisos sobre ciertos ficheros importantes. Para el primer caso, Reparación del inicio ejecuta el comando Sfc.exe, cuyo funcionamiento se describió en un anterior artículo. Para el segundo caso, la herramienta reconstruye los permisos correctos, teniendo en cuenta que los ficheros del sistema operativo tienen una serie de permisos por defecto, para evitar su accidental eliminación o sobreescritura.

Si el Registro resultara estar corrupto, se puede recuperar a partir de la copia de seguridad del directorio %windir%\system32\config\RegBack. Si dicha copia tampoco estuviera en buen estado, se recurre a la copia con extensión .old que hay en el mismo directorio. Sin embargo, ante una corrupción del Registro la restauración del sistema se intenta aplicar siempre en primer lugar. El motivo es claro, las ramas de Registro del punto de restauración probablemente serán más recientes que las que hay en la carpeta RegBack. Solo se recurre a esta carpeta si no hubiera puntos de restauración disponible o estos no hubieran solucionado el problema.

Haciendo referencia a los puntos de restauración, la herramienta elige el más reciente que sea anterior a la causa que ha producido el fallo. Por ejemplo, si el usuario instaló un controlador y el sistema dejó de iniciar, Reparación del inicio intentará usar el punto de restauración más reciente anterior a la instalación del controlador. Para el caso de un Registro corrupto, la herramienta prueba con el punto de restauración más reciente que haya disponible.

Espero que toda esta información sobre el arranque de Windows Vista/Windows 7 y la herramienta Reparación del inicio les sirva para comprender un poco mejor cómo arranca el sistema operativo, qué estructuras están asociadas al arranque, qué problemas pueden surgir y cómo los aborda la herramienta de Reparación del inicio.

(Esta entrada ha sido programada. Daniel está en estos momentos en Redmond, Washington).

Cómo funciona la herramienta Reparación de inicio de Windows Vista (Parte II)

dmartin — Tue, 03 Feb 2009 11:48:00 GMT

En la parte primera de esta serie de artículos sobre la herramienta Reparación de inicio de Windows Vista se trató con detalle el conjunto de pruebas iniciales que realiza esta aplicación, así como las conclusiones que extrae en función de los signos experimentados en el sistema. Estas pruebas iniciales se centran principalmente en la primera fase del arranque del sistema operativo, pues lo más normal es que si hay un problema que impida que un equipo se inicie, tenga que ver con el disco en sí, con el MBR, con la tabla de particiones, con el sector de arranque, etc.

A continuación se comentará sobre el resto de comprobaciones que siguen a las pruebas iniciales si estas no han dado con una posible causa.

Pruebas adicionales

Como ya vimos, si el sistema no ha sido capaz de iniciarse y tanto el administrador de arranque como el cargador de arranque de Windows Vista no han reportado ningún error, es de suponer que el problema probablemente esté encuadrado en alguna fase posterior del arranque del sistema operativo. Si se detecta que ha sucedido una pantalla azul (bugcheck), la herramienta trata de realizar un análisis rudimentario del volcado de memoria resultante. Si no es capaz de extraer ninguna conclusión, supone sencillamente que es un controlador mal diseñado el culpable del problema.

En el caso de que no haya sucedido ninguna pantalla azul durante el último intento de arranque, el siguiente conjunto de pruebas tiene como objetivo detectar un posible fallo que anterior a la inicialización del sistema de ficheros. Un fallo de este tipo por lo general tiene que ver con permisos incorrectos sobre ficheros importantes del sistema operativo, o bien con un sistema de archivos corrupto. En el primer caso, lo que se hace es comparar los permisos de los ficheros de los directorios %windir%\system32 y %windir%\system32\drivers con los permisos originales tras una instalación limpia de Windows Vista. Los permisos originales sobre ficheros de sistema en Windows Vista son un tanto peculiares; esto tiene que ver con la característica WRP (Windows Resource Protection), que se tratará en un posterior artículo. La corrupción en el disco se analiza con la conocida herramienta Chkdsk.

Si las pruebas anteriores no sacan nada en claro, Reparación de inicio investiga si el usuario ha instalado alguna actualización o algún controlador tras el último inicio correcto del sistema. Para ello repasa los eventos del Visor de sucesos, físicamente disponible en la ruta %windir%\System32\winevt\Logs. Si se ha instalado un controlador y/o actualización, la herramienta supone automáticamente que es la causa del problema, sin realizar más pruebas.

Y con esto finalizan las pruebas que realiza la herramienta Reparación de inicio en Windows Vista y Windows Server 2008. Si tras todas las comprobaciones no se hubiera dado aún con el culpable, el sistema registra este hecho e intentará una restauración del sistema como último recurso.

En el siguiente artículo de la serie se tratarán los arreglos que realiza la herramienta Reparación de inicio, según el problema que haya detectado. Será un artículo en el que también se explique detalladamente el arranque de Windows Vista, que ha cambiado bastante con respecto a sistemas NT anteriores (XP, 2000, NT).

Cómo funciona la herramienta Reparación de inicio de Windows Vista (Parte I)

dmartin — Fri, 19 Dec 2008 18:31:00 GMT

No es extraño encontrarse de vez en cuando con un sistema operativo que ni siquiera es capaz de arrancar. En esos casos el usuario, al no tener apenas nada para poder operar y tratar de solucionar el problema, suele recurrir a un servicio técnico o bien reinstala el sistema operativo. Para evitar situaciones como ésta, Microsoft incorporó en Windows Vista una nueva herramienta especializada en el diagnóstico y la solución de la mayoría de problemas que afectan al correcto arranque del sistema: Reparación de inicio (Startup Repair). ¿Pero qué hace exactamente esta herramienta? ¿En qué casos nos podría servir y en cuáles no? Explicar en detalle el funcionamiento de la herramienta es el motivo de este artículo.

Introducción

Reparación de inicio consiste gráficamente en un asistente implementado en el ejecutable StartupRep.exe del directorio \Windows\System32. Para poder iniciar la herramienta es necesario que el equipo arranque en el entorno de recuperación de Windows (Windows Recovery Environment). Este entorno es la evolución de la Consola de recuperación presente en Windows anteriores. Para iniciar el sistema dentro del entorno de recuperación, hay que arrancar el sistema desde el DVD de Vista y seleccionar Opciones de recuperación del sistema. En la lista de herramientas disponibles, la primera es Reparación de inicio.

La aproximación que sigue la herramienta Reparación de inicio es la que seguiría un médico que está atendiendo a un paciente. Cuenta con una batería de comprobaciones para tratar de averiguar la causa del problema que está provocando que el sistema no arranque. Una vez determinada la o las posibles causas, la herramienta incorpora una serie de reparaciones que podrían solucionar el problema. Si la primera no lo soluciona, se pasa a la siguiente, y así sucesivamente. El orden de aplicación de las soluciones es algo que también decide la herramienta en función de los métodos aplicados con anterioridad y del tipo de problema que el usuario está experimentando.

Las comprobaciones que realiza la herramienta podrían dividirse en dos grandes grupos: Unas pruebas iniciales, centradas en las fases iniciales del arranque de la máquina, y una serie de pruebas más avanzadas, que solamente se realizan si las pruebas iniciales no han dado con la causa del problema. Las reparaciones que se realizan una vez finalizado el diagnóstico son tema de un próximo artículo.

Pruebas iniciales

Inicialmente, Reparación del inicio intenta detectar cuál es el disco de sistema (recuerde que éste es el disco que contiene los ficheros de arranque) y analiza, basándose en la tecnología SMART del disco, si hay algún tipo error. Un fallo en este punto es un fallo de hardware y el usuario probablemente tendrá que reemplazar físicamente el disco o su cable.

Seguidamente Reparación de inicio procede a analizar el disco en profundidad; dos son las estructuras que deben estar en perfecto estado para que el sistema arranque correctamente: la tabla de particiones y el sector de arranque de la partición de sistema. Si por algún motivo no se pudiera encontrar la partición de sistema, esto suele ser síntoma de que la tabla de particiones está dañada. Si se encontrara dicha partición pero no fuera legible, es posible que su sector de arranque esté corrupto. Asimismo es importante que la partición de sistema contenga dos ficheros críticos para el arranque: Bootmgr y Boot.ini.

El siguiente punto a comprobar es que haya un sistema operativo en el disco. Para ello se examina el almacén BCD del disco. Este almacén contiene la información necesaria para saber qué sistemas arrancar y cómo arrancarlos. Parte de la información de este almacén se almacenaba en el fichero Boot.ini en versiones anteriores de Windows. Una vez encontrado el sistema operativo, se comprueba la consistencia de los directorios más importantes del mismo, tales como System32, System32\drivers, System32\config, etc. Por supuesto, el sistema operativo debe ser Windows Vista o Windows Server 2008. Reparación de inicio no es compatible con versiones anteriores de Windows.

El fichero Bootmgr de la partición de sistema es el administrador de arranque de Windows Vista y es un archivo crítico para que el sistema arranque correctamente. Si dicho fichero estuviera corrupto, Windows puede recuperarlo copiando de nuevo los archivos de arranque desde una carpeta de origen. El ejecutable Bfsvc.exe es el encargado de hacer esto. Concretamente, Reparación de inicio llama a Bfsvc.exe mediante la siguiente sintaxis: Bfsvc.exe /nosetupcheck. El parámetro /nosetupcheck sirve para que Bfsvc.exe se ejecute incluso si el sistema está en proceso de instalación. Lo que hace Bfsvc.exe es básicamente copiar los archivos de arranque desde el directorio de orígen, que típicamente es C:\Windows\Boot.

Si aún no se hubiera encontrado la posible causa del problema, se examina el fichero Bootstat.dat, un fichero que, entre otras cosas, registra los inicios y apagados incorrectos del equipo. Es el encargado, por ejemplo, de hacerle saber al código de arranque de Windows que el sistema se apagó incorrectamente para así mostrar por defecto la pantalla de opciones de inicio avanzadas.

Reparación de inicio también verifica la consistencia de las ramas del registro, por si hubiera algún tipo de corrupción. Las ramas del registro residen en el directorio \Windows\System32\config y son las siguientes: SYSTEM, SOFTWARE, COMPONENTS y SAM. Como veremos en un posterior artículo, hay varias formas de recuperar un registro corrupto en Windows Vista, y la herramienta sabrá decidir qué método aplicar en cada caso. La rama COMPONENTS es nueva en Windows Vista y registra información relacionada sobre los componentes instalados en Windows Vista. Como esta información tiene que ir en sincronismo con el almacén de componentes (%windir%\winsxs), hay que tener cuidado a la hora de determinar si se debe reparar esa rama del registro o no.

Por último, si aún no se hubiera encontrado una causa del fallo tras todas las pruebas anteriores, es posible que el sistema sea incapaz de arrancar porque cíclicamente aparece una pantalla azul. Si fuera el caso, Reparación de inicio es capaz de extraer la información del volcado, residente en el archivo de paginación, y realizar un análisis básico para determinar al culpable. Por análisis básico se entiende que no se trata de un humano que está analizando el volcado de memoria, sino que únicamente se incorpora una correspondencia bastante simple entre algunos códigos de error grave (bugchecks) y su causa probable. Por ejemplo, el bugcheck MACHINE_CHECK_EXCEPTION (0x9C) suele ser indicativo de un módulo de RAM dañado, por lo que es probable que ante este código de error Reparación de inicio decida analizar la memoria RAM en el siguiente reinicio mediante el ejecutable Memtest.exe. Otro código de error con causa bastante conocida es el KERNEL_STACK_INPAGE_ERROR (0x77), cuyo causante principal es un error físico en el disco (salvo cuando el primer parámetro es 0, 1 ó 2, puede ver la descripción de este bugcheck en MSDN). Como podrá adivinar, ante este código de error es muy probable que el tratamiento consista en analizar el disco con el comando Chkdsk.

Si del código de error no se pudiera sacar nada en claro, la herramienta supone que el culpable del pantallazo azul es un controlador mal diseñado.

Una vez realizadas todas las pruebas iniciales, se anotan las posibles causas que se han detectado y se intenta reparar el problema siguiendo los métodos que se presentarán en un posterior artículo, junto con un conjunto adicional de pruebas, donde es menos probable que se detecte algún fallo pero que se ejecutan si el conjunto inicial de pruebas no hubiera detectado ninguna anomalía en el equipo.

Este diagrama de flujo resume el proceso de análisis básico de problemas de arranque: