Delphi Runtime Error 204 — What It Means & How to Fix It

What Does This Error Mean?

Runtime Error 204 means the program tried to free or operate on a pointer that the memory manager does not recognize as valid. The most common cause is freeing the same object twice (called a double-free), or calling Free on a pointer that was never properly allocated. This error indicates a memory management bug and must be fixed — it can silently corrupt the heap if it goes undetected.

Affected Models

Delphi 12 Athens
Delphi 11 Alexandria
Delphi 10.4 Sydney
Delphi 10.3 Rio
Delphi 10.2 Tokyo

Common Causes

Freeing the same object twice — calling Free or Dispose on a pointer that was already freed
Calling Free on a local variable that was not heap-allocated (stack-allocated records must not be freed)
Passing a pointer to FreeMem that was not originally allocated with GetMem or New
Memory corruption from an earlier bug overwriting heap metadata, causing a later free to appear invalid
Mixing memory managers across DLL boundaries — freeing in one DLL memory that was allocated in another

How to Fix It

Enable FastMM in full debug mode (add it as the first unit in your DPR and set FullDebugMode). When Runtime Error 204 occurs, FastMM reports the exact pointer address, where the object was created, and where it was previously freed.

FastMM is the default memory manager in Delphi 2006 and later. In Delphi 10.4+ you can use FastMM5 for even better diagnostics.
Replace all bare Free() calls with FreeAndNil(). FreeAndNil sets the variable to nil after freeing, so if the same variable is freed a second time, Delphi safely ignores it (freeing nil always does nothing).

This single change eliminates most double-free bugs. Make FreeAndNil your default object-release pattern.
Never call Free on a stack-allocated variable. Local record variables and value types live on the stack — calling Free on them will trigger Runtime Error 204. Only objects created with a class constructor are heap-allocated and must be freed.

Correct: MyObj := TMyClass.Create; ... FreeAndNil(MyObj); Wrong: var R: TMyRecord; ... R.Free; (records are not objects and have no Free method — this would not even compile, but pointer misuse can cause the same problem).
If your project uses DLLs, ensure all DLLs share the same memory manager. Include ShareMem as the very first unit in the DPR of both your EXE and every DLL. Without this, memory allocated in one module cannot safely be freed in another.

Alternatively, use a custom shared memory manager like SimpleShareMem (available in Delphi 10.2+) which does not require the BORLNDMM.DLL runtime dependency.
Audit all paired GetMem/FreeMem and New/Dispose calls. Each allocation must have exactly one matching deallocation using the correct pair. Do not mix: never free with FreeMem something that was allocated with New, or vice versa.

Correct pairs: GetMem → FreeMem, New → Dispose, AllocMem → FreeMem, TObject.Create → TObject.Free.

When to Call a Professional

Runtime Error 204 points to a memory management defect that needs proper debugging. Enable FastMM in full debug mode — it will report exactly which pointer was invalid and often shows where it was first freed. This error should not be suppressed; fix the root cause.

Frequently Asked Questions

What is a double-free and why is it dangerous?

A double-free means you freed the same memory block twice. The first free returns the memory to the heap manager. The second free corrupts the heap's internal bookkeeping because it tries to return memory the manager no longer owns. This corruption can cause Runtime Error 204 immediately, or cause mysterious crashes in completely unrelated code much later.

Why does FreeAndNil prevent double-free bugs?

FreeAndNil calls Free and then sets the variable to nil. In Delphi, calling Free on a nil object reference is explicitly safe and does nothing. So a second accidental FreeAndNil call sees nil and silently exits. Make FreeAndNil your default — it costs nothing at runtime and prevents an entire class of bugs.

How can a bug in one place cause Runtime Error 204 in a completely different place?

The heap is a shared data structure maintained by the memory manager. A buffer overrun or other memory corruption earlier in the program can silently overwrite the heap's internal metadata. When a later, completely correct call to Free tries to use that corrupted metadata, the memory manager detects the inconsistency and raises Runtime Error 204. This is why enabling FastMM debug mode is essential — it helps trace the corruption back to its true origin.