| Previous | Next |
| ERROR_INSTALL_REJECTED | ERROR_NOT_SAME_OBJECT |
ERROR_DYNAMIC_CODE_BLOCKED
Dynamic code generation is disabled for this process.
ERROR_DYNAMIC_CODE_BLOCKED is Win32 error 1655 (0x677). Windows can apply a process mitigation that prevents creation of executable writable memory, conversion of writable pages to executable pages, or modification of existing executable code. The policy is intended to reduce code-injection and memory-corruption risk. It commonly affects JIT compilers, instrumentation engines, profilers, emulators, hot-patching systems, and legacy plug-ins that emit machine code.
Operations that can trigger the block
- a JIT allocates writable memory and then requests executable protection
- software attempts to patch instructions in an already loaded module
- an injector or profiler writes a trampoline into the target process
- a plug-in framework loads code produced after the process mitigation became active
- a thread expects an opt-out that the process policy did not allow or the thread never set
Policy and call data to log
Record the failing API, requested allocation size and protection flags, target process and module, current PROCESS_MITIGATION_DYNAMIC_CODE_POLICY values, creation-time mitigation attributes, thread opt-out state where applicable, application-control policy, and whether the operation is first-party JIT, diagnostics, or unknown code injection. Avoid logging generated machine-code bytes unless a secure diagnostic workflow explicitly requires them.
How to diagnose safely
Query the effective mitigation policy in the affected process and reproduce from process start, because many mitigation choices cannot be relaxed later. Identify the component issuing the executable-memory transition. Compare a supported configuration with the failing one and determine whether the product has an interpreter, ahead-of-time compilation, or brokered helper mode.
Check whether enterprise exploit-protection settings, application manifests, process-creation attributes, or a parent process enabled the policy. For sanctioned debugging or profiling, use a tool documented to support protected targets rather than disabling security globally. Treat unexplained attempts to create dynamic code as a potential security signal.
Resolution and design choices
Update or configure the component to operate without runtime code generation, or launch a separately scoped helper process whose security policy intentionally permits it. Change mitigation policy only after threat review and only for the specific executable that requires the capability. A simple retry in the same process cannot overcome an effective prohibition.
Developers should detect the policy before initializing a JIT, provide a non-JIT path, avoid writable-and-executable mappings, and document incompatibility with exploit-protection settings. Telemetry should distinguish policy enforcement from allocation failure.
Difference from memory exhaustion or CFG
ERROR_NOT_ENOUGH_MEMORY means the allocation could not be satisfied. Error 1655 means security policy rejected dynamic executable code. ERROR_STRICT_CFG_VIOLATION instead concerns loading an image that does not meet the process Control Flow Guard requirement.
Example
A document viewer enables strict exploit protection. Its scripting engine tries to start a JIT and receives 1655 while ordinary heap allocation still succeeds. Switching the engine to interpreter mode preserves the mitigation and restores functionality without granting executable-write capability to the entire process.
References
- Microsoft: System Error Codes (1300–1699)
- Microsoft: PROCESS_MITIGATION_DYNAMIC_CODE_POLICY
- Microsoft: GetProcessMitigationPolicy
Looking for a different code? Search another status or error code.