martes, febrero 27, 2007

Cómo funciona Restaurar sistema [Parte I]

En este artículo (será de los últimos o quizá el último que dedique a Windows XP) comentaré cómo funciona internamente una herramienta bastante útil: Restaurar sistema. Además de ofrecer detalles sobre su diseño, incluiré las causas de los mensajes de error y comportamientos anómalos más frecuentes que me he ido encontrando al analizar problemas de usuarios. Si asimila este artículo de dos partes, comprenderá mucho mejor cómo funciona todo y podrá abordar la resolución de problemas con altas garantías de éxito.

En la primera parte del artículo explicaré cómo funciona el controlador en modo núcleo de Restaurar Sistema: Sr.sys. Este controlador, presente en \WINDOWS\system32\drivers, se encarga básicamente de monitorizar los accesos de entrada y salida que se produzcan en el volumen. Lo hace interceptando llamadas de tipo IoCallDriver. El comportamiento del controlador Sr.sys viene determinado por el contenido de la clave de Registro HKEY_CLASSES_ROOT\SYSTEM\CurrentControlSet\Services\Sr\Parameters.

Inicialización del controlador

Al tratarse de un controlador de arranque, se inicializa en una etapa temprana de la carga de Windows. Nada más terminar de inicializarse, se "adhiere" a todos los volúmenes montados por el sistema operativo. Esta es la causa por la que, si dispone de un arranque dual con Windows Vista, observe que pierde todos los puntos de restauración si arranca Windows XP. Seguidamente, crea un directorio llamado "System Volume Information\_restore{GUID}" (si no existiera) en la raíz del disco. Lo crea de tipo oculto, de sistema y por defecto sólo le otorga permisos al usuario SYSTEM. En él se generan unos cuantos archivos, entre los que destacan:

  • _driver.cfg: Contiene el número del punto de restauración actual, número de secuencia del LOG y otra información relacionada.
  • _filelist.cfg: Este fichero es una copia del fichero Filelist.xml presente en el directorio %SystemRoot%\system32\restore\.

¿Qué monitoriza exactamente el controlador?

Básicamente monitoriza todo fichero "interesante". Por interesante se entiende lo siguiente:

  • Que el archivo o carpeta no esté presente en la lista de exclusiones de _filelist.cfg.
  • Que igualmente no esté incluido en una caché interna de Restaurar sistema.
La caché interna a la que se refiere el segundo punto es una tabla hash que "recuerda" las operaciones que se han realizado sobre los archivos y evita monitorizar aquéllas que se repitan. Con esto se minimiza el número de operaciones de copia de archivos.

Una vez que Sr.sys ha determinado que el fichero debe ser respaldado antes de proceder con la operación que se quiere realizar (por ejemplo, eliminarlo), crea una copia del mismo en el directorio System Volume Information\_restore{GUID}\RPX. La copia tiene la forma "AXXXXXXX.ext", donde "X" son números y "ext" es la extensión original del fichero. El subdirectorio Snapshot contiene copias del estado del Registro en el momento de la creación del punto de restauración. Los archivos guardados mantienen sus DACLs, atributos, streams, etc. y a la vez son comprimidos para evitar su fragmentación. Si por algún motivo los ACLs de algún fichero no cupieran en el correspondiente registro (que es de pocos KBs), se creará un fichero de la forma SXXXXXXX.acl y se incluirá una entrada en el LOG apuntando a dicho fichero.

El fichero Change.log

Este fichero es una parte extremadamente importante a la hora de restaurar el equipo de manera satisfactoria. Cuando se realiza una operación de entrada/salida "interesante", además de guardarse una copia del fichero en cuestión (como ya he comentado), se escribe en un fichero Change.log todos los detalles de la operación que se ha realizado. Nótese que, en el caso de que se hayan modificado directorios, no se realiza copia física de respaldo de los mismos, sólo se registra en Change.log la operación que se haya completado.

Para que este fichero sea manejable por el sistema operativo, el sistema lo divide en varios "trozos". Windows finaliza un trozo cuando ocurre alguno de estos eventos:

  • Se ha apagado el equipo.
  • Por algún motivo se ha deshabilitado el volumen en cuestión.
  • Se ha desactivado Restaurar sistema en ese volumen.
  • El archivo ocupa más de 1 MB de tamaño.
Los trozos se diferencian por sufijos numéricos. Así existirían Change.log.1, Change.log.2, etc., siendo el más reciente el de sufijo más alto.

Esta es la funcionalidad básica del controlador de Restaurar sistema en modo núcleo, Sr.sys. En el siguiente artículo me detendré en la parte en modo usuario así como en lo que ocurre "por lo bajo" cuando el usuario pide restaurar su sistema a un punto anterior. Obviamente aclararé por qué ocurren las temidas "restauraciones incompletas", que impiden revertir de manera satisfactoria el estado del sistema.

martes, febrero 20, 2007

Una curiosidad sobre la caja Ejecutar

En uno de los foros en los que participo, un usuario tenía la siguiente inquietud: ¿Por qué si en una ventana de comandos se escribe "msconfig" no se reconoce el comando y, en cambio, desde Inicio, Ejecutar, sí se ejecuta correctamente dicha herramienta?

El secreto está en que la caja Ejecutar del menú Inicio invoca a una función muy específica (y útil): ShellExecuteEx. Es ella la que realiza todo el trabajo "sucio" de encontrar lo que se ha escrito en la caja Ejecutar. Simplificando detalles que no son relevantes en el tema de este artículo, en primer lugar ShellExecuteEx va a mirar en la clave de Registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths. Las aplicaciones pueden incluir las rutas de sus ejecutables en esta clave sin necesidad de manipular la variable de entorno Path. En el caso de que no haya encontrado el ejecutable en la clave anterior, la función ShellExecuteEx se dispondrá a examinar la variable de entorno Path del sistema operativo. Esto lo hace llamando a la función PathFindOnPath, públicamente documentada. Esta función hace uso a su vez de FindFirstFileEx, FindNextFile y FindClose para encontrar el archivo en cada ruta que encuentre en la variable antes mencionada. Estas funciones residen en Kernel32.dll, por lo que realizan la búsqueda utilizando para ello ciertas funciones del núcleo de Windows que no están públicamente documentadas. Desde símbolo de sistema sólo se examina el contenido de la variable de entorno Path para buscar un comando no interno. Como la ruta de Msconfig.exe no está por defecto en el contenido de la variable Path, aparece un mensaje de error indicando que el comando no ha sido reconocido.

Como siempre, muchos virus se aprovechan de esto y redireccionan el contenido de la clave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths para que apunte a su código malicioso. Así, el usuario, que inocentemente trata de ejecutar Regedit o Msconfig para reparar su sistema, acaba ejecutando un troyano o el ejecutable de un gusano, por ejemplo.

Por cierto, las funciones FindFirstFileEx, FindNextFile y FindClose antes mencionadas las utiliza Windows en muchísimos contextos. Como curiosidad, en el artículo donde comentaba cómo Agregar o quitar programas obtenía la información sobre el tamaño de los programas instalados, el módulo Appwiz.cpl llama a estas funciones si no hay información en la caché o ésta se ha corrompido.

lunes, febrero 05, 2007

Sobre el desfragmentador de Windows Vista

Reproduzco una consulta que recibí de un usuario:

Daniel, el desfragmentador de Windows Vista pienso que es bastante malo, ¿qué han hecho los chicos de MS? No hay barra de progreso y, lo que es más importante, si analizo una partición desfragmentada desde Vista aún sigo viendo mucha fragmentación. ¿Cómo lo han empeorado tanto?

Aunque le parezca lo contrario, el desfragmentador incluido en Windows Vista es mucho mejor que el de su predecesor. En este artículo discutiré cómo funciona internamente, centrándome en las quejas más frecuentes que he ido recibiendo.

¿Por qué no hay barra de progreso al desfragmentar?

Una barra de progreso en un proceso de desfragmentación es una incorrección. Todo proceso de desfragmentación del espacio en disco es un proceso en el cual se siguen múltiples fases: una para desfragmentar archivos, otra para consolidar el espacio libre en disco, etc. Cada una de estas fases puede durar un tiempo variable, por lo que la barra de progreso del desfragmentador de Windows XP carece de sentido práctico.

Los resultados del desfragmentador difieren de los del de XP

En efecto, el desfragmentador de Windows Vista utiliza un algoritmo distinto del de Windows XP. Es mucho más eficiente. El algoritmo empleado en Windows XP podría simplificarse del modo siguiente: Todo archivo del disco que esté en, al menos, dos posiciones no contiguas del disco se marca como "fragmentado". El desfragmentador obtendrá ese dato y unirá todas las partes para, posteriormente, compactar el espacio libre en disco. Esto supone dos puntos negativos:
  • Se requiere de un cierto espacio libre en disco para poder realizar la desfragmentación. En el caso de Windows XP este espacio mínimo es de un 15%. En Windows Vista no hay espacio libre mínimo necesario.
  • Si los fragmentos son "demasiado grandes" el tiempo empleado en mover los bloques es superior a la ganancia en rendimiento obtenida.
Quiero precisar sobre el último punto: En un volumen NTFS, el salto de un fragmento a otro consume un bajísimo porcentaje de tiempo en comparación con el tiempo que se tarda en leer un bloque no fragmentado. Partiendo de bloques de 64 MB o más, no merece la pena mantenerlos contiguos, el "esfuerzo" necesario para ello no compensa la ganancia de rendimiento. Debido a esta optimización, el desfragmentador de Vista reduce el consumo de CPU de manera considerable.

El desfragmentador hace uso de la característica "Low-priority I/Os" de Windows Vista

Una de las nuevas posibilidades del núcleo de Windows Vista que más me gusta son las "low-priority I/Os". Así, un desarrollador, que antes podía ejecutar procesos con baja prioridad, ahora puede realizar entradas/salidas igualmente con baja prioridad. En Windows Vista el servicio de indizado, Windows Defender, las aplicaciones que se inician con Windows, y el desfragmentador (entre otros) hacen uso de entradas/salidas de baja prioridad.

El objetivo de Microsoft es que el usuario pueda desfragmentar el disco mientras utiliza cómodamente el PC. Todo el proceso de desfragmentación se hace empleando entradas/salidas de baja prioridad en el momento que se detecte actividad en el sistema. La única excepción es la fase en la que se desfragmenta la MFT del disco. Puede hacer la prueba, inicie el proceso de desfragmentación, deje el sistema sin usarlo y observe el consumo de recursos. Efectivamente es alto, pero ahora realice tareas en el sistema, verá como el consumo disminuye (aumentará lógicamente el tiempo de desfragmentado).

Hay una tarea programada que desfragmenta el disco

Windows Vista incorpora una tarea programada para desfragmentar el disco. Puede acceder a ella desde Administración de equipos, Herramientas del sistema, Programador de tareas, Biblioteca del Programador de tareas, Microsoft, Windows, Defrag. Esta tarea sólo se realiza cuando el sistema está inactivo, por lo que si despliega la pestaña Historial quizá observe que la tarea se ha iniciado, detenido e iniciado de nuevo un sinfín de veces. Es normal, se detectó actividad en el equipo y la tarea se detuvo, para continuarse tan pronto como el sistema vuelva a estar inactivo.

Así pues, ya ve que el desfragmentador incluido en Windows Vista es mucho más eficiente y menos intrusivo que el de Windows XP, a pesar de que la interfaz gráfica sea demasiado "simple" y esto pueda confundir a los usuarios.

Una última optimización del desfragmentador de Windows Vista que no quiero dejar sin comentar tiene que ver con el almacén de copias sombra ("shadow copies"): El nuevo algoritmo de desfragmentación está diseñado del tal forma que se reduce el número de operaciones copy-on-write en el disco. Si esto no fuera así, el almacén de copias sombra y puntos de restauración de Windows Vista vería acelerado su llenado, perdiéndose por tanto el contenido más antiguo del mismo.