VirtualAllocEx 函式 (memoryapi.h)
在指定進程的虛擬位址空間內保留、認可或變更記憶體區域的狀態。 函式會初始化它配置給零的記憶體。
若要指定實體記憶體的 NUMA 節點,請參閱 VirtualAllocExNuma。
語法
LPVOID VirtualAllocEx(
[in] HANDLE hProcess,
[in, optional] LPVOID lpAddress,
[in] SIZE_T dwSize,
[in] DWORD flAllocationType,
[in] DWORD flProtect
);
參數
[in] hProcess
進程的句柄。 函式會在此進程的虛擬位址空間內配置記憶體。
句柄必須具有 PROCESS_VM_OPERATION 訪問許可權。 如需詳細資訊,請參閱 處理安全性和訪問許可權。
[in, optional] lpAddress
指標,指定您想要配置之頁面區域所需的起始位址。
如果您要保留記憶體,函式會將此位址捨入到最接近的配置數據粒度倍數。
如果您要認可已保留的記憶體,函式會將此位址捨入到最接近的頁面界限。 若要判斷頁面的大小和主計算機上的配置粒度,請使用 GetSystemInfo 函式。
如果 lpAddress 為 NULL,函式會決定要配置區域的位置。
如果此位址位於您尚未呼叫 InitializeEnclave 來初始化的記憶體保護區內, VirtualAllocEx 會為該位址的記憶體保護區配置零頁。 頁面必須先前未認可,且不會使用 Intel Software Guard Extensions 程式設計模型的 EEXTEND 指令來測量。
如果您在初始化的記憶體保護區內位址,則配置作業會失敗,並出現 ERROR_INVALID_ADDRESS 錯誤。 這適用於不支援動態記憶體管理 (的記憶體保護區,也就是SGX1) 。 SGX2 記憶體保護區將允許配置,而且在配置頁面之後,記憶體保護區必須接受該頁面。
[in] dwSize
要配置的記憶體區域大小,以位元組為單位。
如果 lpAddress 為 NULL,函式會將 dwSize 四捨五入至下一個頁面界限。
如果 lpAddress 不是 NULL,此函式會配置範圍中包含一或多個字節的所有頁面,範圍從 lpAddress 到 lpAddress+dwSize。 例如,這表示跨越頁面界限的 2 位元組範圍會導致函式配置這兩個頁面。
[in] flAllocationType
記憶體配置的類型。 此參數必須包含下列其中一個值。
值 | 意義 |
---|---|
|
針對指定的保留記憶體頁面,配置記憶體費用 (磁碟上的整體大小和分頁檔案) 。 函式也保證當呼叫端稍後存取記憶體時,內容會是零。 除非實際存取虛擬位址,否則不會配置實際實體頁面。
若要在一個步驟中保留和認可頁面,請使用 呼叫 VirtualAllocEx 除非已保留整個範圍,否則嘗試指定沒有MEM_RESERVE且非 NULLlpAddress 會指定MEM_COMMIT來認可特定位址範圍。 產生的錯誤碼 ERROR_INVALID_ADDRESS。 嘗試認可已認可的頁面並不會讓函式失敗。 這表示您可以認可頁面,而不需要先判斷每個頁面的目前承諾用量狀態。 如果 lpAddress 指定記憶體保護區內的位址, flAllocationType 必須 MEM_COMMIT。 |
|
保留進程虛擬位址空間的範圍,而不需在記憶體或磁碟上的分頁檔案中配置任何實際實體記憶體。
您可以使用 MEM_COMMIT再次呼叫 VirtualAllocEx 來認可保留的頁面。 若要在一個步驟中保留和認可頁面,請使用 呼叫 VirtualAllocEx 其他記憶體配置函式,例如 malloc 和 LocalAlloc,在釋放之前,無法使用保留的記憶體。 |
|
表示 lpAddress 和 dwSize 所指定的記憶體範圍中的數據不再感興趣。 頁面不應該讀取或寫入至分頁檔案。 不過,稍後會再次使用記憶體區塊,因此不應予以認可。 此值不能與任何其他值搭配使用。
使用此值不保證以 MEM_RESET 運作的範圍會包含零。 如果您想要範圍包含零,請取消認可記憶體,然後重新認可它。 當您使用 MEM_RESET時, VirtualAllocEx 函式會忽略 fProtect 的值。 不過,您仍必須將 fProtect 設定為有效的保護值,例如 PAGE_NOACCESS。 如果您使用 MEM_RESET,且記憶體範圍對應至檔案,VirtualAllocEx 會傳回錯誤。 只有在共享檢視對應至分頁檔案時才可接受。 |
|
MEM_RESET_UNDO 應該只在先前成功套用 MEM_RESET 的位址範圍上呼叫。 它表示 lpAddress 和 dwSize 所指定記憶體範圍中的數據對呼叫端感興趣,並嘗試反轉 MEM_RESET的效果。 如果函式成功,這表示指定位址範圍中的所有數據都保持不變。 如果函式失敗,則位址範圍中至少有一些數據已取代為零。
此值不能與任何其他值搭配使用。 如果在先前未MEM_RESET的位址範圍上呼叫MEM_RESET_UNDO,則行為未定義。 當您指定 MEM_RESET時, VirtualAllocEx 函式會忽略 flProtect 的值。 不過,您仍必須將 flProtect 設定為有效的保護值,例如 PAGE_NOACCESS。 Windows Server 2008 R2、Windows 7、Windows Server 2008、Windows Vista、Windows Server 2003 和 Windows XP: 在 Windows 8 和 Windows Server 2012 之前,不支援MEM_RESET_UNDO旗標。 |
此參數也可以依指示指定下列值。
值 | 意義 |
---|---|
|
使用 大型頁面支援來配置記憶體。
大小和對齊方式必須是大頁最小值的倍數。 若要取得此值,請使用 GetLargePageMinimum 函式。 如果您指定此值,您也必須指定 MEM_RESERVE 和 MEM_COMMIT。 |
|
保留可用來對應 位址視窗延伸 模組的位址範圍, (AWE) 頁面。
此值必須與 MEM_RESERVE 搭配使用,且沒有其他值。 |
|
以最高可能位址配置記憶體。 這比一般配置慢,特別是在有許多配置時。 |
[in] flProtect
要配置之頁面區域的記憶體保護。 如果認可頁面,您可以指定任何一個 記憶體保護常數。
如果 lpAddress 指定記憶體保護區內的位址, flProtect 不能是下列任何值:
- PAGE_NOACCESS
- PAGE_GUARD
- PAGE_NOCACHE
- PAGE_WRITECOMBINE
配置記憶體保護區的動態記憶體時, flProtect 參數必須 PAGE_READWRITE 或 PAGE_EXECUTE_READWRITE。
傳回值
如果函式成功,則傳回值是頁面配置區域的基位址。
如果函式失敗,傳回值為 NULL。 若要取得擴充的錯誤資訊,請呼叫 GetLastError。
備註
每個頁面都有相關聯的 頁面狀態。 VirtualAllocEx 函式可以執行下列作業:
- 認可保留頁面的區域
- 保留免費頁面的區域
- 同時保留並認可免費頁面的區域
您可以使用 VirtualAllocEx 來保留頁面區塊,然後對 VirtualAllocEx 進行其他呼叫,以認可保留區塊中的個別頁面。 這可讓進程保留其虛擬位址空間的範圍,而不需要耗用實體記憶體,直到需要為止。
如果 lpAddress 參數不是 NULL,函式會使用 lpAddress 和 dwSize 參數來計算要配置的頁面區域。 整個頁面範圍的目前狀態必須與 flAllocationType 參數所指定的配置類型相容。 否則,函式會失敗,且未配置任何頁面。 此相容性需求不會排除認可已認可的頁面;請參閱上述清單。
若要執行動態產生的程式代碼,請使用 VirtualAllocEx 來配置記憶體和 VirtualProtectEx 函式來授 與PAGE_EXECUTE 存取權。
VirtualAllocEx 函式可用來在指定進程的虛擬位址空間內,保留 AWE (AWE) 記憶體區域的位址視窗延伸模組。 然後,您可以使用此記憶體區域,將實體頁面對應至應用程式所需的虛擬記憶體和虛擬記憶體外。 必須在 AllocationType 參數中設定MEM_PHYSICAL和MEM_RESERVE值。 不得設定 MEM_COMMIT 值。 頁面保護必須設定為 PAGE_READWRITE。
VirtualFreeEx 函式可以取消認可頁面、釋放頁面的記憶體,也可以同時解除認可並釋放認可的頁面。 它也可以釋放保留頁面,使其成為免費頁面。
建立將可執行的區域時,呼叫程式會負責在程式代碼設定完成之後,透過適當的 FlushInstructionCache 呼叫來確保快取一致性。 否則,嘗試從新可執行區域執行程序代碼可能會產生無法預期的結果。
規格需求
需求 | 值 |
---|---|
最低支援的用戶端 | Windows XP [傳統型應用程式 |UWP 應用程式] |
最低支援的伺服器 | Windows Server 2003 [傳統型應用程式 |UWP 應用程式] |
目標平台 | Windows |
標頭 | memoryapi.h (包括 Windows.h、Memoryapi.h) |
程式庫 | onecore.lib |
DLL | Kernel32.dll |
另請參閱
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應