El comando Sfc.exe en Windows Vista

Una de las acciones más recomendables cuando nos enfrentamos a cierto tipo de problemas en Windows es comprobar la consistencia de los ficheros del sistema operativo, para asegurarnos de que ningún usuario o aplicación los haya eliminado o modificado con versiones incorrectas. El comando que lleva a cabo todo este proceso recibe el nombre de Sfc.exe (System File Checker).

Diferencias entre el comando Sfc.exe en Vista y en versiones anteriores de Windows

Pese a que la sintaxis básica de Sfc.exe se ha mantenido prácticamente inmutable a lo largo del tiempo, los cambios en la arquitectura de Windows Vista han derivado en que la manera de actuar de Sfc.exe ha tenido que cambiar también. Mientras que en Windows XP la unidad básica podríamos decir que es el fichero, en Windows Vista la unidad básica es el componente. Un componente es un contenedor de recursos, entendiendo por recurso un fichero binario, una clave de Registro, un manifiesto (fichero XML con extensión .manifest), etc. Esta jerarquía ha facilitado enormemente la implementación de Windows Vista, tanto para el usuario final, como para Microsoft. Sin embargo, hay ocasiones en las que los componentes del sistema operativo, pese a estar protegidos por WRP (Windows Resource Protection, tema que se tratará en un posterior artículo), se dañan, produciendo comportamientos negativos de lo más variado, como por ejemplo impedir la instalación de una actualización o de un Service Pack. La herramienta Sfc.exe en Windows Vista comprueba la consistencia de dos aspectos del sistema operativo a través del proceso TrustedInstaller.exe (“Instalador confiable”):

  • Los componentes del sistema operativo.
  • Los controladores Plug and Play del sistema operativo (almacén DMI).

Comprobación de los componentes del sistema operativo

En primer lugar se debe comentar que Sfc.exe solo puede reparar componentes que no sean del tipo SxS (Side-by-Side). Este artículo no pretende explicar en qué consisten los componentes SxS, en la web de MSDN dispone de información sobre esta funcionalidad que tantos quebraderos de cabeza da a los desarrolladores de aplicaciones. Para determinar si un componente está dañado o no, se comprueba su manifiesto y los ficheros que lo forman. Si el manifiesto estuviera dañado o no existiera, el sistema aún puede recuperarlo desde el backup, el directorio %windir%\winsxs\Backup. Si esto ocurre y la recuperación se realiza con éxito, el fichero CBS.log del directorio %windir%\Logs\CBS\ registra una línea similar a “[SR] Recovered manifest […] from backup”.

Una vez que los manifiestos han sido verificados y, en caso necesario, reparados, se procede a analizar los binarios que forman el componente. Antes de seguir, conviene explicar que un componente puede presentar varios estados en el sistema operativo:

  • Ausente: Ni siquiera los manifiestos del componente están presentes en el sistema.
  • Resuelto: Los manifiestos están presentes en el equipo, pero los ficheros no.
  • Staged: Los ficheros y manifiestos están presentes, pero aún no han sido proyectados (es decir, el sistema operativo no los está usando).
  • Instalado: Los ficheros y manifiestos están correctamente instalados en el sistema.

Para saber si el componente que está siendo analizado por Sfc está en el estado staged o alguno más avanzado, se examina la clave de Registro HKEY_LOCAL_MACHINE\COMPONENTS\DerivedData\Components. Los valores que comienzan por “c!” hacen referencia a componentes y los que comienzan por “f!” hacen referencia a archivos.

El hash del fichero se compara con el que está presente en el manifiesto y, en caso de que no coincidieran, se intenta recuperar el binario desde el almacén (%windir%\winsxs\). Si tampoco fuera posible extraerlo de ahí o si también estuviera corrupto, se recurre de nuevo al directorio %windir%\winsxs\Backup\.

Comprobación de los controladores Plug and Play

En esta fase se verifica el estado de los controladores Plug and Play que haya instalados en el sistema. En primer lugar, la lista de dichos controladores se enumera desde la clave de Registro HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Setup\PnPLockDownFiles. La comprobación de cada uno de los controladores se realiza contra el correspondiente catálogo presente en el almacén de catálogos (Catroot). Si el controlador estuviera corrupto, se intenta extraer una copia desde el almacén de controladores (%windir%\inf), almacén que contiene los controladores incluidos de serie en una instalación de Windows Vista.

Como ve, el comando Sfc.exe funciona de manera completamente diferente en Windows XP y en Windows Vista. Debido a la nueva arquitectura basada en componentes, en ocasiones esta utilidad va a reportarnos en el fichero CBS.log que no ha sido capaz de solucionar los problemas de consistencia del sistema operativo. Si el almacén de componentes estuviera corrupto, puede probar con la utilidad System Update Readiness, si es que Windows Update no se la ha ofrecido ya. Si aún así siguiera el problema, habrá que examinar con paciencia el fichero CBS.log y determinar el lugar exacto donde está la inconsistencia. A partir de ahí, podría intentarse la extracción desde la imagen WIM presente en el DVD de Windows Vista, proceso que, si bien es arduo y laborioso, nos puede ahorrar una instalación limpia de Windows Vista. Quizá explique este procedimiento en un próximo artículo.

Leave a Reply

Your email address will not be published. Required fields are marked *