WHEA 的另一关键部分是位于 %Systemroot%System32Pshed.dll 中的平台特定的硬件错误驱动程序 (PSHED)。内核与 PSHED 链接，而它与平台和固件硬件连接，实质上是用作错误通知和 WHEA 错误报告 API 之间的转换层。Microsoft 为每种平台体系结构(x86、x64、Itanium)提供有一种 PSHED 并且 PSHED 公开了插件模型，所以硬件供应商和制造商可使用特定于其平台的行为来覆盖默认行为。
最后，与其他错误源相连的系统组件 — 包括设备驱动程序、硬件抽象层 (HAL) 和内核 — 可实现底层硬件错误处理程序 (LLHEL)(它将首先处理错误状况)。LLHEL 的工作是从设备中提取错误信息，通知 PSHED 允许其收集其他平台错误信息，然后调用内核的 WHEA 错误报告 API。
驱动程序验证程序
从 Windows 2000 起，每个 Windows 副本中都包含有驱动程序验证程序，它是一个用于跟踪出错的设备驱动程序和故障硬件的强大工具。管理员通常将驱动程序验证程序(%Systemroot% System32Verifier.exe) 配置为密切监控可能导致系统崩溃的可疑设备驱动程序的行为。驱动程序验证程序可捕获非法驱动程序操作，这样崩溃转储文件就可以直接指出罪魁祸首。
之前驱动程序验证程序的缺陷在于大多数配置更改都需要重新启动系统，而生产服务器明显不愿出现这种情形。Windows Server 2008 中的驱动程序验证程序通过取消最有用验证的重启要求而改进了这一过程，因此可在不重新启动系统的情况下对出现问题的服务器进行故障排除。
此外，驱动程序验证程序还引入了三种新的验证(如图 3 所示)。安全检查确保设备驱动程序在用于与应用程序连接的对象上设置了安全权限。强制挂起 I/O 请求测试了驱动程序对于需立即完成而非一段延迟后再完成的异步 I/O 操作的恢复能力。杂项检查则确认驱动程序有无错误释放使用中的资源、错误使用 Windows 管理规范 (WMI) 注册 API 以及泄漏资源处理程序
图 3 选中 Windows Server 2008 选项的驱动程序验证程序
可伸缩性
执行计时器超时的代码中有一个较小但却非常重要的改进，即不再需要调度程序锁(所有底层同步操作都会使用的一种系统范围调度程序锁)。从而降低了 CPU 同步开销，使得 Windows Server 2008 终端服务器系统能比 Windows Server 2003 多支持约 30% 的并发用户。
Windows Server 2008 中的其他可伸缩性改进包括完成端口增强功能、新的线程池实现、更加有效地使用非一致内存访问 (NUMA) 硬件以及动态系统分区。
改进了 I/O 完成端口处理
大多数可伸缩的 Windows 服务器应用程序(包括 IIS、SQL Server? 和 Exchange Server)都依靠称为完成端口的一个 Windows 同步 API 来最大程度减少执行 I/O 操作时在多个线程之间的切换。具体方法是首先将新到请求(如 Web 服务器客户端连接)通知与完成端口关联起来，并指定一个线程池来专门等待通知。当请求到来时，Windows 将调度一个线程，该线程通常执行其他 I/O 操作(如从磁盘读取一个网页并将其发送到客户端)来完成该请求。
因此，相同线程可尽快地返回以等待更多的客户端请求，线程异步执行 I/O 并将 I/O 完成与完成端口关联起来。线程随后返回等待完成端口，当新请求到来或某个 I/O 完成时，完成端口将调度该线程。通过这种方式，同一线程在 CPU 上始终处于活动状态：处理客户端请求或等待完成端口
之前 Windows 版本中完成端口的缺陷在于：当 I/O 完成后，I/O 系统将让执行该 I/O 的线程立即执行一小段完成处理，而不考虑该线程当前正在执行的其他工作。如果还有其他线程处于活动状态，则常常会导致调度程序抢占活动线程，并上下文切换到另一个执行线程的情况。
通过将完成处理延迟到下一线程以等待与该 I/O 关联的完成端口，Windows Server 2008 避免了此类上下文切换。因此，即使还有另一线程正在等待完成端口，它仍会在执行其他代码之前先执行完成处理，而且调度程序不必切换到执行线程。这种最小化上下文切换的能力可显着地改善高负载服务器应用程序的可伸缩性。
线程池更加有效
利用多个 CPU 来写入应用程序非常困难，因此 Windows XP 引入了工作线程池，它是一种基础结构和相关 API，用于提取在多个 CPU 间执行小段工作的详细信息。 应用程序将工作项目指定给线程池 API，然后该 API 在它为系统中的每个 CPU 创建和管理的某个线程中执行这些工作项目。
线程池的目的是通过使用相同的线程连续执行多个工作项目来尽可能减少上下文切换。当某个线程因为忙于执行其他工作而无法达到此目的时，它将使用不同 CPU 上的另一线程来执行该工作项目。
Windows Server 2008 的线程池实现可间接地(受益于完成端口改进)和直接地(通过优化线程管理)更好利用 CPU，这样工作线程就能根据需要动态切换以便处理应用程序的负荷。并且，此基础结构的核心已转移到内核模式，从而最小化使用该 API 的应用程序所产生的系统调用数量。最后，新 API 使应用程序能够更轻松地执行某些操作，如在应用程序关闭期间中止已排队的工作单元。
NUMA 优化
Windows Server 2003 在线程调度程序和内存管理器中引入了 NUMA 优化，而 Windows Server 2008 在 I/O 管理器中添加了 NUMA 优化同时扩展了内存管理器的 NUMA 优化
NUMA 系统通常是多处理器系统，其中的内存延迟随访问它的处理器不同而有所不同(请参见图 4)。内存被分成多个节点，CPU 和节点之间的延迟可能各不相同，并且每个 CPU 都被视为它可最快访问的那个节点的一部分。
图 4 示例 NUMA 系统
NUMA 系统(尤其是具有超过八个 CPU 的系统)通常比一致内存访问系统更加经济且性能更高。一致内存访问系统必须平等地为所有 CPU 提供内存，而 NUMA 系统则能够为直接连接到 CPU 的内存提供高速互连，同时为与 CPU 相隔较远的内存提供较为便宜但更高延迟的连接
为能在 NUMA 系统中有效扩展，操作系统或应用程序必须了解节点拓扑结构，以便使计算能够在包含计算数据和代码的内存附近执行。例如，Windows 调度程序为每个线程分配一个所谓的理想处理器，该处理器是调度程序试图始终在其上执行该线程的 CPU。这样做可以使线程置于 CPU 缓存中的数据能够尽可能地在每次该线程运行时可用。
在 Windows Server 2003 中，调度程序扩展此概念的方法是：将包含理想处理器的节点视为该线程的理想节点，并且当理想处理器正忙于执行另一个线程时，调度程序会尝试在理想节点中的另一个 CPU 上调度该线程。Windows Server 2003 内存管理器也支持 NUMA，并且在可能的情况下，它会将线程的内存分配定向到正在执行此线程的节点的内存中。
在 Windows Server 2008 中，内存管理器将内核的非分页内存缓冲区(内核和设备驱动程序用于存储必需保存在 RAM 中的数据的内存)分到各个节点，这样可以在产生分配的节点上为线程分配内存。系统页表项 (PTE) 是从发生分配的节点中分配，如果需要新页表页来满足内存分配，则会按照在 Windows Server 2003 中所采取的方式在相同的节点内存中分配，而不会从任何其他节点的内存中分配