| Previous | Next |
| ERROR_PREDEFINED_HANDLE | ERROR_SERVICE_NOTIFICATION |
ERROR_WAS_UNLOCKED
A memory page was unlocked as a side effect of changing protection
ERROR_WAS_UNLOCKED corresponds to Win32 error value documented as: {Page Unlocked} The page protection of a locked page was changed to 'No Access' and the page was unlocked from memory and from the process. The affected page had been locked in physical memory, but a protection change made it inaccessible and Windows removed the lock. The return conveys a state transition that callers may need to account for rather than a simple failure.
Where the result appears in real systems
- Low-level memory managers combining VirtualLock with VirtualProtect.
- Debuggers and instrumentation engines changing page access.
- Security software temporarily marking regions as no-access.
Evidence to collect before changing the system
log the base address, region size, old and requested protection flags, and whether VirtualLock previously succeeded; inspect the complete region with VirtualQuery; confirm that page boundaries and sizes are calculated correctly
Keep the original numeric value, symbolic name, API return path, thread and process identity, and the exact timestamp in one diagnostic record. Those fields prevent later layers from replacing this specific result with a generic failure and make correlation with ETW or Event Viewer practical.
Handling and recovery
Treat the page as no longer locked and rebuild the intended sequence explicitly. If the page must remain resident, restore an accessible protection first and call VirtualLock again only after checking the security and resource implications.
Code that receives this result should classify it according to the operation that produced it: completion information, a recoverable environmental condition, or a programming defect. The result classification should be made at the API boundary where the caller still knows the handle, object, flags, and expected state.
What not to infer from this code
This result differs from ERROR_NOT_LOCKED: it reports that a page had been locked and then lost that state because another operation changed its protection.
Implementation guidance
Preserve this result through logging and telemetry instead of immediately converting it to free-form text. When it crosses an HRESULT boundary, record both the original Win32 value and the converted HRESULT; when it crosses RPC, JSON, or another protocol, include an explicit error-domain field so the receiver does not convert it twice.
A useful automated test for this Win32 error should reproduce the relevant state transition, assert the exact returned value, and verify cleanup after both the normal and exceptional path. The test for this Win32 error should also check that a retry is performed only when the underlying state can genuinely change, because unconditional retries often hide ownership, architecture, power, or resource-negotiation defects.
References
Looking for a different code? Search another status or error code.