| Previous | Next |
| STATUS_NOT_SAME_OBJECT | STATUS_ERROR_PROCESS_NOT_IN_JOB |
STATUS_FATAL_MEMORY_EXHAUSTION
Meaning and context of STATUS_FATAL_MEMORY_EXHAUSTION
You should never try to allocate the total available memory to your runtime - this becomes more and more true the higher level your language is.
Even with very low level languages (which PHP is not, of course), you'll need not just the memory for the bytes that you're allocating (which will be going into heap space), but the memory for the instructions and call stack.
As you get into higher level and interpreted languages, that overhead only increases - the interpreter is going to need its own amount of memory, and there may not be any good or reliable way (whether across versions or even across configurations of the same version or executions within the same configuration) to determine exactly how much "padding" that environment/runtime will need.
In your case, you already suspect that you may come close - you should pick a "safe" amount of buffer space to leave for the runtime, for instance, if you know you're going to try to allocate more than 90% of the available memory to the runtime you shouldn't (and for a language like PHP, where you're very likely running in an server environment where other consumers are competing for the same resources, that threshold should likely be much lower).
In general, it's good practice to avoid consuming more memory than necessary, especially in interpreted and web-based environments. While memory trade-offs might be worth it to shorten execution time (particularly when loading more data in memory will save you time on lots of repeated calculations that would take longer to repeatedly allocate memory for and then deallocate memory for only to reallocate it), the case you're talking about here doesn't really make sense for that. This is the reason that you'd prefer a streaming model, where you only allocate as little memory as necessary to read the part of the file you can reasonably serve (as opposed to a situation where you have to repeatedly process different parts of that file, and then reprocess certain parts of them based on what you just processed - e.g. a routine that has to backtrack frequently in the file to know what to do next).
Native status interpretation
STATUS_FATAL_MEMORY_EXHAUSTION is 0xC00001AD, an NTSTATUS error value. AllStat describes it as “The process has terminated because it could not allocate additional memory.”. The first useful question is which native API, IRP, protocol operation, or subsystem in the kernel, native API, or subsystem that returned the status produced that status.
Debugging sequence
- Preserve this result before RtlNtStatusToDosError, HRESULT conversion, exception translation, or provider-specific remapping removes information.
- Log the operation associated with fatal / memory / exhaustion, the object or handle type, process and thread identity, and the state transition immediately before the return.
- When user mode receives this result, capture both the native status and the final Win32/COM error so the translation boundary remains visible.
Recovery considerations
A retry is appropriate only after the owner of this result has changed the state described by “The process has terminated because it could not allocate additional memory.”, or when its contract explicitly marks the status as transient. If the value reports corruption, invalid format, access policy, or a lifecycle mismatch, preserve evidence and correct that cause before repeating the request.
Official references
Looking for a different code? Search another status or error code.