The Active Network
ActiveWin: Win Vista Active Network | Intro | FAQ | Win XP Tips | Compatibility List | Forum


Windows Vista Section

Kernel Enhancements

In Windows Vista, Microsoft has made substantial enhancements to the Windows kernel in the following areas:

Memory management

  • Improvements to dynamic system address space, including on-demand allocation of system virtual address space and kernel page table pages, and support for very large registries.

  • Enhanced support for non-uniform memory architecture (NUMA) systems and systems with large pages, including additional device driver and Microsoft Win32 NUMA application program interfaces (APIs).

  • Advanced video model support through a new mapping type called rotate virtual address descriptors (VADs).

  • I/O and section access improvements, including pervasive prefetch-style clustering for all types of page faults and system cache read-ahead.

  • General performance improvements, including translation buffer optimizations and improvements to internal data structures and algorithmic performance.

  • Microsoft Terminal Server improvements, including new Terminal Server session objects.

  • Robustness and diagnosability improvements, including reduced data loss from failed in-page operations.

Heap Management

  • Performance

    • Automatic tuning allows applications to transparently take advantage of the low-fragmentation heap (LFH) that was introduced in previous versions of Windows.

    • Rearchitecture of internal algorithms and data structures that handle segment management. As a result, the heap manager provides better fragmentation management, better scalability, and lower overhead for large heaps, especially for 64-bit server applications. In addition, the efficiency of lookup algorithms has been improved from O(n) to O(1).

  • Security and reliability
    Mitigations to decrease surface area for potential attack vectors including:
    • Block metadata encoding

    • Integrity checks on block headers

    • Random heap rebasing

    • Improved and early detection of heap corruptions and the ability for applications to terminate when heap corruption occurs, thereby deterring "brute force" attacks that exploit a vulnerability.

Management mechanisms

  • Registry

    • Transaction support for registry operations

    • Optimizations to reduce the possibility of registry corruption

    • Registry filtering that is consistent with the file system filtering model

    • Registry virtualization support

    • Microsoft Windows-32-bit-On-Windows-64-bit (WOW64) registry mirroring enhancements (64-bit Windows)

  • Services Model

    • Delayed start type for services
      (improves boot performance by starting services shortly after boot and yet retains the "unattended start" behavior)

    • Platform support for sandboxing and protection from user-mode attacks (Session 0 isolation)

    • Manageability improvements
      The service model provides a new notification API to track service state changes. These notifications work both locally and remotely, and remove the requirement for services or clients to use polling loops to monitor state changes In addition, support for failure actions has been extended to provide recovery actions for non-crash failures.

  • Windows Hardware Error Architecture (WHEA)

  • WHEA is a new, common operating system/hardware error-handling infrastructure that helps reduce mean time to recovery through the following mechanisms:

    • A generic mechanism for error source discovery.

    • A common error-record format for operating system and hardware errors.

    • A common error-handling flow for operating system and hardware errors.

    • A persistence mechanism for operating system error records.

    • A common hardware error-eventing model based on Event Tracing for Windows (ETW) for management applications.

Security features

  • Kernel Patch Protection
    x64 versions of Windows Vista include kernel patch protection, first implemented in Windows Server 2003 SP1 and Windows XP for x64-based systems.

  • Protected Processes
    Windows Vista introduces a new type of process called a protected process. Currently only available to applications via the Windows Protected Media Path, protected processes enhance support for digital rights management functionality in Windows Vista by constraining the level of access that other processes in the system can obtain to protected processes.

  • Code Signing
    x64 versions of Windows Vista require kernel-mode software to have a digital signature to load on x64-based computer systems. x86 versions of Windows Vista require certain kernel-mode software to have digital signatures to access next-generation premium content if it utilizes the Windows Protected Media Path.

  • Code Integrity
    Code integrity enforces the mandatory code-signing policy for kernel-mode drivers on x64-based systems. Code integrity also verifies the integrity of all code that is loaded into a protected process. Images that fail image validation are not loaded because such a failure indicates that they have been corrupted (either inadvertently or maliciously by a virus or hack). System catalogs are used to store image or page hashes that are used for validation. Code integrity features include the following:

    • The operating system boot loader (Winload) verifies all boot-critical drivers including the HAL and NTOS kernel.

    • Code integrity functionality in the executive (ntoskrnl) verifies image hashes for every driver that is loaded into kernel mode by using image hashes. This verification is done only on x64 systems.

    • Page hashes are only used by code integrity in the kernel to verify user-mode binaries that implement cryptographic functions, or binaries that are loaded into a protected process that is used for playback of high-definition media content.

    • System catalogs ( that contain image hashes are used to verify kernel code. Page hashes in and are used to verify a specific set of user-mode binaries.

Other Application Support Mechanisms

  • Dynamic-Link Library Loader
    The user-mode dynamic-link library (DLL) loader plays a fundamental role in process and thread creation. Every time a process or thread is created, the loader is invoked to complete the following tasks that are related to DLLs and that are required by the process or thread in question:

    • Determine appropriate DLL load order and resolve dependencies

    • Load all required DLLs

    • Unload DLLs when they are no longer needed

    • The Windows Vista DLL loader has undergone a number of improvements, including:

      • Improved process creation time performance.
        A significant portion of process creation time is spent resolving DLL dependencies and processing DLL imports. Improvements to import processing algorithms have reduced processing time by an impressive factor of 1000x in some scenarios (from ~800,000 cycles to ~800 cycles). End-to-end process creation times were reduced by as much as 10 percent for some of the more DLL-heavy applications.

      • Fewer reboots resulting from system DLL servicing.
        In earlier versions of Windows operating systems, before Windows Vista, whenever a system or core DLL was updated by using a service pack, security patch, or similar mechanism, a reboot was required. The reboot was required because no mechanism could identify which system services had loaded the DLL in question. Therefore, the entire system had to be rebooted to ensure that the earlier version of the DLL was unloaded and the updated DLL was loaded instead.

        Enhanced bookkeeping techniques in the Windows Vista loader allow the system to maintain a complete list of services that have loaded a particular DLL. When that DLL is updated, the system can identify and restart only the specific services that are using the DLL to be updated, instead of rebooting the entire system. This change helps to decrease downtime, thus increasing the availability of the system even while it is being upgraded or serviced. Note that some system DLLs, including NTDLL.dll and kernel32.dll, still require a reboot when they are being serviced.

  • Thread Pool
    A thread pool is a collection of system-managed worker threads that efficiently execute asynchronous callbacks on behalf of the developer. The thread pool can be thought of as a smart entity that manages work items, timed executions, asynchronous I/O, and so on while exposing a simple interface to the developer. The thread pool is considered to be "smart" because it can adapt to demands on system resources and respond by dynamically altering scheduling policy, shrinking or growing the pool, and so on.

    The thread pool in Windows Vista is significantly enhanced to improve reliability, performance, and API simplicity. New thread pool functions give the developer a higher degree of control and flexibility while hiding the complexity of synchronization, reference counting and so on, which makes the thread pool much easier to program. Some specific examples of Windows Vista thread pool enhancements include:

    • Cleanup groups.
      Cleanup groups are container objects that can be associated with a group of thread pool callback-generating objects, which creates a single synchronization point for cleanup operations as a unit. Cleanup groups introduce the ability to clean up pending thread pool requests on process shutdown.

    • Multiple pools per process.
      The thread pool also supports multiple thread pools per process, each of which is scheduled independently. This significantly improves responsiveness as well as code isolation.

    • Performance.
      The thread pool is optimized to provide the best possible processor usage and to reduce pressure on system memory. Thread recycling, maintaining a number of running threads that is proportional to the number of processors, smart load balancing, and work assignment are used to gain maximum performance from the thread pool.

  • Support for Hardware Innovation
    • Dynamic Hardware Partitioning
      Dynamic hardware partitioning allows systems to be partitioned at a hardware level to run multiple operating systems instances on a single server. In addition, on dynamic hardware partitioning-capable systems, I/O devices, memory, and processors can be dynamically added and removed from, to, and between partitions without powering down the system.

      Windows Server 2003 already supports hot add of memory on x86-based, x64-based, and Itanium-based systems. For compliant hardware platforms, Windows Server 2008 supports hot add of processors and memory plus hot replace of processors and memory on x64-based and Itanium-based systems. Hot add of I/O host bridges is also planned. System manufacturers, hardware vendors, firmware vendors, and driver developers should follow Microsoft guidelines for developing products for systems and components that support dynamic hardware partitioning.

    • ACPI
      Windows Vista and Windows Server 2008 continue to advance support for the ACPI specification, including selected features from ACPI 3.0:

      • Complete support for ACPI 2.0 processor performance objects.

      • ACPI 3.0 processor domain dependency and throttling objects.

      • Operating System Capabilities (_OSC) method invocation to facilitate transitions to native support of PCI-E features.

      • ACPI General Purpose Event (GPE) block device support.

      • New firmware tables API.

    • PCI and PCI Express
      Windows Vista and Windows Server 2008 support a significant number of features in the PCI Express 1.1 specification, including:

      • Extended configuration space.

      • Segments.

      • PCI Express registers, including capability registers, save and restore of configuration settings, and BIOS configurations.

      • Device serial numbers.

      • PCI Express hierarchy.

      • Message-signaled interrupts (MSI and MSI-X).

      • Hot plug.

      • Native power management events.

      • Active-state power management.

      • Advanced Error Reporting (AER).

    • Boot Environment Enhancements
      Microsoft has completely reengineered the boot environment for Windows Vista to address the increasing complexity and diversity of modern hardware and firmware. A key aspect of this reengineering is a new firmware-independent data store called boot configuration data (BCD). BCD is designed to handle boot environment data for any type of system. It provides access to the information and applications that Windows Vista and later versions of Windows use to load the operating system or run boot applications such as memory diagnostics. Some key characteristics include:

      • BCD provides clean and intuitive structured storage for boot settings.

      • BCD abstracts the underlying data store, making BCD independent of the underlying firmware or processor architecture. BCD currently handles both PC/AT and EFI systems, and can be readily extended to accommodate future improvements in hardware and firmware.

      • BCD is available at run time as well as during the boot process.

      • BCD provides improved security over boot.ini. It allows secure lockdown of the storage format and flexible assignment of the rights that are required for changing boot settings. BCD is stored in a binary format and cannot be edited directly.

      • BCD is designed to handle systems with multiple versions and configurations of Windows, including versions earlier than Windows Vista.

      • BCD is the only boot data store that is required for Windows Vista and later versions of Windows. BCD supports the loading of earlier versions of Windows, but they are ultimately loaded by Ntldr.exe and must still store their boot options in a boot.ini file.
        Instead, users can interact with BCD through several tools. Developers can programmatically manipulate a BCD store through the BCD Windows Management Instrumentation (WMI) provider that can be used for both local and remote management of BCD stores independent of the underlying firmware.

    • Power Management
      Windows Vista and Windows Server 2008 continue to advance and adopt power management technologies with a rich set of new features and capabilities:

      • Simplified power policies that make it easier for users to match usage patterns to the appropriate power policy.

      • A new hybrid sleep state, which combines aspects of standby (suspend to RAM) and hibernate (suspend to disk) to protect the user's data while in standby.

      • Windows Direct Experience, which provides support for starting a PC directly to a specific media experience (for example, to launch directly into a media player when a "media" button is pushed).

      • A new "away mode" that supports media-oriented PC usage models.

      • Reliable power management transitions.

      • Extensive diagnostic tracing and error reporting infrastructure.

      • Comprehensive group policy control for power management settings.

      • Improved battery meter that provides simple, quick access to basic power management settings.

      • Significant improvements to the overall power management user interface and user experience.

    • Hardware Abstraction Layer
      The HAL for Windows Vista and Windows Server 2008 supports Extensible Firmware Interface (EFI) run-time calls for reading the real-time clock and for Plug and Play. Kernel-mode Plug and Play enhancements in Windows Vista and Windows Server 2008 include the following features:

      • Support for PCI multilevel rebalance.

      • Partial arbitration of resources to support PCI subtractive bridges.

      • Asynchronous device start and enumeration operations to speed system startup.

      • Support for setting and retrieving custom properties on a device.

      • An enhanced ejection API to allow the caller to determine if and when a device has been successfully ejected.

      • Diagnostic tracing to facilitate improved reliability.


Kernel Enhancements for Windows Vista and Windows Server 2008

Windows Administration: Inside the Windows Vista Kernel

Memory Management: What Every Driver Writer Needs to Know

Boot Configuration Data in Windows Vista

Windows Server 2003 Kernel Scaling Improvements

Kernel Enhancements for Windows XP

Windows NT 4.0 Workstation Architecture

MS Windows NT Kernel-mode User and GDI White Paper

MS Windows NT - The Foundation



Return To The Windows Vista Section


  *   *