Windows Vista mejora la confiabilidad del sistema y su capacidad para diagnosticar problemas del sistema y las aplicaciones con muchas características y mejoras nuevas. Por ejemplo, el registrador de seguimiento de eventos de Windows (ETW) del kernel siempre se está ejecutando y puede generar eventos de seguimiento sobre archivos, registros, interrupciones y otros tipos de actividad, y guardarlos en un búfer circular. Cuando se produce un problema, la nueva infraestructura de diagnóstico de Windows (WDI) captura la instantánea del búfer y realiza un análisis local o carga al soporte de Microsoft para solucionar problemas. El nuevo Monitor de rendimiento y estabilidad de Windows ayuda a los usuarios a correlacionar errores, como bloqueos y bloqueos al cambiar la configuración del sistema. Una potente herramienta de reparación del sistema (SRT) reemplaza la Consola de recuperación para la recuperación fuera de línea de los sistemas que no se pueden iniciar. Hay tres aspectos que dependen de los cambios en el nivel del kernel al sistema, que son los siguientes aspectos del artículo que debe leer con atención: Kernel Transaction Manager (KTM), manejo mejorado de fallos y versiones anteriores. 1. Kernel Transaction Manager Uno de los aspectos más complicados del desarrollo de software es lidiar con las condiciones de error. En particular, durante las operaciones avanzadas, la aplicación completa una o más subtareas que causan cambios en el sistema de archivos o en el registro. Por ejemplo, el servicio de actualización de software de una aplicación podría tener que realizar varias actualizaciones de registro, reemplazar uno de los ejecutables de la aplicación y tener acceso denegado cuando intenta actualizar el segundo ejecutable. Si el servicio no desea dejar la aplicación en el estado incoherente resultante, debe realizar un seguimiento de todos los cambios y estar preparado para revocarlos. Probar el código de recuperación de errores es difícil y con frecuencia se omite, por lo que la restauración de errores en el código puede hacer esfuerzos en vano. Las aplicaciones escritas para Windows Vista pueden lograr una capacidad de recuperación automática de errores con un mínimo esfuerzo al usar el nuevo soporte de transacciones en NTFS y al registro del administrador de transacciones del núcleo. Cuando una aplicación desea realizar una serie de cambios relacionados, puede crear transacciones de Coordinador de transacciones distribuidas (DTC) y transacciones KTM, o crear un procesamiento KTM directamente, y asociar modificaciones a los archivos y claves de registro a las transacciones. Si todos los cambios son exitosos, la aplicación confirma la transacción y los cambios surten efecto, pero en cualquier momento anterior, la aplicación puede revertir la transacción y luego descartar los cambios. La ventaja es que otras aplicaciones pueden ver cambios en la transacción después de confirmar la transacción, y las aplicaciones que usan DTC en Windows Vista y el próximo Windows Server (con nombre en código "Longhorn") pasarán a SQL Server, Microsoft. El Servidor de colas de mensajes (MSMQ) y otras bases de datos coordinan sus transacciones. Por lo tanto, un servicio de actualización de aplicaciones que utiliza transacciones KTM nunca deja la aplicación en un estado incoherente. Es por esto que Windows Update y System Restore usan transacciones. Como el núcleo del soporte de transacciones, KTM permite a los administradores de recursos transaccionales, como NTFS y el registro, coordinar sus actualizaciones a los cambios específicos realizados por la aplicación. En Windows Vista, NTFS usa una extensión llamada TxF para admitir transacciones. El registro utiliza una extensión similar llamada TxR. Estos administradores de recursos en modo kernel coordinan el estado de transacción con KTM, al igual que los administradores de recursos en modo de usuario usan DTC para coordinar el estado de transacción en los administradores de recursos en modo multiusuario. Los terceros también pueden implementar su propio administrador de recursos utilizando KTM. Tanto TxF como TxR definen un nuevo conjunto de API de registro y sistema de archivos (similares a los existentes, excepto que contienen parámetros de transacción). Si la aplicación desea crear un archivo en una transacción, primero cree una transacción con KTM y luego pase la transacción resultante a la nueva API de creación de archivos. Tanto TxF como TxR se basan en el sistema de archivos de registro en diario común introducido en Windows Server 2003 R2 o en la función de registro de sistema de archivos de alta velocidad de CLFS (% SystemRoot% \\ System32 \\ Clfs.sys). TxR y TxF utilizan CLFS para almacenar permanentemente los cambios en el estado de la transacción antes de realizar una transacción. Esto les permite proporcionar recuperación de transacciones y asegurar la recuperación incluso en caso de un corte de energía. Además de los registros CLFS, TxR crea un conjunto de archivos de registro relacionados que rastrean los cambios transaccionales en los archivos de registro del sistema en% Systemroot% \\ System32 \\ Config \\ Txr (como se muestra en la Figura 1), así como para cada registro de usuarios. La unidad crea varios conjuntos de archivos de registro por separado. TxF almacena datos de transacciones para cada volumen en un directorio oculto de un volumen llamado \\ $ Extend \\ $ RmMetadata. 2. Compatibilidad con fallos mejorada Cuando Windows encuentra un error de modo de núcleo no recuperable (ya sea debido a errores del controlador del dispositivo, fallos de hardware o problemas del sistema operativo), existe un fenómeno de "pantalla azul de la muerte" y parte o toda la memoria física. Después de escribir en el archivo de volcado de caída (si está configurado para hacer esto), intenta terminar el sistema para evitar la corrupción de los datos del disco. Los archivos de volcado son útiles porque cuando se reinicia después de una caída del sistema, el servicio de Análisis de Accesos en Línea de Microsoft (OCA) analiza estos archivos para encontrar la causa raíz. Si lo prefiere, también puede analizarlo usted mismo utilizando las herramientas de depuración de Microsoft para Windows. Sin embargo, en versiones anteriores de Windows, la compatibilidad con los archivos de volcado de bloqueo solo se habilitaba después de que el proceso del Administrador de sesiones (% Systemroot% \\ System32 \\ Smss.exe) inicializara el archivo de paginación. Esto significa que cualquier error grave antes de esto dará como resultado una pantalla azul, pero no archivos de volcado. Debido a que se produce una gran cantidad de inicializaciones de controladores de dispositivo antes de que se inicie Smss.exe, los bloqueos tempranos nunca causan volcados, lo que hace que el diagnóstico de la causa sea extremadamente difícil. Windows Vista reduce la ventana de tiempo para la generación de archivos sin volcado al inicializar la compatibilidad con archivos de volcado después de que se hayan inicializado todos los controladores de dispositivos de inicio, pero antes de que se cargue el controlador de inicio del sistema. Debido a este cambio, si se produce un bloqueo al comienzo del proceso de arranque, el sistema puede capturar el volcado de caída y dejar que OCA lo ayude a resolver el problema. Además, Windows Vista usa bloques de 64KB para almacenar datos en archivos de volcado, mientras que las versiones anteriores de Windows usaban bloques de 4KB para escribir archivos. Este cambio permite escribir 10 veces más rápido en archivos de volcado grandes. El manejo de bloqueos de aplicaciones también se ha mejorado en Windows Vista. En versiones anteriores de Windows, cuando una aplicación fallaba, ejecutaba un controlador de excepciones no manejado. El controlador inicia el proceso de Informe de errores de aplicación (AER) de Microsoft (% Systemroot% \\ System32 \\ Dwwin.exe), muestra un cuadro de diálogo que indica que el programa se bloqueó y le pregunta si desea enviar un informe de errores a Microsoft. Sin embargo, si la pila del subproceso principal del proceso se daña durante el bloqueo, el controlador de excepciones no gestionado se bloqueará cuando se ejecute, lo que provocará que el kernel finalice el proceso, la ventana del programa desaparecerá de inmediato y no habrá ninguna ventana de informe de errores. Windows Vista traslada el manejo de errores del contexto del proceso de bloqueo al nuevo servicio, Informe de errores de Windows (WER). Este servicio se implementa mediante una DLL (% Systemroot% \\ System32 \\ Wersvc.dll) en el proceso de hospedaje del servicio. Cuando la aplicación falla, aún ejecuta el controlador de excepciones no manejado, pero el controlador envía un mensaje al servicio WER y el servicio inicia el proceso de informe de errores WER (% Systemroot% \\ System32 \\ Werfault.exe) para mostrar el error. Informe de diálogo. Si la pila está dañada y el manejador de excepciones no manejado se bloquea, el manejador se ejecutará nuevamente y se bloqueará nuevamente, consumiendo finalmente la pila de todos los subprocesos (usando la región de memoria), en cuyo punto el kernel intervendrá y enviará un mensaje de notificación de fallos al servicio.