了解 Windows Vista 内核：第 2 部分

 

了解 Windows Vista 内核：第 2 部分

Mark Russinovich

 

概览:

• 内存管理
• 启动和关闭
• 电源管理

上个月，我在这个由三部分构成的系列文章的第一部分，分析了 Windows Vista 内核在进程和 I/O 方面的增强功能。

这一次，我将涵盖到 Windows Vista 对内存管理方式的提升以及系统启动、关闭和电源管理方面的主要改进（第 1 部分）。

Windows® 随着每个发行版本的问世都在可伸缩性和性能方面进行了改进，Windows Vista™ 也不例外。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 时，先前缓存的数据在被引用时必须从磁盘重新读取。

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

观察 SuperFetch

在您使用 Windows Vista 系统一段时间后，您会发现任务管理器“性能”页面上的“可用物理内存”计数器的数值很低。这是因为 SuperFetch 和标准 Windows 缓存处理使用了所有可用物理内存来缓存磁盘数据。例如，在您首次引导时，如果您立即运行任务管理器，则您会注意到，可用内存值会随着已缓存内存量的增加而减少。如果您运行一个内存需求很大的程序，然后退出该程序（分配大量内存并在之后释放内存的任何免费软件“RAM 优化程序”都适用），或者刚刚复制了一个非常大的文件，则在系统回收已释放内存时可用内存量将增加，并且物理内存用量图将下降。但随着时间的过去，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 特定的设置。

Figure 3 Settings displayed in BCDEdit (单击该图像获得较大视图)

当您引导 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 服务桌面，用户可在这里与服务的用户界面交互，然后再切换回自己的桌面。有关启动时会出现哪些情况的详细信息，请参阅边栏“查看启动进程关系”。

Figure 4 Service has displayed a window (单击该图像获得较大视图)

查看启动进程关系

可使用 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 将要求用户提供其凭据。

Startup process and session information(单击该图像获得较大视图)

凭据提供程序

即使是登录体系结构也在 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 实用程序来确保服务接受预关闭通知：

Viewing pre-shutdown status(单击该图像获得较大视图)

Mark Russinovich 是 Microsoft 的“平台和服务部”的一名技术人员。他是《Microsoft Windows Internals》（Microsoft Windows 内部结构）(Microsoft Press, 2004) 的合著者之一，并经常在 IT 和开发人员会议上演讲。在 Microsoft 最近收购了 Mark Russinovich 与其他人创办的 Winternals Software 之后，Mark Russinovich 也随之加入了 Microsoft。他还创办了 Sysinternals，在那里他发布了 Process Explorer、Filemon 和 Regmon 实用程序。

© 2008 Microsoft Corporation 与 CMP Media, LLC.保留所有权利；不得对全文或部分内容进行复制.