概覽:
●內存管理和 SMB 2.0
●NTFS 自修復功能、Windows 硬件錯誤報告體系和驅動程序驗證程序
●I/O 完成端口、線程池和 NUMA 的可伸縮性
●Hyper-V 虛擬化
Windows Server 2008 是最新版本的 Microsoft 服務器平台，它包含許多系統級更改，這些更改涉及操作系統的所有功能領域：從內存管理到線程調度，從網絡連接到安全(這裡只列出了少數幾個)。
由於 Windows Server？ 2008 和 Windows Vista？ SP1 的內核相同。只有其中的少數功能僅特定於客戶端且並未包含在 Windows Server 2008 中，如 SuperFetch、ReadyBoost、ReadyDrive、ReadyBoot 和多媒體類計劃程序服務 (MMCSS)。
因此，我將不再重復介紹 Windows Vista 中已介紹過且 Windows Server 2008 中同樣包含的重要內核變化，如 I/O 優先級排列、新的引導體系結構 BitLockerTM、代碼完整性和強制完整性級別。我將重點介紹之前這些文章中未涉及到的關鍵變化，包括與可靠性、性能、可伸縮性以及新的 Microsoft 管理程序計算機虛擬化技術 Hyper-VTM 相關的變化。
同樣，與之前的文章一樣，本文的范圍僅限於操作系統內核 Ntoskrnl.exe 以及與其緊密關聯的系統組件的變化。例如，本文不會介紹安裝(WIM 或 Windows？ 映像格式和基於組件的服務)、管理(組策略和 Active Directory？ 改進)、常規診斷和監控(Windows 診斷基礎結構)、核心網絡(新的防火牆和 TCP/IP 實現)、Server Core 或服務器角色的變化。
用於多處理器系統
系統的其中一項底層變化是 Windows Server 2008 僅提供設計用於多處理器系統的內核版本。過去，Windows 擁有專門針對單 CPU 計算機上的單處理器的版本，因為該版本可通過忽略僅在多處理器環境下需要的同步代碼來獲得稍好一點的性能。隨著硬件速度變得越來越快，由優化帶來的性能提高幾乎可忽略不計，並且如今的大多數服務器系統都包含多個處理器，所以已不再需要單處理器的內核版本。
Windows Server 2008 內核的各個版本，系統中具體使用哪個版本取決於操作系統是調試版本(Checked 版本)還是零售版本、安裝為 32 位還是 64 位(Itanium、Intel 64 或 AMD64)，以及如果是 32 位安裝，系統的物理內存是否超過 4GB 或支持數據執行保護 (DEP)。Windows Server 2008 還可能是最後一個提供 32 位版本的 Windows Server 操作系統。
內核 32 位 64 位
多處理器 是 是
多處理器 Checked 版本 是 是
多處理器物理地址擴展 (PAE) 是 否
多處理器 PAE Checked 版本 是 否
Windows Server 的每個版本均注重改善服務器主要應用場合(如文件服務、網絡 I/O 和內存管理)的性能。此外，Windows Server 2008 還包含許多變化和新功能，以使 Windows 能更好地利用新的硬件體系結構，適應高延遲網絡並消除之前的 Windows 版本中限制性能的瓶頸。本部分將回顧內存管理器、I/O 系統方面的增強功能，並介紹新的網絡文件系統 SMB 2.0。
內存管理
試驗：查看大規模的磁盤 I/O 操作
可使用 TechNet Sysinternals Process Monitor之類的文件系統監視工具來查看 Windows Server 2008 系統上的大規模文件 I/O 操作。
有多種方法均可產生大規模 I/O 操作。如果有另一個運行 Windows Vista Service Pack 1 或 Windows Server 2008 的系統，可在頭一個服務器上運行 Process Monitor 並監控到第二個系統的文件復制。還可以通過運行非常耗費內存的程序使得內存管理器將頁面寫出到分頁文件中，從而產生大規模的分頁文件 I/O 操作。
圖 A 顯示了在 Windows XP 系統中運行非常耗費內存的程序後 Process Monitor 的輸出，此時在 Process Monitor 的“Options”(選項)菜單中選中了“Enable Advanced Output”(啟用高級輸出)選項，並將過濾器設置為僅顯示到分頁文件 pagefile.sys 的寫入。“Detail”(詳細信息)列顯示寫入大小為 64KB。
圖 A
如果在 Windows Server 2008 上運行相同的步驟，則很可能出現類似圖 B 中顯示的輸出，它顯示大多數寫入大小約為 1MB。
圖 B
Windows Server 2008 中的內存管理器包含多項性能增強功能。例如，與 Windows Server 2003 相比，從分頁文件提取數據或對映射文件執行預讀 I/O 時，它將使用數量更少但規模更大的磁盤 I/O。I/O 系統中的變化是促成更大規模的文件 I/O 的前提，它去除了自 Windows NT？ 的第一個版本以來一直存在的 64KB 的 I/O 大小限制。
並且，必須注意：與 Windows Server 2003 相比，使用 Windows Server 2008 時，Cache Manager 從映射文件進行預讀(猜測性讀取)的數據讀取通常要大兩倍，並且將直接進入待機列表(系統的代碼和數據緩存)。這種行為取代了 Cache Manager 映射虛擬內存並將數據讀入系統工作集(由內存管理器為系統分配的內存)的需要，而這種需要可能導致其他使用中的代碼或數據被不必要地驅出工作集。
當把數據寫入分頁文件時，內存管理器也會執行更大規模的 I/O。盡管 Windows Server 2003 常常執行比 64KB 還小的寫入操作，但在 Windows Server 2008 中，內存管理器通常使用 1MB 的寫入操作。
除通過減少寫入分頁文件的次數來提高性能外，較大規模的寫入操作還可減少分頁文件中的碎片。而它又反過來減少了讀回多個頁面所需的讀取次數和磁盤尋道次數，因為如果不相鄰，讀取和尋道次數都會多得多。
內存管理器還會嘗試寫出其他已修改頁面(這些頁面與將要寫出到所擁有進程的地址空間中的頁面相鄰)，並且會將分頁文件放到已包含其他相鄰頁面的區域中。這種方法也可盡量減少碎片並提高性能，因為那些可能會最終寫出到分頁文件中的頁面均已被寫入。此外，它還減少了引入大量相鄰進程頁面所需的分頁讀取次數。查看側欄“試驗：查看大規模的磁盤 I/O 操作”了解有關內存管理器使用大規模的 I/O 方面的更多信息。
SMB 2.0
自從文件服務功能被引入到 Windows 中以來，服務器消息塊 (SMB) 遠程文件系統協議(也稱為通用 Internet 文件系統 (CIFS))就已成為 Windows 文件服務的基礎。在過去的幾年中，SMB 的設計限制制約了 Windows 文件服務的性能和利用新的本地文件系統功能的能力。例如，單個消息能傳輸的最大緩沖區大小為約 60KB，並且 SMB 1.0 無法識別 Windows Vista 和 Windows Server 2008 中新增的 NTFS 客戶端符號鏈接。
Windows Vista 和 Windows Server 2008 引入了 SMB 2.0，它是客戶端和服務器都支持時 Windows 所使用的一種新型遠程文件服務協議。除能正確處理客戶端符號鏈接和其他 NTFS 增強功能外，SMB 2.0 還使用批處理來最小化客戶端和服務器之間的信息交換數量。批處理可提高廣域網 (WAN) 之類高延遲網絡的吞吐量，因為它允許同時傳輸更多數據。
SMB 1.0 針對單個文件按順序執行 I/O，而 SMB 2.0 則實現了 I/O 管道，從而可針對同一文件執行多個並發 I/O。它通過衡量客戶端用於未完成 I/O 的服務器內存數量來決定管道的深度。
由於 Windows I/O 內存管理器和 I/O 系統以及 TCP/IP 接收窗口自動調節方面的變化和文件復制引擎的改進，SMB 2.0 顯著提高了吞吐量並減少了大型傳輸的文件復制時間。由於兩種操作系統都實現了 SMB 2.0，所以部署 Windows Server 2008 文件服務器和 Windows Vista 客戶端即可使用 SMB 2.0 並實現這些性能優點。
使用 NTFS 自修復功能提高可靠性
可靠性是一個關鍵服務器屬性，Windows Server 2008 提供各種改進來幫助管理員順暢運行其服務器(包括在線 NTFS 一致性修復、新的硬件錯誤報告體系以及對驅動程序驗證程序的擴展)。
由於現在使用的存儲設備一般都以 TB 為單位，因此對某個卷進行脫機一致性檢查可能會使服務中斷數小時。鑒於許多磁盤損壞都局限於單個文件或部分元數據，Windows Server 2008 實現了新的 NTFS 自修復功能，即可在卷保持聯機的情況下修復損壞。
當 NTFS 檢測到損壞時，它將阻止訪問受損的文件並創建一個系統工作線程，該線程將對受損數據結構執行類似 Chkdsk 的修復，完成後再允許訪問修復後的文件。在此操作期間仍然可以正常訪問其他文件，因而最小化服務中斷。
WHEA 基礎結構
Windows Server 2008 中包含有 Windows 硬件錯誤報告體系 (WHEA) 基礎結構，它可以簡化硬件故障管理並主動響應非致命錯誤。服務器通常都有嚴格的正常工作時間保證，因此及時確定並響應此類系統中的錯誤至關重要。
通過對利用在線崩潰分析 (OCA) 提交到 Microsoft 的崩潰進行分析表明：約 10% 的操作系統崩潰是源於硬件故障，但確定此類崩潰的根本原因卻非常困難甚至於不可能，因為崩潰時所獲取的硬件錯誤信息非常少。此外，在 Windows Server 2008 之前，Windows 並不內置支持監控設備的運行狀況，也未實現故障前的修復或通知。其原因在於硬件設備並未使用一種通用的錯誤格式並且不支持錯誤管理軟件。
WHEA 為各種平台設備(包括處理器、內存、緩存和類似 PCI 和 PCI Express 之類的總線)提供了統一的錯誤源發現和報告機制。其原理是實現圖 2 中所示的體系結構，其中核心是錯誤源調用來報告錯誤的內核 API。此 API 要求所有錯誤都以同一方法進行格式化，然後使用 Windows 事件跟蹤 (ETW) 事件來記錄錯誤(嚴重錯誤則在重啟後再記錄)。
圖 2 WHEA 錯誤報告基礎結構
ETW 早在 Windows 2000 中就已引入，而當 ETW 使用 WHEA 後，硬件制造商和軟件供應商就可輕松地開發利用 WHEA 事件的設備診斷管理應用程序。如果某事件已嚴重到足以導致系統崩潰，WHEA 會確保將該致命錯誤記錄存儲到崩潰轉儲文件中，這樣管理員就可確定崩潰的根本原因。
WHEA 的另一關鍵部分是位於 %Systemroot%\System32\Pshed.dll 中的平台特定的硬件錯誤驅動程序 (PSHED)。內核與 PSHED 鏈接，而它與平台和固件硬件連接，實質上是用作錯誤通知和 WHEA 錯誤報告 API 之間的轉換層。Microsoft 為每種平台體系結構(x86、x64、Itanium)提供有一種 PSHED 並且 PSHED 公開了插件模型，所以硬件供應商和制造商可使用特定於其平台的行為來覆蓋默認行為。
最後，與其他錯誤源相連的系統組件 — 包括設備驅動程序、硬件抽象層 (HAL) 和內核 — 可實現底層硬件錯誤處理程序 (LLHEL)(它將首先處理錯誤狀況)。LLHEL 的工作是從設備中提取錯誤信息，通知 PSHED 允許其收集其他平台錯誤信息，然後調用內核的 WHEA 錯誤報告 API。
驅動程序驗證程序
從 Windows 2000 起，每個 Windows 副本中都包含有驅動程序驗證程序，它是一個用於跟蹤出錯的設備驅動程序和故障硬件的強大工具。管理員通常將驅動程序驗證程序(%Systemroot%\System32\Verifier.exe) 配置為密切監控可能導致系統崩潰的可疑設備驅動程序的行為。驅動程序驗證程序可捕獲非法驅動程序操作，這樣崩潰轉儲文件就可以直接指出罪魁禍首。
之前驅動程序驗證程序的缺陷在於大多數配置更改都需要重新啟動系統，而生產服務器明顯不願出現這種情形。Windows Server 2008 中的驅動程序驗證程序通過取消最有用驗證的重啟要求而改進了這一過程，因此可在不重新啟動系統的情況下對出現問題的服務器進行故障排除。
此外，驅動程序驗證程序還引入了三種新的驗證(如圖 3 所示)。安全檢查確保設備驅動程序在用於與應用程序連接的對象上設置了安全權限。強制掛起 I/O 請求測試了驅動程序對於需立即完成而非一段延遲後再完成的異步 I/O 操作的恢復能力。雜項檢查則確認驅動程序有無錯誤釋放使用中的資源、錯誤使用 Windows 管理規范 (WMI) 注冊 API 以及洩漏資源處理程序。
圖 3 選中 Windows Server 2008 選項的驅動程序驗證程序
可伸縮性
可伸縮性是指操作系統或應用程序有效利用多個處理器和大量內存的能力。Windows 的每個版本都會通過減少或取消使用鎖(它們會降低多處理器的平行性)來提高可伸縮性，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 中所采取的方式在相同的節點內存中分配，而不會從任何其他節點的內存中分配。
在 Windows Server 2003 中，當線程進行內存分配時，內存管理器在分配內存時將優先考慮在線程當前執行的節點中進行分配。如果線程暫時調度到非理想節點，則在此期間執行的所有分配操作都將在非理想節點中執行。所以，當線程最終回到其理想節點中執行時，它將不再像最初一樣緊挨著所分配內存中存儲的數據或代碼。
為解決這一問題，在 Windows Server 2008 中，內存管理器在所有線程內存分配時都將優先考慮線程的理想節點，即使線程正在另一節點附近執行。內存管理器還能自動了解處理器和節點之間的延遲，所以當理想節點中沒有足夠的可用內存時，它會檢查與理想節點最近的另一節點。此外，當線程引用代碼或數據時，內存管理器將把其待機列表中的頁面遷移到線程的理想節點。
希望控制分配位置的應用程序可使用新的 NUMA 內存 API，它使這些應用程序能夠為內存分配、文件映射視圖和文件映射對象指定首選節點。對於與文件映射相關的分配，內存管理器會檢查映射操作是否指定節點，然後檢查文件映射對象是否指定節點，如果兩者都未指定，則最後它將回來繼續選用線程的理想節點。
在 Windows Server 2008 之前，用於存儲或網絡 I/O 的中斷及其相關的延緩進程調用 (DPC) 能夠在任意 CPU 上執行，包括在與啟動 I/O 操作處於不同節點的 CPU 上執行。這有可能導致 I/O 操作中的數據讀取或寫入在訪問數據的節點以外的其他節點的內存中執行。
為避免這種情況，Windows Server 2008 I/O 系統將 DPC 執行定向到啟動 I/O 操作的節點中的 CPU，並且擁有支持 PCI 總線 MSI-X(消息信號中斷標准的擴展)設備的系統還可以通過使用設備驅動程序來進一步讓 I/O 在本地完成，因為這些設備驅動程序將利用 Windows Server 2008 API 將 I/O 中斷定向到啟動該 I/O 的處理器。
動態分區
讓系統更具伸縮性的一種方法是讓其支持動態增加硬件資源(如 CPU 和內存)。如果這些資源無需重啟系統即可實現更換，則此支持還能使系統更具可用性。
Windows Server 2003 支持動態內存添加功能，從而使得具有動態內存支持的服務器能在管理員添加的同時即可使用這些 RAM。Windows Server 2008 還擴展了動態內存支持，因為它可實現內存更換。
RAM 由於越來越依賴糾錯碼 (ECC) 校正而非常容易發生故障，因此在支持動態更換的服務器上，Windows Server 2008 可透明地將出現故障的內存條中的數據遷移到替換內存上。具體過程為：首先遷移操作系統所控制的數據，然後將硬件設備置於低功耗狀態來有效關閉它們，遷移內存中的剩余數據，接著恢復設備電源繼續正常操作。
Windows Server 2008 還支持處理器的動態添加和動態更換。對於動態更換，硬件必須支持備用 CPU 概念，當現有 CPU 產生故障指示時，備用 CPU 可聯機或動態添加到系統中，目前僅高端系統支持此概念。Windows Server 2008 調度程序可減緩故障 CPU 上活動的速度，並將工作轉移至替換硬件上，隨後可取出故障 CPU 並將其更換為新的備用件。
Windows Server 2008 支持處理器的動態添加，因此管理員能在不停機的情況下升級服務器的處理能力。但是，調度程序和 I/O 系統只能將新 CPU 提供給那些通過新 API 請求 CPU 到達通知的設備驅動程序和應用程序，因為某些應用程序內置假定 CPU 數量對於引導會話而言是固定的。例如，應用程序可能為每個 CPU 分配一個工作隊列，線程執行時將使用與該 CPU 關聯的隊列。如果調度程序將該應用程序的某個線程調度到新的 CPU 上，它可能會試圖引用並不存在的隊列，因而可能導致損壞應用程序的數據並很有可能致使該應用程序崩潰。
基於 Microsoft 服務器的應用程序(如 SQL Server 和 Exchange Server)能支持 CPU 動態添加，一些核心 Windows 進程也支持此功能，包括 System 進程、會話管理器進程 (%SystemRoot%\System32\Smss.exe) 和 Generic Service Hosting 進程 (%Systemroot%\System32\Svchost.exe)。其他進程也可使用 Windows API 來請求新 CPU 到達通知。當新 CPU 到達時，Windows 將向設備驅動程序通知這一情況、啟動 CPU 並隨後通知所寫入的設備驅動程序和應用程序使用新的 CPU，這樣它們就可以在需要時分配數據結構以跟蹤新 CPU 上的活動。
計算機虛擬化
在 Windows Server 2008 之前，Microsoft 就已經使用宿主虛擬化技術(如圖 5 所示)實現了包括 Virtual Server 2005 在內的各種虛擬化產品。在宿主虛擬化中，虛擬機的實現技術是在宿主操作系統上(通常是作為設備驅動程序)運行的虛擬機監控器 (VMM)。VMM 依賴宿主操作系統的資源管理和設備驅動程序，並且當宿主操作系統調度其運行時，它會在活動虛擬機 (VM) 之間對 CPU 切分時間片。
圖 5 宿主計算機虛擬化
Hyper-V(以前的代號為“Viridian”)是利用管理程序虛擬化得以實現的。管理程序完全控制著所有硬件資源，甚至引導系統和用於控制 VM 的 Windows Server 2008 操作系統本身實質上也是以虛擬機的方式運行(如圖 6 所示)。
圖 6 Hyper-V 體系結構
管理程序可將系統分成多個 VM，並將 Windows Server 2008 的引導實例當作主分區(或根分區)，以使其可直接訪問各種硬件設備(如磁盤、網絡適配器和圖形處理器)。管理程序要求根分區執行電源管理並響應硬件即插即用事件。它將截取子分區中啟動的硬件設備 I/O 並將其路由到根分區，然後根分區使用標准 Windows Server 2008 設備驅動程序來執行硬件訪問。通過這種方式，運行 Hyper-V 的服務器可以充分利用 Windows 對硬件設備的支持。
當將 Windows Server 2008 配置為具有 Hyper-V 服務器角色時，Windows 將把 hypervisorimagelaunchtypeboot 引導配置數據庫 (BCD) 設置設為 auto，並將 Hvboot.sys 設備驅動程序配置為在引導過程的前期啟動。如果配置了該選項，Hvboot.sys 將使系統做好虛擬化准備，然後將 %Systemroot%\System32\Hvax64.exe 或 %Systemroot%\System32\Hvix64.exe 加載到內存中，具體加載哪個程序取決於系統是實現 AMD-V 虛擬化擴展還是 Intel VT CPU 虛擬化擴展。
加載完成後，管理程序使用虛擬化擴展將自身插入到 Windows Server 2008 中。用戶模式的應用程序使用 x64 處理器的 Ring 3 權限級別，而內核模式代碼則在 Ring 0 上運行，因此管理程序實際是在概念權限級別 Ring -1 上運行，因為它可控制 Ring 0 上運行的代碼的執行環境。
當使用 Hyper-V 管理控制台創建或啟動子分區時，它將利用 %Systemroot%\System32\Drivers\Winhv.sys 驅動程序來與管理程序通信，該驅動程序使用公開記錄的 hypercall API 來指示管理程序創建指定物理內存大小的新分區和執行特征。根分區中的 VM 服務 (%Systemroot%\System32\Vmms.exe) 為每個子分區創建一個 VM 工作進程 (%Systemroot%\System32\Vmwp.exe) 以管理子分區的狀態。
Windows 改善子 VM 操作系統性能的其中一種方法是 Windows Server 2008 和 Windows Vista 都已實現的啟發方法(即僅當操作系統運行實現 Microsoft hypercall API 的管理程序時才會激活的代碼序列)。通過直接請求管理程序的服務，子 VM 避免了在管理程序必須猜測子操作系統的意圖時所產生的虛擬代碼開銷。
例如，未實現自旋鎖(執行底層多處理器同步)啟發方法的來賓操作系統將停在一個緊湊循環上旋轉以等待其他虛擬處理器釋放自旋鎖。此旋轉可能會阻塞其中一個硬件 CPU，直到管理程序調度第二個虛擬處理器。在啟發式操作系統中，自旋鎖代碼會在將要發生旋轉時通過 hypercall 通知管理程序，這樣管理程序可以立即調度另一個虛擬處理器並降低不必要的 CPU 使用。
Windows Server 2008 改善 VM 性能的另一種方式是加速 VM 對設備的訪問。可通過在子操作系統中安裝統稱為“VM 集成組件”的一個組件集合來增強性能。
如果運行未安裝集成組件的 VM，則子操作系統將為管理程序所提供的模擬設備配置硬件設備驅動程序。當設備驅動程序試圖使用硬件資源時，管理程序必須進行干預以便通知根分區，根分區將代表子 VM 操作系統使用標准 Windows 設備驅動程序執行設備 I/O。由於單獨的高級 I/O 操作(例如讀磁盤)可能包含多個離散的硬件訪問，所以它可能導致管理程序和根分區中出現許多稱為“截取”的轉換。
Windows Server 2008 使用以下三種組件來最小化截取：虛擬機總線驅動程序 (%Systemroot%\System32\Drivers\Vmbus.sys)、虛擬服務客戶端 (VSC) 和虛擬服務提供商 (VSP)。當利用受支持操作系統將集成組件安裝到 VM 中時，VSC 將取代設備驅動程序的角色，並使用子 VM 中的 Vmbus.sys 驅動程序服務，通過管理程序的 hypercall 和內存共享服務將高級 I/O 請求發送到根分區中的虛擬機總線驅動程序。在根分區中，Vmbus.sys 將請求轉發到相應的 VSP，然後它通過根分區的設備驅動程序來啟動標准 Windows I/O 請求。
