October 2008 - Posts
Este martes 27 de octubre, Microsoft dio a conocer en la conferencia PDC una versión "pre-beta" de lo que será su próximo sistema operativo, Windows 7. A estas alturas del ciclo de desarrollo aún es pronto para ver lo que nos va a ofrecer el nuevo sistema, si bien es claro que no representará un cambio tan importante como lo fue el paso de XP a Vista. En esta ocasión, Microsoft se ha basado en los numerosos cambios arquitectónicos que ocurrieron con Windows Vista y se ha centrado en asegurarse de que funcionen lo mejor posible.
Por supuesto, hay algunas novedades que merece la pena resaltar:
- Un centro de problemas y soluciones mucho más refinado con respecto a Windows Vista.
- Soporte Bluetooth mejorado.
- Una nueva barra de tareas mucho más intuitiva.
- La interfaz de usuario es más sencilla de utilizar y las opciones de configuración están más a la vista.
- Reconocimiento táctil y de escritura.
- Control de cuentas de usuario (UAC) proporciona más información para ayudarle a decidir al usuario.
- Soporte nativo de imágenes de CD/DVD.
- Creación por defecto de una partición separada para los ficheros de arranque.
Alguna de estas nuevas funcionalidades, y otras más, serán descritas en próximos artículos. Por supuesto, si tiene alguna inquietud sobre Windows 7 puede mandar un mensaje como comentario a esta entrada o utilizar la página "Contact" del blog.
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.
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.