實體位置延伸 - PAE 記憶體與 Windows
更新日期: 2005 年 2 月 9 日
本頁內容
簡介
PAE 為 Intel 所提供的記憶體位址延伸，它可讓大多數的 32-bit (IA-32) Intel Pentium Pro 與之後的平台支援超過 4GB 的實體記憶體。本文提供了一些可以協助裝置驅動程式開發人員建置支援 PAE 的 Windows 驅動程式的資訊。
Microsoft 支援實體位址延伸 (PAE) 記憶體於 Microsoft Windows 2000、Windows XP 和 Windows Server 2003 產品：
Windows 2000 Advanced Server | 8 GB 的實體 RAM |
Windows 2000 Datacenter Server | 32 GB 的實體 RAM |
Windows XP (所有版本) | 4 GB 的實體 RAM* |
Windows Server 2003 (and SP1) Standard Edition | 4 GB 的實體 RAM* |
Windows Server 2003 Enterprise Edition | 32 GB 的實體 RAM |
Windows Server 2003 Datacenter Edition | 64 GB 的實體 RAM |
Windows Server 2003 SP1 Enterprise Edition | 64 GB 的實體 RAM |
Windows Server 2003 SP1 Datacenter Edition | 128 GB 的實體 RAM |
* 在這些 Windows 版本中實體位址空間的總容量最大為 4 GB。
PAE 僅支援於 32 位元版本的 Windows 作業系統。64 位元版本的 Windows 不支援 PAE。更多有關 64 位元版本 Windows 的裝置驅動程式與系統需求資訊，請參閱 64 位元系統設計。
雖然一般對 PAE 記憶體的聯想為支援超過 4 GB 的 RAM，但事實不僅如此，在 Windows XP SP2、Windows Server 2003 以及之後的 32 位元版本 Windows 中 PAE 還可以支援硬體強制 Data Execution Prevention (DEP)。
作業系統支援。PAE 模式能夠支援超過 4 GB RAM，但此模式並非系統的預設值。
如欲於系統啟動時即支援 PAE 記憶體，必須在 Boot.ini 檔案中對應的項目裡加上 /PAE 切換參數。若發生問題，儘管 /PAE 切換參數仍存在於 Boot.ini 檔案中，仍可使用安全模式將系統重新啟動為一般模式 (僅支援 4 GB 的 RAM)。
PAE 啟動模式需要有 Intel Architecture 處理器 (Pentium Pro 或是更新的版本)、超過 4 GB 的 RAM 以及 Windows 2000、Windows XP 或 Windows Server 2003。
若系統已啟用 DEP (具 /NOEXECUTE 切換參數) 或系統處理器支援硬體強制 DEP 則 PAE 啟動模式會自動被啟用而毋需再將 /PAE 切換參數加入啟動項目中。具支援硬體強制 DEP 且包含有 /PAE 切換參數之處理器的系統同時存在有 /NOEXECUTE 切換參數。若系統處理器具硬體強制 DEP 的能力但啟動項目中沒有 加入 /NOEXECUTE 切換參數，則 Windows 會將 /NOEXECUTE=optin 當作預設值並啟用 PAE 模式。更多相關的資訊，請參閱 Windows DDK 中的 "Boot Options in a Boot.ini File" 章節。
主機板的議題：匯流排的 DAC 性能
各式各樣的晶片組具有支援超過 4 GB 的實體記憶體的能力。Windows Datacenter 和 Advanced Server 作業系統可經由 PAE 來使用這些記憶體。
在 64 位元平台中，為了最佳的效能，所有的 PCI 介面卡 (包括 32 位元 PCI 介面卡) 皆必須能夠進行完整的實體位址空間定址作業。對於 32 位元 PCI 介面卡來說，這表示他們必須能夠支援 Dual Address Cycle (DAC) 命令以允許它們為介面卡或裝置轉譯 64 位元位址 (在此表示，位址大於 4 GB 位址空間)。在 64 位元平台中介面卡無法提供這個支援則無法直接存取完整的位址空間。
可惜的是，Microsoft 發現在主機板上不是所有的 PCI 匯流排都支援 DAC，DAC 為 32 位元 PCI 介面卡進行超過 4 GB 的記憶體定址作業時所需要的功能。此外，沒有其它的方法可以讓具 DAC 性能的 PCI 裝置 (或與它相對應的驅動程式) 知道它正執行在一個不具 DAC 性能的匯流排上。
在硬體中的這些議題，Microsoft 必須依據客戶、OEM 和 Microsoft 的觀點在作業系統中找到令人滿意的軟體解決方案。此章節中將闡述幾種因各種不適用的理由而淘汰，以及商討過後選擇出來的可能的軟體解決方案。
覆寫 Dma64BitAddress = 效能與穩定性問題
第一個軟體解決方案為要求作業系統覆寫由驅動程式傳來的 Dma64BitAddresses 為 HalGetAdapter：若驅動程式傳來 TRUE 則表示它的裝置連接到一個不支援 DAC 的匯流排上，則強制將它設為 FALSE。那是因為 Hardware Abstraction Layer (HAL) 透過 IoMapTransfer 或 GetScatterGatherList 雙重緩衝 (Double-Buffer) 轉譯完成，所以裝置就不會看到大於 4 GB 的位址。欲得知更多相關的訊息，請參閱 Windows DDK 中的 "Double-Buffer DMA Transfer" 章節。
可惜的是，HalGetAdapter 沒有足夠的資訊來判斷呼叫者裝置的匯流排。所有可知的訊息皆為驅動程式所提供的 DEVICE_DESCRIPTION 架構的內容，其中僅有相關資訊其介面類型為 PCI。
typedef struct _DEVICE_DESCRIPTION {
ULONG Version;
BOOLEAN Master;
BOOLEAN ScatterGather;
BOOLEAN DemandMode;
BOOLEAN AutoInitialize;
BOOLEAN Dma32BitAddresses;
BOOLEAN IgnoreCount;
BOOLEAN Reserved1; // must be false
BOOLEAN Dma64BitAddresses;
ULONG BusNumber; // unused for WDM
ULONG DmaChannel;
INTERFACE_TYPE InterfaceType;
DMA_WIDTH DmaWidth;
DMA_SPEED DmaSpeed;
ULONG MaximumLength;
ULONG DmaPort;
} DEVICE_DESCRIPTION, *PDEVICE_DESCRIPTION;
除此之外：
| • | 在 Microsoft，雙重緩衝 (Double-buffering) 於測試中顯示對 I/O 輸送量與 CPU 使用的效能方面有負面的影響。此負面的影響會增加更多的記憶體超出已加入的 4 GB。 |
| • | 此關聯到高效能的 I/O 與雙重緩衝 (Double-Buffering) 的延遲可能造成驅動程式與裝置的時效問題，進而影響到系統的穩定性。 |
所有的這一切都違反了 Windows Datacenter 與 Advanced Server 要增加穩定性與可靠性的目標。
IoGetDmaAdapter = 無法使用於所有的驅動程式
Windows Driver Model (WDM) 提出了 IoGetDmaAdapter() 呼叫，它相似於 HalGetAdapter，但同時採用指標 (Pointer) 於實體裝置物件 (Physical Device Object; PDO)。此舉讓作業系統能夠偵測到呼叫者的 PCI 匯流排且不論此裝置是否擁有非 DAC 匯流排的子裝置。之後 PCI 驅動程式就能夠覆蓋 DEVICE_DESCRIPTION 中的 Dma64BitAddress 欄位，因此 HAL 相信裝置僅能夠處理 32 位元的位址。
此方法的所產生的問題為不是所有的驅動程式都使用 IoGetDmaAdapter。很多驅動程式仍使用 HalGetAdapter，儘管最近的 DDK 中已明確的定義此為舊式的呼叫方式。Microsoft 無法防止協力廠商驅動程式使用 HalGetAdapter 呼叫；經由使呼叫失敗來強制驅動程式使用 IoGetDmaAdapter 同時也會使得其它驅動程式的函式失效。要求所有的驅動程式使用 IoGetDmaAdapter 同時也帶來了大量測試與效能的問題。
不正確的或沒有 DMA 常式 = 沒有可能的解決方案
無論如何不論使用 IoGetDmaAdapter 或 HalGetAdapter，並非所有的驅動程式都正確的使用 DMA 常式。有些不使用它們的驅動程式全都是因為會對效能造成影響。因為您將不意外地發現 64 位元驅動程式直接乎略 DMA 常式因為它們 "了解" 它們不需要這樣的常式。在這樣的情況下，沒有可能的作業系統解決方案--所有導致驅動程式不正確的原因都會被發現並修正。
連接至非 DAC 匯流排或是所有的匯流排皆為非 DAC 匯流排的啟動裝置 = 沒有較大的記憶體支援
除了上述的許多有關非 DAC 匯流排的問題之外，還有兩個特別的案例：
| • | 連接至非 DAC 匯流排的啟動裝置。第一個案例為啟動裝置連接至非 DAC 的匯流排。假設分頁檔案存在於啟動裝置且此為主要的資料路徑，然後所有分頁檔案 I/O 都會被迫變為雙重緩衝，消極地影響系統效能進而可能造成系統不穩定。 |
| • | 所有的匯流排皆為非 DAC 匯流排。第二個案例為所有的匯流排皆為非 DAC 匯流排，在這個狀況下使用者無法選擇將 DAC 介面卡、具 LME 功能的介面卡或是兩者移至 DAC 匯流排。這個案例僅有一個方式可以解決就是將記憶體支援限制在 4 GB，而不管其處理器、記憶體控制器或是主機板是否支援超過 4 GB 的 RAM。 |
Microsoft 並不預期任何第二個案例與少數第一個案例的情況，但我們必須將這個可能性考慮進去以定義出完整的方案。
選用的方案：當非 DAC 匯流排存在時停用超過 4 GB 記憶體
因為 Microsoft 並沒有可靠的軟體解決方案可以解決這個問題，只好採用另一個方式就是停用此種組態，它將無法運作且通知管理員此問題。若有任何非 DAC 匯流排則停用所有大於 4 GB 的記憶體此為這個案例中唯一可以防止不穩定性的方法。Microsoft 認為這對客戶來說是最佳的方案，因為它是對平台造成最少影響的方法。
下列的表格概述了這個想法。
DAC | DAC | 最佳效能與穩定性。 |
DAC | Non-DAC | 需要雙重緩衝。
1 2 |
Non-DAC | DAC | 記憶體損毁可能是因為與 PCI 標準不一致；Windows 採取特別的動作來防止。3 |
Non-DAC | Non-DAC | 需要雙重緩衝。4 |
如果您，IxV，使用且測試使用者模式程式碼 [而這幾乎普遍是確定的] 這是一個您必須涵括的測試案例。您必須確定您所測試的程式碼能夠正確地處理高階的虛擬位址，特別是高於 2 GB 的虛擬位址。您的應用程式或公用程式應該連同 Windows 一起測試以確定它們可以執行。
通常，VirtualAlloc 會由低階到高階的方式傳回虛擬位址。所以，除非您的處理程序配置大量的記憶體或它擁有非常破碎的虛擬位址空間，否則它將不會取得高階的位址。這可能造成高階位址的 Bug 無法被發現。在 Windows Server 2003、Datacenter Edition 與 Enterprise Edition 作業系統中有一個簡單的方法可以將配置的順序改為由高至低，而這個功能則能夠揭露許多重要的 bug。
您需要設定 HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management\AllocationPreference REG_DWORD = 0x100000
所有應用程式，特別是在原始檔案中使用 LINKER_FLAGS=/LARGEADDRESSAWARE 來建置的這些應用程式，都應該測試 /PAE、/NOLOWMEM 和 /3GB 切換參數的使用與登錄項目的變更。
沒有特定的硬體要求進行 MEM_TOP_DOWN 的測試。任何執行 Windows Server 2003、Datacenter Edition 或 Enterprise Edition 作業系統都支援這個測試。
MEM_TOP_DOWN 亦可使用於 Itanium 基礎的系統。不過，/3GB 是為 x86 特定的功能。
/PAE、/NOLOWMEM 與 /3GB 切換參數，以及登錄項目變更，可同時使用。注意 /3GB 將阻止存取超過 16 GB 的實體記憶體因為核心記憶體空間已因 /3GB 切換參數而減少，而且當記憶體大於 16 GB 時，結果將會造成沒有足夠的空間容納所要求的額外的分頁表格項目 (Page Table Entry)。
介面卡與驅動程式議題：LME 和 DAC 功能
所有實體記憶體皆被視為一般用途的記憶體，因此沒有新的 API 需要去取存 I/O 高於 4 GB 實體記憶體位置。此外，也能完成直接 I/O 大於 4 GB 實體記憶體位址--這需要具 DAC 功能或 64 位元 PCI 裝置。裝置和驅動程式可考慮 Large Memory Enabled (LME)，讓它們能夠處理直接 I/O 大於 4 GB。
因為 Windows 沒有 Kernel PAE 或 LME API 或介面，PAE-X86 Kernel 肯定有很多項目是與標準 Kernel 相同，包括：
| • | Kernel 記憶體空間組織沒有變更。 |
| • | PCI 基礎的位址登錄項 [BAR] 也保持相同。 |
| • | 登錄旗標作用相同。 |
| • | 未分頁集區大小亦保持相同。 |
| • | 3GT 功能支援超過 16 GB RAM。 |
| • | IMAGE_FILE_LARGE_ADDRESS_AWARE 依舊可以使用。 |
| • | "常用的" Kernel 位址維持在相同的位置。 |
不過，仍需要小心開發裝置驅動程式。硬體裝置 LME 驅動程式應具有 DAC 功能或 64 位元能力；否則，裝置將依舊處於 "傳統的" 32 位元狀態並將使用雙重緩衝，且具有相對較低的效能。
雖然雙重緩衝在 8 GB 系統中可具相對較小的影響 (單一百分點），仍會對需要大量 I/O 的工作造成影響像是資料庫作業。這也有賴於許多不在 Microsoft 控制之下的因素，像是硬體設計和裝置驅動程式最佳化 (如插斷仲裁和有效運用 PCI 匯流排)。隨著實體記憶體的數量資加，與 DAC/64 位元裝置和 LME 驅動程式相較之下的負面影響也跟著加大。
可用於 LME 驅動程式的一般指南
以下指南有助於防止 LME 驅動程式失敗：
| • | 請勿使用 PVOID64。在任何地方使用 PVOID64 都會傳回錯誤資訊，因為此呼叫並不會在 Intel Architecture 平台上傳回有效的資訊。請改用 PHYSICAL_ADDRESS。 注意：這並不適用於 NDIS Miniport。另外，諸如 USB 和其他有相當低效能的 Miniport，並不需要重新改寫成 LME，因為效能的提昇和折損並不明顯。不過，這些 Miniport 應正確使用 Windows 的核心介面，而不是試圖利用未記載和不支援的捷徑來欺騙作業系統。 |
| • | 請勿在鎖定的緩衝區呼叫 MmGetPhysicalAddress()，捨棄高階的 32 位元，然後將 DMA 的介面卡寫入結果位址。這肯定會造成記憶體損毀、遺失 I/O 和系統失敗。假設進行此呼叫，請確定使用傳回的全部位址資訊，而且驅動程式能正確運作於 64 位元位址。 |
| • | 請勿在操控實體位址時，使用 PVOID。因為 PVOID 只是 32 位元，會發生位址截斷，而且會造成記憶體損毀。 |
| • | 請勿在操控實體位址時，使用 ULONG，因為這與 PVOID 具有一模一樣的預警和行為：系統失敗。 |
| • | 當嘗試避免 HAL (「對應暫存器」) 所提供的緩衝處理不為真時，請勿在 DEVICE_DESCRIPTION 中表示對散佈/聚集的支援。 |
| • | 若驅動程式無法支援 64 位元位址，在呼叫 IoMapTransfer(...) 請切記要使用 AdapterControl(...) 函式 (再次提醒您，記得要迴避相對應的登錄項目)，並且不要將 MapRegisterBase 的值設為零。這將會造成失敗。 |
其它的函式與呼叫可能會失敗。相關資訊皆列示於 Windows DDK 中。
NDIS Miniport 與 SCSI Miniport 指南
PAE 系統中的 NDIS Miniport 指南
具 64 位元位址功能的網路介面卡應該：
| • | 使用 NDIS 散佈/聚集 DMA 模型。
Miniports 需要在 Dma64Addresses = TRUE 時呼叫 NdisMInitializeScatterGatherDma。 |
| • | 使用還原序列化的 Miniport 驅動程式模型。
Miniport 應該還原序列化以便在 Windows Datacenter 和 Advanced Server 作業系統上獲得最佳效能。 |
請參閱 DDK 文件中 NdisMInitializeScatterGatherDma 項目之相關資訊。
一般指南
NDIS Miniport 應注意下列事項：
| • | 使用 NdisMAllocateSharedMemory 所配置的記憶體保證不會跨越 4 GB 的界限。 |
| • | NDIS_PER_PACKET_INFO_FROM_PACKET(ScatterGatherListPacketInfo) 對於支援散佈/聚集 DMA 的 Miniport 永遠不會傳回 NULL。 |
| • | SCATTER_GATHER_ELEMENT 所指示的實體位址範圍不會跨越 4-GB 的界限。假若虛擬記憶體緩衝區真的跨越 4-GB 的界限，將分成兩個散佈/聚集項目。 |
適用於 32 位元只有位址網路裝置的指南
下列為建議適用於 32 位元只有位址網路裝置的指南：
| • | 適當編寫的 NDIS 驅動程式在 PAE 系統上將以現狀運作，但會隨著安裝的 RAM 量的增加，對效能產生明顯的負面衝擊。 |
| • | NdisMStartBufferPhysicalMapping 會將 4 GB 位址以上的所有片段，複製到低於 4 GB 標記的記憶體。 |
適用於 64 位元具備位址功能 SCSI Miniport 的指南
(內含 SCSI 2 所有相關的介面卡)
下列為建議適用於 64 位元具備位址功能 SCSI Miniport 的指南：
| • | Miniport 需要支援散佈/聚集 DMA。它們一定不能呼叫任何從屬模式 DMA 常式：ScsiPortFlushDma 或是 ScsiPortIoMapTransfer。 |
| • | Miniport 應該檢查 PORT_CONFIGURATION_INFORMATION 中 Dma64BitAddresses 的值，來判斷是否支援 64 位元實體位址。若支援 64 位元實體位址，則 Miniport 應該變更其延伸模組大小，以容納較大的實體位址 (若有必要的話)，並在呼叫 ScsiPortGetUncachedExtension之前，將Dma64BitAddresses 欄位設定為 SCSI_DMA64_MINIPORT_SUPPORTED。 |
| • | Miniport 一定不能嘗試使用虛擬位址存取資料緩衝區，除非它們已設定 PORT_CONFIGURATION_INFORMATION 結構中的 MapBuffers 位元。此規則的例外是 INQUIRY 和 REQUEST_SENSE 作業，它們永遠具有有效的虛擬位址。 |
| • | 使用 SCSI_PHYSICAL_ADDRESS 來存取所有的實體位址。 |
| • | 未快取的延伸模組和 SRB 延伸模組不會跨越 4 GB 的界限。 |
| • | 沒有散佈/聚集項目會跨越 4 GB 的界限。 |
舊式 SCSI Miniport 的指南
下列為建議適用於舊式 SCSI Miniport 的指南：
| • | Miniport 不需要支援散佈/聚集 DMA。它們一定不能呼叫任何從屬模式 DMA 常式：ScsiPortFlushDma 或 ScsiPortIoMapTransfer。 |
| • | 一定不能嘗試使用虛擬位址存取資料緩衝區，除非它們已設定 PORT_CONFIGURATION_INFORMATION 結構中的 MapBuffers 位元。此規則的例外是 INQUIRY 和 REQUEST_SENSE 作業，它們永遠具有有效的虛擬位址。 |
| • | 除非絕對必要，否則 Miniport 不應該設定 MapBuffers 位元，因為在 LME 系統上提供有效的虛擬位址給 32 位元驅動程式犧牲很大。 |
建立和測試 LME 驅動程式
使用下列的檢查點來建立並測試 LME 驅動程式：
| • | 當將驅動程式修改為支援具 Large Memory 的系統時請勿嘗試同時加入更多的功能。寧可，盡可能變更越少越好以確定 LME 功能正常。 |
| • | 請永遠使用最新版本的 Hardware Compatibility Test (HCT) 來進行作業它放置於：http://www.microsoft.com/taiwan/whdc/DevTools/HCTKit.mspx。 |
| • | 使用所有 Microsoft 所提供的工具，同時測試系統使用超過 4 GB 的實體記憶體與使用低於 4 GB 的系統記憶體兩種情況。 |
| • | 測試舊有的驅動程式以確定沒有因為不正確的呼叫 (像是 MmGetPhysicalAddress) 所造成的毁損。 |
| • | PAE 系統的測試規格。這需要至少安裝有 6 GB 的 RAM。 |
| • | 在 Boot.ini 檔案中測試 NOLOWMEM 切換參數的使用： | • | 以保證 64 位元實體位址大於 4 GB。 | | • | 低於 4 GB 時隱藏分頁。 | | • | 使用特有的模式填滿低於 4 GB 的分頁。
工作管理員中將顯示粗略地 RAM 使用總量為 ~4 GB。 |
|
| • | 測試同時使用 /3GB 切換參數 | • | 變更核心記憶體環境以使得驅動程式的問題曝光 | | • | 將核心記憶體空間減少至 1 GB |
|
| • | 測試 MEM_TOP_DOWN 登錄項設定的使用
此舉將強制所有的記憶體配置由原來的由低至高的優先順序改變成為由高至低配置。
設定 HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management\AllocationPreference REG_DWORD = 0x100000 |
| • | 測試使用 DevCtl (HCT 中所提供的)： | • | 故意透過 IOCTL 來攻擊驅動程式。 | | • | 測試異常處理與失敗模式，並測試經由非預期的進入點進到驅動程式。 | | • | 搜尋並使緩衝區因為太小以致於無法容納回傳的資料。 | | • | 檢查 IOCTL/FSCTL 於：
- 遺漏、太小或太大的緩衝區
- 非同步變更資料
- 錯誤的指標
- 非同步的緩衝區對應變更。 | | • | 使用同步與非同步兩種方式發送要求到裝置。 | | • | 測試 IRP 取消、延遲與 Null | | • | 檢查漏失 (Leak)、Pooltag 以及 Lookaside 資訊。 |
|
| • | 測試使用 Driver Verifier (Windows 內提供)： | • | 所有集區配置是各自分開以檢查是否有毁損情況。 | | • | 進行記憶體壓力測試--無論何時 IRQL 或 Spinlock 都可取得，嘗試將驅動程式搬入分頁中；擷取嚴重錯誤。 | | • | 所有 Spinlock、IRQL 以及集區要求與釋出需要大量的錯誤檢查：Spinlock 的重覆釋出、未初始化之變數的使用、集區的其它表單損毁等等 |
|
疑難排解 DAC 支援與 LME 驅動程式
下列的檢查點將能夠幫助所有 OEM、IHV 以及客戶來判斷是否有任何與支援 DAC 與LME 的主機板、匯流排或介面卡相關的問題。
| • | 若驅動程式在初始化時失敗，請與系統 OEM 連繫以判斷是否系統所有的 PCI 匯流排皆支援 DAC。 |
| • | 若網路卡驅動程式在網路連線時立即出現錯誤檢查，請查看是否所有的匯流排皆支援 DAC，您可直接詢問 OEM 廠商。 |
| • | 若系統中的 PCI 匯流排皆支援 DAC 功能，請檢查硬體驅動程式是否與 PCI 2.1 相容。 |
| • | 若此匯流排支援 DAC 且裝置也與 PCI 2.1 相容，請檢查驅動程式有關實體位址所做的假設。 |
有關 PAE 記憶體支援文件提供於 Windows DDK 中。提供給客戶的摘要資訊包含於下列章節中。
PAE 的硬體要求
系統最少必須符合下列要求：
| • | x86 Pentium Pro 處理器或更新版本 |
| • | 超過 4 GB 的 RAM |
| • | 450 NX 或相容的晶片組與支援，或更新版本 |
啟用 PAE
欲啟用 PAE：
| • | 找到 Boot.ini 檔案，它通常存在於根目錄中 (例如，C:/) 並將唯讀與隱藏檔案屬性移除。 |
| • | 使用文字編輯工具開啟 Boot.ini 檔案，將 /PAE 參數加到 ARC 路徑，如同下列範例所示：
multi(0)disk(0)rdisk(0)partition(2)
\WINNT="Windows ???? Datacenter Server" /PAE /basevideo /sos
|
| • | 在 [檔案] 功能表中，按一下 [儲存]。 |
| • | 重新將唯讀檔案屬性加到 Boot.ini 檔案。 |
疑難排解特別的案例
下列有兩個可能發生的案例，以及修正問題的方法。
問題：在 PAE 啟用後電腦無法開機。
原因：您的硬體可能不支援 PAE。
解決方法：於安全模式下啟動系統，意即停用 PAE。然後將 /PAE 切換參數由 Boot.ini 檔案中移除。
執行安全模式的方式：
1. | 當您看見 "請選擇您想要啟動的作業系統：" 時按下 F8。 |
2. | 使用上下鍵來選擇合適的安全模式選項，然後按下 ENTER 鍵。
欲使用數字鍵盤上的移動鍵來選擇項目，請切記將 NUMLOCK 關閉。 |
問題：PAE 啟用之後，電腦執行一段時間然後出現 Stop 錯誤。
原因：您的硬體可能不支援 PAE。
解決方案：連絡您的硬體廠商取得更新的驅動程式。若您的硬體或驅動程式不具有支援 PAE 的能力，您可以利用將 /PAE 切換參數由 Boot.ini 檔案中移除的方式來停用 PAE。若您必須停用 PAE 但您的系統處理器支援硬體強制的 DEP，請將 /NOPAE /NOEXECUTE=alwaysoff 加入您的 Boot.ini 檔案。注意：這個動作將會停用您電腦的 DEP 功能。
LME 與具 DAC 功能的裝置接下來的工作
