Runtime Error 203
Delphi Programming
Severity: ModerateWhat Does This Error Mean?
Runtime Error 203 means the program tried to allocate memory from the heap and the operating system could not fulfill the request. This typically means the process has consumed all available virtual memory — either from a memory leak, loading too much data at once, or hitting the 2 GB ceiling of a 32-bit process. Every object creation (TMyClass.Create), dynamic array resize, and GetMem call draws from the heap.
Affected Models
- Delphi 12 Athens
- Delphi 11 Alexandria
- Delphi 10.4 Sydney
- Delphi 10.3 Rio
- Delphi 10.2 Tokyo
Common Causes
- A memory leak — objects being created with Create() but never freed, slowly consuming all available memory
- Loading very large files or datasets entirely into RAM at once instead of processing them in chunks
- Running as a 32-bit application, which is limited to approximately 2 GB of virtual address space
- Creating many large in-memory structures (TStringList, TList, TMemoryStream) without releasing them
- Deep recursion that creates new objects at each level without freeing them before recursing further
How to Fix It
-
Enable FastMM in full debug mode. Add FastMM4 (or confirm FastMM5 for Delphi 10.4+) as the first unit in your DPR file, and enable FullDebugMode and LogMemoryLeakDetailToFile. Run your program and review the leak report on exit.
FastMM reports each leaked allocation with the object class name and the source file and line where it was created — making leaks easy to track down.
-
Review all object creation code. Every object created with a constructor must be freed in a matching finally block. The pattern is: Obj := TMyClass.Create; try ... finally Obj.Free; end;
Objects created in a constructor and assigned to form fields should be freed in the form's destructor.
-
Prefer FreeAndNil() over Free() when releasing objects. FreeAndNil sets the variable to nil after freeing, so accidental second calls are harmless (freeing nil is always safe in Delphi).
Replace MyObj.Free with FreeAndNil(MyObj) throughout your codebase as a good habit.
-
Process large files in chunks rather than loading everything into memory. Use TFileStream to read sections of the file at a time instead of loading the entire file into a TMemoryStream.
A file that is 200 MB on disk might expand to 400 MB or more in memory depending on the data structure used.
-
If the application is a 32-bit executable hitting the 2 GB virtual address space ceiling, recompile it as 64-bit. In Delphi IDE: Project → Options → Build Configurations → Platforms → Add Win64.
A 64-bit application can access essentially all installed system RAM, eliminating the 2 GB ceiling of 32-bit processes.
When to Call a Professional
Runtime Error 203 from a memory leak requires methodical debugging. Enable FastMM in full debug mode — it reports every unreleased allocation with file and line numbers at program exit. For 32-bit memory ceiling issues, the fix is to recompile the project as a 64-bit application.
Frequently Asked Questions
How do I tell if my Delphi program has a memory leak versus just using too much memory at once?
Watch your program's memory usage in Task Manager or Process Explorer over time. If memory grows slowly and continuously with use (especially after repeated operations like opening and closing a form), you have a leak. If memory spikes once on a specific operation and then stays elevated, that operation is loading too much data at once.
Does Delphi automatically free objects like Java or C# do?
No — Delphi uses manual memory management for most objects. You must call Free() when you are done with an object. However, strings, dynamic arrays, and interfaces are managed automatically using reference counting. This hybrid model gives you performance and control but requires discipline with object lifetimes.
What is the memory limit for a 32-bit Delphi application on 64-bit Windows?
By default, a 32-bit process on 64-bit Windows is limited to 2 GB of virtual address space. With the LARGEADDRESSAWARE flag set in the linker, this can extend to about 3–4 GB. But the correct long-term solution for memory-intensive applications is to compile as a 64-bit application, which can access all installed RAM.