深入Windows Vista 内核

　Mark Russinovich 是 Microsoft 平台和服务部门的技术人员。他是《Microsoft Windows Internals》（Microsoft Windows 内部结构）(Microsoft Press, 2004) 的合著者之一，并经常在 IT 和开发人员会议上演讲。

　　这是系列文章的第一部分，探讨的是 Windows Vista 内核中的新增内容。在这一期中，将着重说明在进程、线程和 I/O 方面的更改；在将来几期内容中将涉及到内存管理、启动和关闭、可靠性和恢复以及安全性方面的内容。

　　本文的范围仅限于对 Windows Vista™ 内核的更改，尤其是对 Ntoskrnl.exe 和与其紧密关联的组件的更改。请记住，在 Windows Vista 中还存在许多其他重大更改，但这些却超出了内核的范围，因此本文将不予以说明。其中包括对外壳（如集成的桌面搜索）、网络（如新的 IPv6 堆栈和双向防火墙）和下一代图形模型（如 Aero™ Glass、Windows® Presentation Foundation、桌面窗口管理器和新图形驱动程序模型）的改进。而且未涉及的内容还包括新的 Windows 用户模式和内核模式驱动程序框架（UMDF 和 KMDF），因为在较早的 Windows 版本上它们在后级别才是可安装的。

CPU 时钟周期计数

　　Windows Vista 包含了进程和线程方面的大量增强功能，其中包括使用 CPU 时钟周期计数器以较公平地进行 CPU 分配，以及使用新的多媒体类计划程序服务 (MMCSS)，它有助于媒体应用程序提供稳定的播放。

　　所有 Windows NT® 版本，包括 Windows Vista 程序在内，大约在每 10 ms 或 15 ms（毫秒）执行一次间隔计时器中断例程，间隔取决于硬件平台。该例程查看它所中断的线程并更新线程的 CPU 使用统计数据，就好像该线程在整个间隔期间都在运行，而事实上，线程可能仅在间隔就要结束前才开始执行。而且，从技术上讲，可能已经为线程分配了 CPU，但却一直没有机会运行，因为执行的是硬件和软件中断例程。

　　虽然对于报告线程和进程 CPU 使用情况的诊断工具来说，基于时钟的时间计算是一个好方法，但是，若由线程计划程序使用该方法将导致不公平的 CPU 分配。默认情况下，Windows 客户端版本上的线程最多可运行 2 个时钟节拍（如果是在前台中运行则为 6 个时钟节拍）。然而，根据线程在系统上的行为和其他活动，线程实际上可能在 CPU 上根本没有时间或是最多得到 6 个时钟节拍（如果是在前台中运行则为 18 个时钟节拍）。
　　
　　图 1 显示了两个具有相同优先级的线程同时准备好运行时发生的不公平情况。计划程序假定线程 A 在整个间隔期间内运行时，线程 A 一直运行到下一时间片间隔过期，因此也就可以确定线程 A 已运行完毕。而且，在线程 A 运行期间发生的中断应由线程 A 完全负责。在下一间隔内，计划程序挑选线程 B 来接续，并且要在整个间隔内运行。

图 1 不公平的线程计划

　　在 Windows Vista 中，计划程序使用现代处理器的时钟周期计数器寄存器精确地跟踪线程所执行的 CPU 时钟周期数。通过估计 CPU 在一个时钟间隔内能够执行的时钟周期数，它可以更准确地在 CPU 上布置轮循。另外，Windows Vista 计划程序不会根据线程的轮循计数中断执行。这就意味着，在 Windows Vista 上，线程始终会得到至少一次在 CPU 上运行的机会，而且永远不会执行多个额外时钟间隔，这使应用程序的行为更公平，也更具确定性。图 2 显示了 Windows Vista 如何响应图 1 中所示的情况，方法是为两个线程提供至少一个时间片的执行间隔。

图 2 Windows Vista 基于时钟周期的计划

　　“查看进程的 CPU 使用情况”边栏说明了用户如何通过使用 Process Explorer 实用工具监视进程的 CPU 时钟周期使用情况。

多媒体类计划程序服务

　　用户期望多媒体应用程序（包括音乐和视频播放器）能够提供无缝的播放体验。然而，其他同时运行的应用程序（如防病毒、内容索引甚至是邮件客户端）对 CPU 的要求会带来不和谐的因素。为了提供更佳的播放体验，Windows Vista 引入 MMCSS 来管理多媒体线程的 CPU 优先级。
　　像 Windows Media® Player 11 这样的多媒体应用程序使用能够表明其多媒体特性的新 API，通过 MMCSS 进行注册，它必须与下列按名称排列的注册表项之一匹配： HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\Tasks
　　
　　各种任务注册表项可指定与不同多媒体类型相关联的线程为 CPU 和图形处理器资源获取的首选级别（尽管在 Windows Vista 中未实现图形处理器资源管理）。图 3 显示了在干净安装 Windows Vista 后其中一个任务注册表项的内容，尽管第三方开发人员能够添加自己的任务定义。

图 3 多媒体类计划程序音频任务定义

　　在 %SystemRoot%\System32\Mmcss.dll 中实现且在服务主机 (Svchost.exe) 进程中运行的 MMCSS 具有可在优先级 27 运行的优先级管理线程。（Windows 中线程优先级的范围是从 0 到 31。）此线程将已注册的多媒体线程的优先级推进到另一个范围内，该范围与任务注册表项（如图 4 所示）的计划类别值相关联。在 Windows 中，线程优先级 16 及更高级别处在实时优先级范围内并且高于系统上的其他所有线程（除了内核的内存管理器工作线程，该线程在优先级 28 和 29 运行）。仅管理帐户（如执行 MMCSS 的“本地系统”帐户）具有设置实时线程优先级所需的提升优先级权限。

　　在播放音频文件时，Windows Media Player 注册音频任务线程；在播放视频时，Windows Media Player 注册播放任务线程。对于已经指明它们在拥有前台窗口的进程中运行时并且在将任务的定义注册表项中的 BackgroundOnly 值设置为 True 时将同时传递流的所有线程，MMCSS 服务会对其进行提升。
但是在 MMCSS 想要帮助多媒体线程获得所需的 CPU 时间的同时，它还想确保其他线程至少也能获得一些 CPU 时间，这样，系统和其他应用程序才能保持响应能力。因此，MMCSS 为其他活动保留了一定百分比的 CPU 时间，并在以下注册表值中进行指定： HKLM\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\SystemResponsiveness
　　
　　默认情况下，此比例为 20%；MMCSS 监视 CPU 的使用情况，以确保在其他线程需要 CPU 时，在 10 ms 期间内提升多媒体线程所占的时间不超过 8 ms。为了使多媒体线程不占用剩下的 2 ms，计划程序将其优先级设置在 1-7 级的范围内。
您可以通过阅读“查看 MMCSS 优先级提升”边栏了解 MMCSS 是如何提升线程优先级的。

基于文件的符号链接

　　Windows Vista I/O 的相关更改包括基于文件的符号链接、更有效的 I/O 完成处理、对 I/O 取消的全面支持以及优先 I/O。

　　终于在 Windows Vista 中见到符号文件链接（或如在 UNIX 中那样称作软链接）了，许多人认为它是 NTFS 中缺少的文件系统功能。NTFS 的 Windows 2000 版本引入了符号目录链接（称为目录接合），允许用户创建指向其他目录的目录，但是在 Windows Vista 版本发布之前，NTFS 仅支持文件的硬链接。
　　Windows 解决符号链接和目录接合所采用的方式的最大区别在于处理所发生的位置。Windows 在本地系统上处理符号链接，即使它们引用远程文件服务器上的位置。Windows 在服务器本身上处理引用远程文件服务器的目录接合。因此，服务器上的符号链接可以引用仅从客户端才能访问的位置（如其他客户端卷），而目录接合则做不到。为了解决这个问题，Windows Vista 支持适用于文件和目录的新符号链接类型。

　　已经对许多文件系统命令进行了更新，以了解符号链接的含义。例如，Delete 命令知道不要跟随链接（这样会导致目标的删除），而是要删除链接。然而，由于不是所有的应用程序都能正确地处理符号链接，因此，创建符号链接需要新的创建符号链接权限，而默认情况下，仅有管理员才具有该权限。

　　您可以在命令提示符下使用 Mklink 命令创建符号链接。命令提示符的内置目录命令通过用 <SYMLINK> 标记符号链接并在括号中显示目标的方式标识符号链接，如图 5 中所示。Windows 资源管理器也可识别符号链接，并使用快捷方式箭头显示。可以通过将“链接目标”列添加到浏览窗口中来查看资源管理器中的链接目标。

图 5 使用 Mklink 创建符号链接

I/O 完成和取消

　　对 I/O 系统所做的大量更改可改进服务器应用程序的性能。这些应用程序通常使用称为完成端口的同步对象来等待异步 I/O 请求的完成。在 Windows Vista 之前，当此类 I/O 完成时，已发布 I/O 的线程将执行 I/O 完成工作，这可切换到线程所属的进程并中断所有正在进行的其他工作。然后，I/O 系统将更新完成端口的状态，以唤醒正在等待完成端口进行状态更改的线程。

　　在 Windows Vista 上，I/O 完成处理不必非由已发布 I/O 的线程执行，但是必须由等待完成端口将其唤醒的线程来执行。这个相对较小的更改避免了不必要的线程计划以及可能造成应用程序和系统整体性能下降的上下文切换。为了进一步提高性能，服务器可以从一个请求的完成中检索多个 I/O 操作的结果，避免转换到内核模式。

　　从最终用户的角度来看，I/O 系统中最可见的更改可能是 Windows Vista 所支持的取消同步 I/O 操作。如果曾经执行过 net view 命令或试图使用 Windows XP 或 Windows Server® 2003 访问过脱机远程系统的共享，您就已经体验到了无法取消的 I/O 操作问题：直到网络超时过期后，命令或文件浏览器才能响应。应用程序没有选择，只能等待，直至操作失败，因为它没有办法告知正在执行 I/O 的设备驱动程序不需再理会 I/O 了。

　　在 Windows Vista 中，大多数 I/O 操作都可以取消，包括 Net View 和资源管理器使用的打开文件 I/O。然而，必须更新应用程序以响应最终用户的取消 I/O 请求，而且许多与具有超时设置的设备进行交互的 Windows Vista 实用工具已得到必要的支持。例如，实际上由每个 Windows 应用程序（包括第三方应用程序）使用的文件打开和保存对话框现在允许在试图显示文件夹内容时启用“取消”按钮。在按 Ctrl+C 时，Net 命令也可取消其同步 I/O。
可以通过在 Windows Vista 上打开命令提示符并键入以下内容来查看 I/O 取消所带来的好处： net view (\\nonexistentmachine)
　　
　　在 Windows 试图联系不存在的系统时该命令将挂起，但可以通过键入 Ctrl+C 来终止该命令。在 Windows XP 中，Ctrl+C 不会产生影响，并且直到网络操作超时后命令才会返回。

　　在 Windows 以前的版本中会引发用户问题的另一类 I/O 就是设备驱动程序不能正确取消的 I/O，因为设备驱动程序轻易不会知道它们应该这样做。如果曾经终止过进程，但随后发现它在进程查看工具中有所延迟，那么，您已经亲眼目睹了设备驱动程序无法对进程终止做出响应，并且取消由未完成进程发布的 I/O 这两个过程。直到所有进程的 I/O 已经完成或已被取消，Windows 才能执行最终进程清理。在 Windows Vista 中，设备驱动程序能够很容易地注册进程终止的通知，因此，大多数无法终止的进程问题也就迎刃而解了。

I/O 优先级

　　虽然 Windows 始终支持 CPU 使用情况的排列优先级，但是却未包括 I/O 优先级这一概念。如果没有 I/O 优先级，搜索索引、病毒扫描和磁盘碎片整理等后台活动会对前台操作的响应性带来严重的影响。例如，用户在另一进程正在执行磁盘 I/O 时启动应用程序或打开文档，则该用户将体验到延迟，因为前台任务要等待磁盘访问。同样的干扰也会影响到多媒体内容（如硬盘上的歌曲）流播放的质量。

　　为了有助于前台 I/O 操作获取首选项，Windows Vista 引入了两个全新类型的 I/O 优先级排列：单独 I/O 操作的优先级和 I/O 带宽保留。Windows Vista I/O 系统内部包括对五个 I/O 优先级的支持，如图 6 所示，但是仅使用了四个优先级（Windows 的未来版本可能支持“高”优先级）。

　　I/O 具有“中等”默认优先级，内存管理器想要在低内存情况下将脏内存数据写到磁盘中从而为其他数据和代码在 RAM 中留出空间时，将使用“关键”优先级。Windows Task Scheduler 将具有默认任务优先级的任务 I/O 优先级设置为“低”，并将由执行后台处理的应用程序（为 Windows Vista 而编写）指定的优先级设置为“非常低”。所有 Windows Vista 后台操作（包括 Windows Defender 扫描和桌面搜索索引）均使用“非常低”I/O 优先级。

　　系统存储类设备驱动程序 (%SystemRoot%\System32\Classpnp.sys) 强制使用 I/O 优先级，因此也就自动应用于指向大多数存储设备的 I/O。类和其他存储驱动程序将“中等”I/O 插入到队列内优先级为“低”和“非常低”的 I/O 之前，但是至少应每秒发布一个等待“低”或“非常低”I/O 的操作，这样后台进程才可以向前进行。使用“非常低”I/O 读取数据还会使缓存管理器立刻将修改写入磁盘，并绕过读取操作的预读逻辑，否则它会优先从正在访问的文件中进行读取。请将边栏“查看“非常低”I/O 优先级”作为使用 Process Monitor 实用工具的“非常低”I/O 优先级的示例了解一下。

　　Windows Vista 带宽保留支持对于媒体播放机应用程序非常有用，Windows Media Player 将其连同 MMCSS 优先级提升一起使用，以提供对本机内容近乎稳定的播放体验。媒体播放机应用程序要求 I/O 系统确保它能够以指定速率读取数据，如果设备能够以请求的速率传递数据而且现有保留也允许的情况下，它将针对发布 I/O 的频率以及 I/O 应具有的大小两方面为应用程序提供指导。I/O 系统不会为其他 I/O 提供服务，除非它能够满足在目标存储设备上做出保留的应用程序的要求。

　　在 I/O 系统中值得一提的一个最终更改与 I/O 操作的大小有关。因为第一版 Windows NT、内存管理器和 I/O 系统已将单独存储 I/O 请求所处理的数据数量限制为 64KB。因此，即使应用程序发布了一个更大的 I/O 请求，也会被分解为最大大小为 64KB 的多个请求。每个 I/O 都导致了转换到内核模式的开销并在存储设备上启动 I/O 传输，因此在 Windows Vista 中，存储 I/O 请求大小将不再受限。已对一些 Windows Vista 用户模式组件进行了修改，以利用对更大 I/O 的支持，包括资源管理器的复制功能和命令提示符的 Copy 命令（现在发布 1MB 的 I/O）。

Windows Vista 内存管理器包含了大量增强功能，例如，更大范围地使用无锁同步技术、锁定粒度更细、数据结构包更紧密，分页 I/O 更大、增加了对现代 GPU 内存体系结构的支持，并更有效利用了硬件的转换旁路缓冲器。另外，Windows Vista 内存管理如今还针对不同工作负荷的要求提供动态地址空间分配。
以下四种采用新技术的性能增强型功能首次在 Windows Vista 操作系统上登台亮相：SuperFetch、ReadyBoost、ReadyBoot 和 ReadyDrive。本文稍后将详细讨论这些功能。

动态内核地址空间

      分散Windows 以及其上所运行的应用程序占用的地址空间已经达到了 32 位处理器的地址空间极限。默认情况下，Windows 内核被限制在 2GB，或者是 32 位虚拟地址空间总量的一半，另一半则预留给当前正在 CPU 中运行线程的进程使用。在其自己的那一半虚拟地址空间中，内核必须映射其自身、设备驱动程序、文件系统缓存、内核堆栈、每会话代码数据结构，以及由设备驱动程序分配的非分页（锁定的物理内存）缓冲区和分页缓冲区。在 Windows Vista 推出之前，内存管理器在引导时确定针对这些用途分配多少地址空间，但这种不变性有时会造成其中某一区域空间被占满，而其他区域仍有大量可用空间的情况。区域空间被用尽会导致应用程序出现故障，并会妨碍设备驱动程序完成 I/O 操作。
在 32 位 Windows Vista 中，内存管理器动态管理内核的地址空间，根据工作负荷的具体需求为各种用途分配和释放空间。这样，用于存储分页缓冲区的虚拟内存量会随着设备驱动程序需求量增加而增加，并会在驱动程序释放它时缩小。因此，Windows Vista 将能够处理更大范围的工作负荷，同样，即将推出的代号为“Longhorn”的 32 位版本 Windows Server® 也将升级到可以处理更多的并行终端服务器用户。
当然，在 64 位 Windows Vista 系统上，地址空间约束目前还不属于实质性的限制，因此，在将这些约束配置为相应最大值时，不需要对其进行任何特殊处理。

内存优先级

      就像 Windows Vista 添加 I/O 优先级（如上一部分中所述）一样，它还实现内存优先级。要了解 Windows 如何使用内存优先级，就需要掌握内存管理器如何实现其内存缓存（称为“待机列表”）。在 Windows Vista 之前的所有 Windows 版本中，当某个进程所拥有的物理页面（大小一般为 4KB）被系统回收时，内存管理器通常将该页面置于“待机列表”末尾。如果进程想要再次访问该页面，内存管理器会从“待机列表”获取该页面，然后将其重新分配给该进程。如果进程想要使用物理内存的新页面，但没有可用的内存，则内存管理器会为其提供“待机列表”前端的页面。此方案基本上对待机列表中的所有页面都同等对待，仅按页面被置于列表中的时间来对它们进行排序。

      在 Windows Vista 上，内存的每个页面都具有一个在 0 到 7 之间的优先级，这样，内存管理器会将“待机列表”划分为八个列表，每一个都用来存储具有特定优先级的页面。当内存管理器想要从“待机列表”中获取某一页面时，它会先从低优先级列表获取页面。页面的优先级通常反映的是第一个导致该页面分配的线程的优先级。（如果页面是共享的，它反映的就是共享线程的最高内存优先级。）线程会从其所属的进程继承它的页面优先级值。当内存管理器预见到某一进程要访问内存时，会将低优先级用于它从磁盘推测性读取的页面。

      默认情况下，进程的页面优先级值为 5，但应用程序和系统可通过函数更改进程和线程的页面优先级值。只有从宏观上理解页面的相对优先级时，才能意识到内存优先级的真正价值，也就是 SuperFetch 所发挥的作用。

SuperFetch

      内存管理器的重大改变体现在它对物理内存的管理方式。先前版本 Windows 所使用的“待机列表”管理有两个局限性。首先，页面的优先化仅取决于进程最近过去的行为，而不会预见到它们未来的内存需求。其次，用于优先化的数据仅限定于进程在任意给定时刻所拥有的页面列表。这两个缺点会导致出现“午餐后综合症”之类的状况，即您离开计算机一段时间，但需要内存密集型的系统应用程序在此期间一直都在运行（例如病毒扫描或磁盘碎片整理）。此应用程序会强制您的活动应用程序已在内存中进行缓存处理的代码和数据由内存密集型活动重写。等您回来后，就会发现性能变得非常缓慢，因为各应用程序必须从磁盘请求它们的数据和代码。

      Windows XP 采用了预取支持，该功能基于以前的引导和应用程序启动来执行大规模的磁盘 I/O，以向内存预加载所预期到的代码和文件系统数据，从而改进了引导和应用程序启动性能。Windows Vista 凭借 SuperFetch 又向前迈进了一大步，SuperFetch 是一种通过历史信息和前瞻性内存管理来增强“least-recently accessed”（最近最少访问的）方法的内存管理方案。

      SuperFetch 作为在服务主机进程 (%SystemRoot%\System32\Svchost.exe) 内运行的 Windows 服务在 %SystemRoot%\System32\Sysmain.dll 中实现。该方案依赖于内存管理器提供的支持，因此它可以检索页面使用历史，以及引导内存管理器将来自磁盘文件或分页文件的数据和代码预加载到“待机列表”中，并为各页面指定优先级。SuperFetch 服务基本上是将页面跟踪扩展到曾经存储在内存中但已被内存管理器重新使用以为新数据和代码让出空间的数据和代码。该服务会将这一信息存储在 %SystemRoot%\Prefetch 目录中扩展名为 .db 的场景文件中（位于用于优化应用程序启动的标准预取文件旁边）。在对内存使用情况的这种深入了解基础上，SuperFetch 可在物理内存变为可用时预加载数据和代码。

      只要内存变为可用（例如，当某应用程序退出或释放内存时），SuperFetch 便会要求内存管理器提取最近被驱出的数据和代码。这将以每秒少数几页的速率完成，并且 I/O 的优先级为“非常低”，以便预加载操作不会影响用户或其他活动应用程序。因此，如果您离开计算机去享用午餐，并且某个内存密集型的后台任务导致活动应用程序的代码和数据在您离开期间被驱出内存，则 SuperFetch 通常会在您回来之前将所有或大多数代码和数据返回到内存中。SuperFetch 还包含了对休眠、待机、快速用户切换 (FUS) 和应用程序启动的特定场景支持。例如，当系统处于休眠状态时，SuperFetch 会将数据和代码存储在它预期（基于以前的休眠）将在后续恢复期间被访问的休眠文件中。相比之下，当您恢复 Windows XP 时，先前缓存的数据在被引用时必须从磁盘重新读取。

      请参注1“观察 SuperFetch”以简单了解 SuperFetch 如何影响可用内存。

Watching memory

ReadyBoost

      CPU 和内存的速度快到超越了硬盘的速度，因此磁盘是一个常见的系统性能瓶颈。随机磁盘 I/O 成本尤为高昂，因为磁头寻道时间约为 10 毫秒，这对于现今的 3GHz 处理器来说有些漫长。尽管 RAM 是用于缓存磁盘数据的理想选择，但它的成本也相对较高。不过，闪存通常较为便宜，它随机读取的速度最高可比典型硬盘快 10 倍。因此，Windows Vista 中加入了一个名为 ReadyBoost 的功能来利用闪存存储设备，方法是在这些设备上创建一个逻辑上介于内存和磁盘之间的中间缓存层。

      ReadyBoost 由一个在 %SystemRoot%\System32\Emdmgmt.dll 中实现的运行于服务主机进程中的服务和一个卷过滤器驱动程序 (%SystemRoot%\System32\Drivers\Ecache.sys) 组成。（Emd 是“外部内存设备”的简称，即 ReadyBoost 在开发期间所使用的工作名称。）当您将 USB 密钥之类的闪存设备插入到系统中时，ReadyBoost 服务会查看该设备以确定其性能特征并将测试结果存储在 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Emdmgmt 中（如图 1 所示）。

Figure 1 ReadyBoost device test results in the registry

      如果您还未使用设备进行缓存处理，并且新设备大小介于 256MB 和 32GB 之间、对于 4KB 随机读取的传输率为 2.5MB/s 或更高、对于 512KB 随机写入的传输率为 1.75MB/s 或更高，则 ReadyBoost 将询问您是否想要将高达 4GB 的存储空间专门用于进行磁盘缓存。（尽管 ReadyBoost 可以使用 NTFS，它还是会将最大缓存大小限制在 4GB，以适应 FAT32 限制。）如果您同意，该服务便会在设备的根目录下创建一个名为 ReadyBoost.sfcache 的缓存文件，并要求 SuperFetch 在后台预先填充缓存。

      在 ReadyBoost 服务对缓存进行初始化之后，Ecache.sys 设备驱动程序会将所有读写数据截取到本地硬盘卷（例如 C:\），并将要写入的所有数据复制到该服务创建的缓存文件中。Ecache.sys 会将数据压缩，压缩比通常达到 2:1，这样，4GB 的缓存文件通常将包含 8GB 数据。驱动程序会联合使用高级加密标准 (AES) 和一个随机生成的每引导会话密钥对其写入的每个块进行加密，以在将设备从系统移除的情况下保证缓存中数据的保密性。
当 ReadyBoost 确定可从缓存满足随机读取需求时，它便会从那里向随机读取提供服务，但由于硬盘的有序读取访问要胜过闪存，因此，它允许有序访问模式中的读数据直接移至磁盘，即使该数据位于缓存中。
ReadyBoot

      如果系统的内存不到 512MB，则 Windows Vista 会使用与 Windows XP 一样的引导时预取，但如果系统的 RAM 为 700MB 或以上，它便会使用 RAM 内缓存来优化引导进程。缓存的大小取决于可用 RAM 总量，但这足以创建适当的缓存，并还可以为系统留出要顺利引导所需的内存。
在每一次引导后，ReadyBoost 服务（就是刚刚介绍的用于实现 ReadyBoost 功能的服务）会使用空闲 CPU 时间来为下一次引导计算引导时缓存计划。它会分析来自前五次引导的文件跟踪信息，并标识出访问了哪些文件以及这些文件在磁盘上的位置。该服务将已处理的跟踪信息以 .fx 文件形式存储在 %SystemRoot%\Prefetch\Readyboot 中，并将缓存计划保存在 HKLM\System\CurrentControlSet\Services\Ecache\Parameters 下的 REG_BINARY 值（这些值针对它们所引用的内部磁盘卷而命名）中。

      缓存由实现 ReadyBoost 缓存处理的同一设备驱动程序 (Ecache.sys) 实现，但缓存的填充则是由 ReadyBoost 服务在系统引导时带领完成。尽管引导缓存像 ReadyBoost 缓存一样进行压缩，但 ReadyBoost 和 ReadyBoot 缓存管理之间的另一个区别是，在 ReadyBoot 模式下，除了 ReadyBoost 服务的更新之外，缓存不会变为反映在引导期间读取或写入的数据。ReadyBoost 服务会在引导开始后 90 秒时（或者在其他内存需求批准它的情况下）将缓存删除，并将缓存的统计信息记录在 HKLM\System\CurrentControlSet\Services\Ecache\Parameters\ReadyBootStats 中（如图 2 所示）。Microsoft 性能测试表明，与旧有 Windows XP 预取器相比，ReadyBoot 使性能提高了约 20%。

Figure 2 ReadyBoot Performance statistics

ReadyDrive

      ReadyDrive 是一项利用了名为 H-HDD 的新型混合硬盘驱动器的 Windows Vista 功能。H-HDD 是一种带有嵌入式非易失性闪存（还称为 NVRAM）的磁盘。典型 H-HDD 所包含的缓存大小介于 50MB 和 512MB 之间，但 Windows Vista 缓存限制为 2TB。
Windows Vista 使用 ATA-8 命令来定义要在闪存中存放的磁盘数据。例如，Windows Vista 会在系统关闭时将引导数据保存到缓存，从而可以更快速地重新启动。它还会在系统处于休眠状态时将某些部分的休眠文件数据存储在缓存中，以便加速后来的恢复过程。即使在磁盘盘片降速时也会启用缓存，因此，Windows 可以将闪存用作磁盘写入缓存，这样可避免在系统靠电池电源运行时将磁盘盘片加速。使磁盘轴保持关闭状态可以节省由磁盘驱动器在正常使用期间所消耗的大量电源。

引导配置数据库

      Windows Vista 在启动和关闭方面增强了许多功能。随着“引导配置数据库”(BCD) 的采用，启动功能在存储系统和 OS 启动配置、系统启动进程的新流程和组织、新登录体系结构以及对延迟式自动启动服务的支持方面都有所改进。Windows Vista 关闭方面的变化包括 Windows 服务的预关闭通知、Windows 服务关闭排序以及 OS 对电源状态转换的管理方式的重大改变。

      启动进程的最明显变化之一是，系统卷的根目录中没有了 Boot.ini。这是因为，引导配置现在存储在 BCD 中（在先前版本的 Windows 上，它存储在 Boot.ini 文本文件中）。Windows Vista 使用 BCD 的其中一个原因是，BCD 将 Windows 支持的两个当前引导体系结构合为了一体：主引导记录 (MBR) 和可扩展固件接口 (EFI)。MBR 通常由 x86 和 x64 桌面系统使用，而 EFI 则由基于 Itanium 的系统使用（但在不久的将来，桌面 PC 很有可能会附带 EFI 支持）。BCD 对固件进行了抽象化，并具有超越 Boot.ini 的其他优点，例如，对 Unicode 字符串和备用预引导可执行文件的支持。
BCD 实际上存储在磁盘上的某个加载到 Windows 注册表中以通过注册表 API 进行访问的注册表配置单元中。在 PC 上，Windows 将其存储在系统卷上的 \Boot\Bcd 中。在 EFI 系统上，它位于 EFI 系统分区上。在加载了该配置单元后，它会在 HKLM\Bcd00000000 下显示，但因其内部格式没有文档记录，所以编辑它时需要使用 %SystemRoot%\System32\Bcdedit.exe 之类的工具。也可通过 Windows Management Instrumentation (WMI) 将用来操纵 BCD 的接口提供给脚本和自定义编辑器使用，并且可以使用“Windows 系统配置实用程序”(%SystemRoot%\System32\Msconfig.exe) 来编辑或添加基本参数（如内核调试选项）。

      BCD 将平台范围的引导设置（例如，默认 OS 选择和引导菜单超时时间）与 OS 特定的设置（例如，OS 引导选项和 OS 引导加载器的路径）分割开来。例如，图 3 显示了在您未使用命令行选项运行 Bcdedit 时，BCD 会在输出上部的“Windows 引导管理器”部分显示平台设置，接着在“Windows 引导加载器”部分显示 OS 特定的设置。

      当您引导 Windows Vista 安装时，这个新方案会将在先前版本 Windows 上由操作系统加载器 (Ntldr) 处理的任务划分为两种不同的可执行文件：\BootMgr 和 %SystemRoot%\System32\Winload.exe。Bootmgr 会读取 BCD 并显示 OS 引导菜单，而 Winload.exe 会处理操作系统加载。如果您要执行干净引导，则 Winload.exe 会加载引导启动设备驱动程序和核心操作系统文件（包括 Ntoskrnl.exe），并将控制权移交给操作系统；如果系统要从休眠状态恢复，则 Winload.exe 会通过执行 %SystemRoot%\System32\Winresume.exe 将休眠数据加载到内存中并恢复 OS。

      Bootmgr 还包含对其他预引导可执行文件的支持。Windows Vista 还随带了 Windows 内存诊断 (\Boot\Memtest.exe)，该工具已被预配置为用于检查 RAM 性能状况的选项，但第三方可以添加其自己的预引导可执行文件，以作为将在 Bootmgr 的引导菜单中显示的选项使用。

启动进程

    在先前版本的 Windows 中，各种系统进程之间的关系并不直观。例如，在系统引导时，交互登录管理器 (%SystemRoot%\System32\Winlogon.exe) 会启 动“本地安全机构子系统服务”(Lsass.exe) 和“服务控制管理器”(Services.exe)。此外，Windows 会使用一个名为 Session 的命名空间容器来隔离在不同登录会话中运行的进程。但在推出 Windows Vista 之前，登录到控制台的用户共享的是 Session 0（即，由系统进程使用的会话），这就造成了潜在的安全问题。例如，如果某个运行于 Session 0 中的编写拙劣的 Windows 服务在交互式控制台上显示一个用户界面，从而允许恶意软件通过粉碎攻击之类的方法来攻击窗口并有可能获得管理特权，就会引发此类安全问题。

    为解决这些问题，若干个系统进程都针对 Windows Vista 进行了重新设计。会话管理器 (Smss.exe) 是在使用先前版本的 Windows 时在引导期间创建的第一个用户模式进程，但在 Windows Vista 上，会话管理器会启动自己的另一个实例来配置 Session 0，该会话将独自供系统进程专用。用于 Session 0 的会话管理器进程将启动“Windows 启动应用程序”(Wininit.exe)（一个用于 Session 0 的 Windows 子系统进程 (Csrss.exe)），然后退出。“Windows 启动应用程序”会通过启动“服务控制管理器”、“本地安全机构子系统”和一个用来管理计算机的终端服务器连接的新进程（即“本地会话管理器”(Lsm.exe)）持续运行。

    当用户登录到系统上时，初始的会话管理器会创建其自己的一个新实例来配置新会话。新的 Smss.exe 进程会为这个新会话启动 Windows 子系统进程和 Winlogon 进程。让主会话管理器使用自己的副本初始化新会话并不会为客户端系统带来任何有利条件，但在充当终端服务器的 Windows Server“Longhorn”系统上，可以并行运行多个副本以提高多个用户的登录速度。

    在这个新的体系结构下，各系统进程（包括 Windows 服务）在 Session 0 中进行了隔离。如果运行于 Session 0 中的某个 Windows 服务显示一个用户界面，则“交互服务检测”服务 (%SystemRoot%\System32\UI0Detect.exe) 会通过在用户的安全上下文中启动自己的实例并显示图 4 中所示的消息来通知所有登录的管理员。如果用户选择“显示消息”按钮，该服务会将桌面切换到 Windows 服务桌面，用户可在这里与服务的用户界面交互，然后再切换回自己的桌面。有关启动时会出现哪些情况的详细信息，请参阅边栏“查看启动进程关系”。

查看启动进程关系

    可使用 Sysinternals (microsoft.com/technet/sysinternals) 提供的 Process Explorer 来查看 Windows Vista 的进程启动树。

    屏幕快照包括“会话”列，您可通过 Process Explorer 的列对话框添加它。突出显示的进程是初始的 Smss.exe。位于它下面的是 Session 0 的 Csrss.exe 和 Wininit.exe，由于这两个进程的父进程（用于配置 Session 0 的 Smss.exe 实例）已经退出，因此它们左对齐。Wininit 的三个子进程分别是 Services.exe、Lsass.exe 和 Lsm.exe。

    Process Explorer 将一组进程标识为在 Session 1 中运行，也就是我通过远程桌面连接登录到的会话。Process Explorer 用蓝色突出色来显示与自身使用相同帐户运行的进程。最后，将 Session 2 初始化，以为登录到控制台并创建新登录会话的用户做好准备。就是在该会话中，Winlogon 将运行并使用 LogonUI 要求新的控制台用户“按 Ctrl+Alt+DELETE 进行登录”，而且在该会话中，Logonui.exe 将要求用户提供其凭据。

凭据提供程序

      即使是登录体系结构也在 Windows Vista 上发生了变化。在先前版本的 Windows 上，Winlogon 进程会加载在注册表中指定的“图形识别与认证”(GINA) DLL 来显示要求用户提供其凭据的登录 UI。遗憾的是，GINA 模式受到了许多限制，包括只能配置一个 GINA、第三方很难编写完整的 GINA，以及具有非标准用户界面的自定义 GINA 会改变 Windows 用户体验。

      而 Windows Vista 使用了新的“凭据提供程序”体系结构来代替 GINA。Winlogon 会启动一个单独的进程，即“登录用户界面主机”(Logonui.exe)，该进程将加载在 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Authentication\Credential Providers 中配置的凭据提供程序。Logonui 可以并行托管多个凭据提供程序；实际上，Windows Vista 随带了交互式 (Authui.dll) 提供程序和智能卡式 (Smart-cardcredentialprovider.dll) 提供程序。为确保统一的用户体验，LogonUI 会管理对最终用户显示的用户界面，但它还会允许凭据提供程序指定文本、图标和编辑控件之类的自定义元素。

延迟式自动启动服务

      如果您曾经在 Windows 系统启动后立即登录到系统上，您或许在桌面被完全配置并且您可以与外壳和所启动的任何应用程序进行交互之前经历了一些延迟。在您登录时，“服务控制管理器”会启动多个被配置为自动启动服务并因此在引导时激活的 Windows 服务。许多服务都会执行与登录活动争用资源的 CPU 密集型初始化和磁盘密集型初始化。为解决此问题，Windows Vista 采用了一个被称为延迟式自动启动的新服务启动类型，如果服务不必在 Windows 引导后立即激活，便可使用该类型。

      “服务控制管理器”会在自动启动服务完成启动后再启动配置为延迟式自动启动的服务，并将这些服务的初始线程优先级设置为 THREAD_PRIORITY_LOWEST。此优先级别会使线程执行的所有磁盘 I/O 都采用“非常低”I/O 优先级。在服务完成初始化后，“服务控制管理器”会将其优先级设置为普通。将延迟式启动、较低的 CPU 和内存优先级与后台磁盘优先级结合后，大大减少了与用户登录间的相互冲突。许多 Windows 服务（包括后台智能传输、Windows Update 客户端和 Windows Media® Center）都使用这个新启动类型来帮助提升引导后的登录性能。
关闭

      困扰着 Windows 服务编写人员的一个问题是，在 Windows 关闭过程中，默认情况下他们最多只有二十秒钟的时间来执行清理。Windows Vista 之前的 Windows 版本一直不支持等待所有服务都退出的干净关闭，因为存在程序错误的服务可能会无限期地阻止关闭。有些服务（例如那些具有与网络相关的关闭操作或必须将大量数据保存到磁盘的服务）可能需要更多的时间，因此 Windows Vista 允许服务请求预关闭通知。

      在 Windows Vista 关闭时，“服务控制管理器”会首先通知那些要求预关闭通知的服务。它将无限期地等待这些服务退出，但如果这些服务存在程序错误且没有响应查询，则“服务控制管理器”会在三分钟后放弃并继续前进。一旦所有这些服务都已退出或超时时间已满，“服务控制管理器”就会接着对剩余的服务执行旧有形式的服务关闭。组策略和 Windows Update 服务会在全新的 Windows Vista 安装中注册预关闭通知。

      组策略和 Windows Update 服务还会使用另一个 Windows Vista 服务功能：关闭排序。各服务始终都可以指定启动依存性，“服务控制管理器”要服从这些依存性以按照满足这些依存性的顺序来启动服务，但在 Windows Vista 之前，各服务还无法指定关闭依存性。现在，注册预关闭通知的服务也可以将其自己插入到存储在 HKLM\System\CurrentControlSet\Control\PreshutdownOrder 的列表中，“服务控制管理器”将根据它们的相应顺序将其关闭。有关这些服务的详细信息，请参阅边栏“标识延迟式自动启动和预关闭服务”。

电源管理

      睡眠和休眠属于其他形式的关闭，自 Windows 2000 将电源管理引入到 Windows NT® 系列的 Windows 操作系统后，驱动程序和应用程序方面的问题重重的电源管理一直都是令商务旅行人士苦恼的一件事情。当许多用户在踏上旅途前合上自己的便携式计算机外盖时，都期望计算机系统处于挂起或休眠状态，但没想到在到达目的地时，手提箱已经变得灼热，电池也被用尽，而且还丢失了数据。这是因为 Windows 始终都会询问设备驱动程序和应用程序是否允许更改电源状态，只要有一个驱动程序或应用程序未响应，就可能会阻止转换。

      在 Windows Vista 中，内核的电源管理器仍会通知驱动程序和应用程序要更改电源状态以便它们可以为这些更改做好准备，但不会再请求许可。此外，电源管理器最多会留出 20 秒来等待应用程序对更改通知做出响应，而不是像在先前版本的 Windows 上那样等待 2 分钟。因此，Windows Vista 用户可以更加确信自己的系统会执行休眠和挂起。

预告

      正如我先前所说的，这是由三部分组成的系列文章中的第二部分。第一部分介绍了 Windows Vista 内核在 I/O 和进程方面的改进。这一次，我分析了 Windows Vista 在内存管理、启动和关闭方面的增强。下一次，我将通过介绍内核在可靠性和安全性方面的改变来结束本系列文章。

标识延迟式自动启动和预关闭服务

      内置的 SC 命令在 Windows Vista 得到了更新，以显示配置为延迟式自动启动服务的服务：

Using SC to display start type  (单击该图像获得较小视图) 

      遗憾的是，SC 命令不会报告已请求预关闭通知的服务，但您可以使用 Sysinternals 提供的 PsService 实用程序来确保服务接受预关闭通知：