Windows Vista improves system reliability and your ability to diagnose system and application problems with many new features and improvements. For example, the kernel Windows Event Tracking (ETW) logger is always running and can generate trace events about files, registries, interrupts, and other activity types, and save them in a circular buffer. When a problem occurs, the new Windows Diagnostic Infrastructure (WDI) captures the buffer snapshot and performs a local analysis or upload to Microsoft Support for troubleshooting. The new Windows Performance and Stability Monitor helps users correlate errors (such as crashes and hangs) with each other by changing the system configuration. A powerful System Repair Tool (SRT) replaces the Recovery Console for offline recovery of non-bootable systems. There are three aspects that rely on kernel-level changes to the system, which are the following aspects of the article that you need to read carefully: Kernel Transaction Manager (KTM), improved crash handling, and previous versions. 1. Kernel Transaction Manager One of the most cumbersome aspects of software development is dealing with error conditions. In particular, during advanced operations, the application completes one or more subtasks that cause file system or registry changes. For example, an application's software update service might have to make several registry updates, replace one of the application's executables, and be denied access when it tries to update the second executable. If the service does not want to leave the application in the resulting inconsistent state, it must track all changes and be prepared to revoke them. Testing error recovery code is difficult and often skips, so restoring errors in the code can make efforts in vain. Applications written for Windows Vista can achieve automatic error resilience with minimal effort by using new transaction support in NTFS and using the registry of the kernel transaction manager. When an application wants to make many related changes, you can create Distributed Transaction Coordinator (DTC) transactions and KTM transactions, or create KTM processing directly, and associate modifications to files and registry keys to transactions. If all changes are successful, the application commits the transaction and the changes take effect, but at any time before, the application can roll back the transaction and then discard the changes. The advantage is that other applications can see changes in the transaction after committing the transaction, and applications that use DTC in Windows Vista and the upcoming Windows Server (codenamed "Longhorn") will pass SQL Server, Microsoft. The Message Queue Server (MSMQ) and other databases coordinate their transactions. Therefore, an application update service that uses KTM transactions never leaves the application in an inconsistent state. This is why Windows Update and System Restore use transactions. As the core of transaction support, KTM allows transactional resource managers such as NTFS and the registry to coordinate their updates to specific changes made by the application. In Windows Vista, NTFS uses an extension called TxF to support transactions. The registry uses a similar extension called TxR. These kernel-mode resource managers coordinate transaction state with KTM, just as user-mode resource managers use DTC to coordinate transaction state across multi-user mode resource managers. Third parties can also implement their own resource manager using KTM. Both TxF and TxR define a new set of file system and registry APIs (similar to existing ones, except that they contain transaction parameters). If the application wants to create a file in a transaction, first create a transaction using KTM and then pass the resulting transaction to the new file creation API. Both TxF and TxR rely on the common journaling file system introduced in Windows Server 2003 R2 or the high-speed file system logging feature of CLFS (%SystemRoot%\\System32\\Clfs.sys). TxR and TxF use CLFS to permanently store transaction state changes before committing a transaction. This allows them to provide transaction recovery and ensure recovery even in the event of a power outage. In addition to the CLFS logs, TxR creates a set of related log files that track transactional changes to the system registry files in %Systemroot%\\System32\\Config\\Txr (as shown in Figure 1), as well as for each user registry configuration. The unit creates several sets of log files separately. TxF stores transaction data for each volume in a hidden directory of a volume named \\$Extend\\$RmMetadata. 2. Enhanced crash support When Windows encounters an unrecoverable kernel mode error (either due to device driver errors, hardware failures, or operating system issues), there is a "blue screen of death" phenomenon and some or all of the physical memory After writing to the crash dump file (if configured to do so), it attempts to terminate the system to prevent corruption of the disk data. Dump files are useful because when you restart after a system crash, the Microsoft Online Crash Analysis (OCA) service analyzes these files to find the root cause. If you prefer, you can also analyze it yourself using the Microsoft debugging tools for Windows. However, in previous versions of Windows, support for crash dump files was only enabled after the Session Manager (%Systemroot%\\System32\\Smss.exe) process initialized the paging file. This means that any serious errors before this will result in a blue screen, but no dump files. Because a large number of device driver initializations occur before Smss.exe starts, early crashes never cause crash dumps, making diagnosis of the cause extremely difficult. Windows Vista reduces the time window for dump-free file generation by initializing dump file support after all boot-start device drivers are initialized, but before the system boot driver is loaded. Because of this change, if a crash occurs at the beginning of the boot process, the system can capture the crash dump and let OCA help you solve the problem. In addition, Windows Vista uses 64KB blocks to store data into dump files, while previous versions of Windows used 4KB blocks to write files. This change allows a large dump file to be written up to 10 times faster. Application crash handling has also been improved in Windows Vista. In previous versions of Windows, when an application crashed, it executed an unhandled exception handler. The handler starts the Microsoft Application Error Reporting (AER) process (%Systemroot%\\System32\\Dwwin.exe), displays a dialog box indicating that the program crashes, and asks if you want to send an error report to Microsoft. However, if the stack of the main thread of the process is corrupted during the crash, the unhandled exception handler will crash when executed, causing the kernel to terminate the process, the program window disappears immediately, and there is no error reporting window. Windows Vista moves error handling from the context of the crash process to the new service, Windows Error Reporting (WER). This service is implemented by a DLL (%Systemroot%\\System32\\Wersvc.dll) in the service hosting process. When the application crashes, it still executes the unhandled exception handler, but the handler sends a message to the WER service and the service starts the WER error reporting process (%Systemroot%\\System32\\Werfault.exe) to display the error. Report dialog. If the stack is corrupt and the unhandled exception handler crashes, the handler will execute again and crash again, eventually consuming the stack of all threads (using the memory region), at which point the kernel will intervene and send a crash notification message to the service.