Permissions needed for WriteProcessMemory appear to be inaccurately documented

Question

Permissions needed for WriteProcessMemory appear to be inaccurately documented

RLWA32 52,946

The documentation for the WriteProcessMemory function states that the process handle passed to the function "must have PROCESS_VM_WRITE and PROCESS_VM_OPERATION access to the process."

This appears to be inaccurate as a handle obtained without requesting PROCESS_VM_OPERATION (PROCESS_VM_WRITE | PROCESS_VM_READ | PROCESS_QUERY_LIMITED_INFORMATION was requested) access was sufficient to write to target process memory.

This was noticed when reviewing and testing code in one of Pavel Yosifovich's repositories at https://github.com/zodiacon/youtubecode/blob/main/HideDll/HideDll/HideDll.cpp

Viorel 127.3K Reputation points

2026-11-01T15:53:51.91+00:00

Perhaps PROCESS_VM_OPERATION may be required in situations not identified through experimentation.
RLWA32 52,946 Reputation points

2026-11-01T16:49:54.44+00:00

@Viorel Following the stated requirements I have always requested PROCESS_VM_OPERATION for any code I have written that will call WriteProcessMemory.

As I watched the video that Pavel Yosifovich posted to YouTube for the code linked above I expected the call to WriteProcessMemory to fail. I think that some code failures in Yosifovich's posted videos are deliberate to illustrate a teaching point and I expected this to be one of them. So I was surprised when the call succeeded without the requisite privilege requested for the process handle being used.

I wonder if that privilege is more closely tied to the undocumented "helpful" behavior described by Raymond Chen's blog article that internally uses VirtualProtectEx.

2 answers

Your answer

Viorel 127.3K Reputation points

2026-11-01T15:53:51.91+00:00

Perhaps PROCESS_VM_OPERATION may be required in situations not identified through experimentation.
RLWA32 52,946 Reputation points

2026-11-01T16:49:54.44+00:00

@Viorel Following the stated requirements I have always requested PROCESS_VM_OPERATION for any code I have written that will call WriteProcessMemory.

As I watched the video that Pavel Yosifovich posted to YouTube for the code linked above I expected the call to WriteProcessMemory to fail. I think that some code failures in Yosifovich's posted videos are deliberate to illustrate a teaching point and I expected this to be one of them. So I was surprised when the call succeeded without the requisite privilege requested for the process handle being used.

I wonder if that privilege is more closely tied to the undocumented "helpful" behavior described by Raymond Chen's blog article that internally uses VirtualProtectEx.

Answer 1

WriteProcessMemory callers should continue requesting both PROCESS_VM_WRITE and PROCESS_VM_OPERATION; success with only PROCESS_VM_WRITE is observable implementation behavior for some writable target pages, not the documented access contract.

Why the tested call succeeds

The public contract states that the handle must contain both rights:

PROCESS_VM_WRITE permits writing to process memory.
PROCESS_VM_OPERATION permits operations on the process address space and is explicitly associated with both VirtualProtectEx and WriteProcessMemory in the process-rights table.^1^
The WriteProcessMemory reference likewise requires both rights.^2^

However, Microsoft has described WriteProcessMemory as conditionally changing page protection when the destination is read-only: it temporarily makes the page writable, writes the bytes, and restores the original protection. This debugger-oriented behavior requires the caller to be able to modify protection; otherwise that attempt fails.^3^ VirtualProtectEx itself requires PROCESS_VM_OPERATION.^4^

That produces two relevant cases:

The destination is already writable.
The current Windows implementation may complete the copy using PROCESS_VM_WRITE without performing a protection operation. This is consistent with the observed result.
The destination is not writable and WriteProcessMemory must adjust its protection.
The operation needs the authority represented by PROCESS_VM_OPERATION; a handle lacking that right cannot rely on the write succeeding.

The tested repository therefore demonstrates that PROCESS_VM_OPERATION is not necessarily checked on every successful execution path. It does not establish that the right can safely be omitted from code intended to satisfy the API contract across target pages or Windows versions.

Recommended access mask

Use the documented minimum for production code:

DWORD access =
    PROCESS_VM_WRITE |
    PROCESS_VM_OPERATION |
    PROCESS_QUERY_LIMITED_INFORMATION;

HANDLE process = OpenProcess(access, FALSE, processId);
if (!process) {
    // Handle GetLastError().
}

Add PROCESS_VM_READ only if the program also calls ReadProcessMemory; it is not part of the documented WriteProcessMemory requirement.^1^

Is the documentation inaccurate?

It is conservative rather than a precise description of every internal path. The text documents the supported permissions callers must obtain, while the implementation can avoid using PROCESS_VM_OPERATION when no address-space operation is necessary.

A useful documentation clarification would be:

Callers must request PROCESS_VM_WRITE and PROCESS_VM_OPERATION. Some implementations may successfully write to an already-writable region with only PROCESS_VM_WRITE, but applications must not rely on that behavior.

This distinction can be submitted through Feedback → This page on the WriteProcessMemory documentation page, including:

the Windows build tested;
the exact OpenProcess access mask;
the target page’s protection;
a minimal reproducer showing success without PROCESS_VM_OPERATION;
whether the same test fails against a read-only target page.

References

Answer 2

Nguyen Dam (WICLOUD CORPORATION) 1,175 Microsoft External Staff Moderator

Hello @RLWA32 and thank you for catching and bringing attention to this documentation issue.

I reproduced the behavior using WriteProcessMemory with a process handle that did not have PROCESS_VM_OPERATION, and the call still succeeded, as you observed. The GitHub code you linked provides another example where the operation succeeds without that flag.

User's image

Since the documented requirement does not appear to match the observed behavior, I suggest submitting feedback directly on the documentation page so the documentation team can clarify or correct it. Select the thumbs-down button next to Was this page helpful? You can then choose Other and describe your findings in the Tell us more box.

If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation. Thank you.

Nguyen Dam (WICLOUD CORPORATION) 1,175 Reputation points Microsoft External Staff Moderator

2026-11-05T01:50:20.34+00:00

Hi @RLWA32 ,

Just following up on the thread. I hope your further experimentation has gone well. If there’s anything else I can help with on this, please feel free to let me know.
Nguyen Dam (WICLOUD CORPORATION) 1,175 Reputation points Microsoft External Staff Moderator

2026-11-09T02:08:32.3033333+00:00

Hi @RLWA32 ,

Just one last follow-up on this thread. I hope your further experimentation has been going well. If you happen to have any new findings or questions, please feel free to share them whenever convenient.

Thanks again for taking the time to investigate and share your findings.
RLWA32 52,946 Reputation points

2026-11-09T11:55:59.2466667+00:00

@Nguyen Dam (WICLOUD CORPORATION) Up to now I have tested ReadProcessMemory and WriteProcessMemory between two process running in the same context and between a process running with elevated privileges and a process running as a standard user. The elevated process was also tested with and without enabling the Debug privilege.

Memory in the target process has been allocated by HeapAlloc, GlobalAlloc, LocalAlloc and VirtualAlloc. Naturally, allocations created by functions other than VirtualAlloc allow read/write access. I allocated 3 regions with VirtualAlloc. The 3 regions had PAGE_READ_ONLY, PAGE_READWRITE, and PAGE_EXECUTE_READ protection.

I also tested reading and writing process variables that resided in their own segments. One variable was read only and the other was read/write.

VMMap was used to examine the content of memory locations and verify protections.

For example,

As expected, reading all memory locations succeeded. In all cases, attempting to write to memory locations without PROCESS_VM_OPERATION failed with an access denied error. After obtaining a handle that had PROCESS_VM_OPERATION write attempts succeeded except for those attempted on read only memory. These failed with error code 998 - Invalid access to memory location. Interestingly, writes to memory protected as PAGE_EXECUTE_READ succeeded.

Suspending the target process before read/write attempts did not change the outcome.

The last thing for me to do is to examine the memory write requests from the HideDll repo to see if there is anything that distinguishes them from those that have failed without PROCESS_VM_OPERATION.