Windows Vista通过许多新功能和改进提高了系统的可靠性和您对系统与应用程序问题的诊断能力。例如，内核Windows事件跟踪 (ETW) 记录程序总是处于运行状态，能够生成有关文件、注册表、中断以及其他活动类型的跟踪事件，并保存在循环缓冲区中。当出现问题时，新的 Windows 诊断基础结构 (WDI) 会捕获缓冲区快照，并进行本地分析或上载到 Microsoft 支持进行故障排除。
新的 Windows 性能和稳定性监视器可以帮助用户通过更改系统配置将错误（如崩溃和挂起）相互关联。强大的系统修复工具 (SRT) 取代了故障恢复控制台，用于不可启动系统的离线恢复。
有三个方面依靠对系统进行的内核级更改，即需要您认真阅读的本文中的以下方面：内核事务管理器 (KTM)、改进的崩溃处理和以前的版本。
1.内核事务管理器
软件开发中最繁琐的一个方面就是处理错误条件。特别是在进行高级操作的过程中，应用程序完成了一个或多个导致文件系统或注册表更改的子任务。例如，应用程序的软件更新服务可能要进行几次注册表更新，替换应用程序的可执行文件之一，而在它尝试更新第二个可执行文件时被拒绝访问。如果服务不想将应用程序留在因此导致的不一致状态，就必须跟踪所有更改并为撤销它们做好准备。测试错误恢复代码很困难，并经常跳过，因此恢复代码中的错误会让努力徒劳无功。
为 Windows Vista 编写的应用程序通过使用 NTFS 中新的事务支持和使用内核事务管理器的注册表，不费吹灰之力即可获得自动错误恢复能力。当应用程序想进行许多相关更改时，可以创建分布式事务处理协调器 (DTC) 事务和 KTM 事务处理，或直接创建 KTM 处理，并将对文件和注册表项的修改与事务关联起来。如果所有的更改成功，应用程序会提交事务同时更改生效，但是在此之前任何时候，应用程序可以回滚事务，然后放弃更改。
其有利因素在于，其他应用程序在提交事务后才能看到事务中的更改，而在 Windows Vista 和即将问世的 Windows Server（代号名为“Longhorn”）中使用 DTC 的应用程序会通过 SQL Server、Microsoft Message Queue Server (MSMQ) 以及其他数据库协调其事务。因此，使用 KTM 事务的应用程序更新服务永远不会将应用程序留在不一致的状态。这就是 Windows Update 和系统还原使用事务的原因。
作为事务支持的核心，KTM 允许事务资源管理器（如 NTFS 和注册表）对应用程序所做的特定更改协调其更新。在 Windows Vista 中，NTFS 使用称为 TxF 的扩展来支持事务。注册表使用称为 TxR 的类似扩展。这些内核模式资源管理器与 KTM 一起协调事务状态，正如用户模式资源管理器使用 DTC 跨多用户模式资源管理器协调事务状态一样。第三方也可以使用 KTM 实施其自己的资源管理器。
TxF 和 TxR 都定义了一套新的文件系统和注册表 API（与现有的类似，只不过它们包含事务参数）。如果应用程序想在事务中创建文件，首先要使用 KTM 创建事务，然后将引起的事务处理传递给新文件创建 API。
TxF 和 TxR 都依赖在 Windows Server 2003 R2 中引入的公用日志文件系统或 CLFS (%SystemRoot%\System32\Clfs.sys) 的高速文件系统记录功能。TxR 和 TxF 使用 CLFS 永久性地存储提交事务之前的事务状态更改。这样可以让它们提供事务恢复并确保即使在断电时也可以恢复。除了 CLFS 日志，TxR 还创建了一组相关的日志文件，跟踪 %Systemroot%\System32\Config\Txr 中系统注册表文件的事务更改（如图 1 所示），同时还为每个用户注册表配置单元单独创建几组日志文件。TxF 在名为 \$Extend\$RmMetadata 的卷的隐藏目录中存储每个卷的事务数据。
2.增强的崩溃支持
当 Windows 遇到不可恢复的内核模式错误时（无论是由于设备驱动程序错误、硬件故障还是操作系统问题），在出现“蓝屏死机”现象和将物理内存的部分或所有内容写入崩溃转储文件（如果配置为执行此操作）后，它会尝试终止系统来防止磁盘数据的损坏。转储文件非常有用，因为当您在系统崩溃后重启时，Microsoft 在线崩溃分析 (OCA) 服务会分析这些文件找出根本原因。如果愿意，您也可以使用面向 Windows 的 Microsoft 调试工具自已进行分析。
不过，在以前的 Windows 版本中，只有在会话管理器 (%Systemroot%\System32\Smss.exe) 进程初始化分页文件后才会启用对崩溃转储文件的支持。这意味着在此之前任何严重错误会导致蓝屏，但没有转储文件。由于在 Smss.exe 启动之前，会出现大量的设备驱动程序初始化，所以早期的崩溃永远不会引起崩溃转储，因此使原因诊断极为困难。
在所有引导启动设备驱动程序初始化之后，但在系统启动驱动程序加载之前，Windows Vista 通过初始化转储文件支持，可减少无转储文件生成的时间窗口。由于这一更改，如果在引导过程开始时出现崩溃，系统就可以捕捉崩溃转储，让 OCA 帮助您解决问题。此外，Windows Vista 使用 64KB 块将数据存储到转储文件中，而以前的 Windows 版本使用 4KB 块写入文件。这一更改使得大型转储文件的写入速度最多可提高 10 倍。
应用程序崩溃处理功能在 Windows Vista 中也得以改进。在以前的 Windows 版本中，当应用程序崩溃时，它会执行未处理的异常处理程序。处理程序启动 Microsoft 应用程序错误报告 (AER) 进程 (%Systemroot%\System32\Dwwin.exe)，显示对话框，指明程序崩溃，并询问您是否要向 Microsoft 发送错误报告。不过，如果崩溃时进程主线程的堆栈损坏，未处理的异常处理程序执行时会崩溃，导致内核终止进程、程序窗口立即消失，并且没有错误报告窗口。
Windows Vista 将错误处理从崩溃进程的上下文移至新服务，即 Windows 错误报告 (WER)。此服务由服务托管进程中的 DLL (%Systemroot%\System32\Wersvc.dll) 实施。在应用程序崩溃时，它仍然会执行未处理的异常处理程序，但是该处理程序会向 WER 服务发送消息，并且服务会启动 WER 错误报告进程 (%Systemroot%\System32\Werfault.exe) 以显示错误报告对话框。如果堆栈损坏并且未处理的异常处理程序崩溃，处理程序会再次执行并且再次崩溃，最终消耗所有线程的堆栈（使用内存区域），此时内核会介入，并向服务发送崩溃通知消息。
Windows Vista通过许多新功能和改进提高了系统的可靠性和您对系统与应用程序问题的诊断能力。例如，内核Windows事件跟踪 (ETW) 记录程序总是处于运行状态，能够生成有关文件、注册表、中断以及其他活动类型的跟踪事件，并保存在循环缓冲区中。当出现问题时，新的 Windows 诊断基础结构 (WDI) 会捕获缓冲区快照，并进行本地分析或上载到 Microsoft 支持进行故障排除。
新的 Windows 性能和稳定性监视器可以帮助用户通过更改系统配置将错误（如崩溃和挂起）相互关联。强大的系统修复工具 (SRT) 取代了故障恢复控制台，用于不可启动系统的离线恢复。
有三个方面依靠对系统进行的内核级更改，即需要您认真阅读的本文中的以下方面：内核事务管理器 (KTM)、改进的崩溃处理和以前的版本。
1.内核事务管理器
软件开发中最繁琐的一个方面就是处理错误条件。特别是在进行高级操作的过程中，应用程序完成了一个或多个导致文件系统或注册表更改的子任务。例如，应用程序的软件更新服务可能要进行几次注册表更新，替换应用程序的可执行文件之一，而在它尝试更新第二个可执行文件时被拒绝访问。如果服务不想将应用程序留在因此导致的不一致状态，就必须跟踪所有更改并为撤销它们做好准备。测试错误恢复代码很困难，并经常跳过，因此恢复代码中的错误会让努力徒劳无功。
为 Windows Vista 编写的应用程序通过使用 NTFS 中新的事务支持和使用内核事务管理器的注册表，不费吹灰之力即可获得自动错误恢复能力。当应用程序想进行许多相关更改时，可以创建分布式事务处理协调器 (DTC) 事务和 KTM 事务处理，或直接创建 KTM 处理，并将对文件和注册表项的修改与事务关联起来。如果所有的更改成功，应用程序会提交事务同时更改生效，但是在此之前任何时候，应用程序可以回滚事务，然后放弃更改。
其有利因素在于，其他应用程序在提交事务后才能看到事务中的更改，而在 Windows Vista 和即将问世的 Windows Server（代号名为“Longhorn”）中使用 DTC 的应用程序会通过 SQL Server、Microsoft Message Queue Server (MSMQ) 以及其他数据库协调其事务。因此，使用 KTM 事务的应用程序更新服务永远不会将应用程序留在不一致的状态。这就是 Windows Update 和系统还原使用事务的原因。
作为事务支持的核心，KTM 允许事务资源管理器（如 NTFS 和注册表）对应用程序所做的特定更改协调其更新。在 Windows Vista 中，NTFS 使用称为 TxF 的扩展来支持事务。注册表使用称为 TxR 的类似扩展。这些内核模式资源管理器与 KTM 一起协调事务状态，正如用户模式资源管理器使用 DTC 跨多用户模式资源管理器协调事务状态一样。第三方也可以使用 KTM 实施其自己的资源管理器。
TxF 和 TxR 都定义了一套新的文件系统和注册表 API（与现有的类似，只不过它们包含事务参数）。如果应用程序想在事务中创建文件，首先要使用 KTM 创建事务，然后将引起的事务处理传递给新文件创建 API。
TxF 和 TxR 都依赖在 Windows Server 2003 R2 中引入的公用日志文件系统或 CLFS (%SystemRoot%\System32\Clfs.sys) 的高速文件系统记录功能。TxR 和 TxF 使用 CLFS 永久性地存储提交事务之前的事务状态更改。这样可以让它们提供事务恢复并确保即使在断电时也可以恢复。除了 CLFS 日志，TxR 还创建了一组相关的日志文件，跟踪 %Systemroot%\System32\Config\Txr 中系统注册表文件的事务更改（如图 1 所示），同时还为每个用户注册表配置单元单独创建几组日志文件。TxF 在名为 \$Extend\$RmMetadata 的卷的隐藏目录中存储每个卷的事务数据。
2.增强的崩溃支持
当 Windows 遇到不可恢复的内核模式错误时（无论是由于设备驱动程序错误、硬件故障还是操作系统问题），在出现“蓝屏死机”现象和将物理内存的部分或所有内容写入崩溃转储文件（如果配置为执行此操作）后，它会尝试终止系统来防止磁盘数据的损坏。转储文件非常有用，因为当您在系统崩溃后重启时，Microsoft 在线崩溃分析 (OCA) 服务会分析这些文件找出根本原因。如果愿意，您也可以使用面向 Windows 的 Microsoft 调试工具自已进行分析。
不过，在以前的 Windows 版本中，只有在会话管理器 (%Systemroot%\System32\Smss.exe) 进程初始化分页文件后才会启用对崩溃转储文件的支持。这意味着在此之前任何严重错误会导致蓝屏，但没有转储文件。由于在 Smss.exe 启动之前，会出现大量的设备驱动程序初始化，所以早期的崩溃永远不会引起崩溃转储，因此使原因诊断极为困难。
在所有引导启动设备驱动程序初始化之后，但在系统启动驱动程序加载之前，Windows Vista 通过初始化转储文件支持，可减少无转储文件生成的时间窗口。由于这一更改，如果在引导过程开始时出现崩溃，系统就可以捕捉崩溃转储，让 OCA 帮助您解决问题。此外，Windows Vista 使用 64KB 块将数据存储到转储文件中，而以前的 Windows 版本使用 4KB 块写入文件。这一更改使得大型转储文件的写入速度最多可提高 10 倍。
应用程序崩溃处理功能在 Windows Vista 中也得以改进。在以前的 Windows 版本中，当应用程序崩溃时，它会执行未处理的异常处理程序。处理程序启动 Microsoft 应用程序错误报告 (AER) 进程 (%Systemroot%\System32\Dwwin.exe)，显示对话框，指明程序崩溃，并询问您是否要向 Microsoft 发送错误报告。不过，如果崩溃时进程主线程的堆栈损坏，未处理的异常处理程序执行时会崩溃，导致内核终止进程、程序窗口立即消失，并且没有错误报告窗口。
Windows Vista 将错误处理从崩溃进程的上下文移至新服务，即 Windows 错误报告 (WER)。此服务由服务托管进程中的 DLL (%Systemroot%\System32\Wersvc.dll) 实施。在应用程序崩溃时，它仍然会执行未处理的异常处理程序，但是该处理程序会向 WER 服务发送消息，并且服务会启动 WER 错误报告进程 (%Systemroot%\System32\Werfault.exe) 以显示错误报告对话框。如果堆栈损坏并且未处理的异常处理程序崩溃，处理程序会再次执行并且再次崩溃，最终消耗所有线程的堆栈（使用内存区域），此时内核会介入，并向服务发送崩溃通知消息。