Skip to content

Latest commit

 

History

History
116 lines (85 loc) · 5.63 KB

nf-memoryapi-virtualprotectex.md

File metadata and controls

116 lines (85 loc) · 5.63 KB
UID title description helpviewer_keywords old-location tech.root ms.assetid ms.date ms.keywords req.header req.include-header req.target-type req.target-min-winverclnt req.target-min-winversvr req.kmdf-ver req.umdf-ver req.ddi-compliance req.unicode-ansi req.idl req.max-support req.namespace req.assembly req.type-library req.lib req.dll req.irql targetos req.typenames req.redist ms.custom f1_keywords dev_langs topic_type api_type api_location api_name
NF:memoryapi.VirtualProtectEx
VirtualProtectEx function (memoryapi.h)
Changes the protection on a region of committed pages in the virtual address space of a specified process.
VirtualProtectEx
VirtualProtectEx function
_win32_virtualprotectex
base.virtualprotectex
winbase/VirtualProtectEx
base\virtualprotectex.htm
base
6afd7ae6-e4c5-483c-a638-c85781674c7b
5/18/2022
VirtualProtectEx, VirtualProtectEx function, _win32_virtualprotectex, base.virtualprotectex, winbase/VirtualProtectEx
memoryapi.h
Windows.h, Memoryapi.h
Windows
Windows XP [desktop apps \| UWP apps]
Windows Server 2003 [desktop apps \| UWP apps]
onecore.lib
Kernel32.dll
Windows
19H1
VirtualProtectEx
memoryapi/VirtualProtectEx
c++
APIRef
kbSyntax
DllExport
Kernel32.dll
API-MS-Win-Core-memory-l1-1-0.dll
KernelBase.dll
API-MS-Win-Core-memory-l1-1-1.dll
API-MS-Win-Core-memory-l1-1-2.dll
API-MS-Win-Core-memory-l1-1-3.dll
API-MS-Win-DownLevel-Kernel32-l1-1-0.dll
MinKernelBase.dll
API-MS-Win-Core-Memory-L1-1-4.dll
VirtualProtectEx

VirtualProtectEx function

-description

Changes the protection on a region of committed pages in the virtual address space of a specified process.

-parameters

-param hProcess [in]

A handle to the process whose memory protection is to be changed. The handle must have the PROCESS_VM_OPERATION access right. For more information, see Process Security and Access Rights.

-param lpAddress [in]

A pointer to the base address of the region of pages whose access protection attributes are to be changed.

All pages in the specified region must be within the same reserved region allocated when calling the VirtualAlloc or VirtualAllocEx function using MEM_RESERVE. The pages cannot span adjacent reserved regions that were allocated by separate calls to VirtualAlloc or VirtualAllocEx using MEM_RESERVE.

-param dwSize [in]

The size of the region whose access protection attributes are changed, in bytes. The region of affected pages includes all pages containing one or more bytes in the range from the lpAddress parameter to (lpAddress+dwSize). This means that a 2-byte range straddling a page boundary causes the protection attributes of both pages to be changed.

-param flNewProtect [in]

The memory protection option. This parameter can be one of the memory protection constants.

For mapped views, this value must be compatible with the access protection specified when the view was mapped (see MapViewOfFile, MapViewOfFileEx, and MapViewOfFileExNuma).

-param lpflOldProtect [out]

A pointer to a variable that receives the previous access protection of the first page in the specified region of pages. If this parameter is NULL or does not point to a valid variable, the function fails.

-returns

If the function succeeds, the return value is nonzero.

If the function fails, the return value is zero. To get extended error information, call GetLastError.

-remarks

The access protection value can be set only on committed pages. If the state of any page in the specified region is not committed, the function fails and returns without modifying the access protection of any pages in the specified region.

The PAGE_GUARD protection modifier establishes guard pages. Guard pages act as one-shot access alarms. For more information, see Creating Guard Pages.

It is best to avoid using VirtualProtectEx to change page protections on memory blocks allocated by GlobalAlloc, HeapAlloc, or LocalAlloc, because multiple memory blocks can exist on a single page. The heap manager assumes that all pages in the heap grant at least read and write access.

When protecting a region that will be executable, the calling program bears responsibility for ensuring cache coherency via an appropriate call to FlushInstructionCache once the code has been set in place. Otherwise attempts to execute code out of the newly executable region may produce unpredictable results.

-see-also

Memory Management Functions

Memory Protection Constants

Virtual Memory Functions

VirtualAlloc

VirtualProtect

VirtualQueryEx