Runtime Error 216
Delphi Programming
Severity: CriticalWhat Does This Error Mean?
Runtime Error 216 is a General Protection Fault (GPF) — the program tried to read from or write to a memory address it is not allowed to access, and the operating system forcibly terminated it. The most common cause is a nil or dangling pointer: code that tries to use an object reference that was never created, has been freed, or points to corrupted memory. This is one of the most serious runtime errors — it means your code has a memory access bug.
Affected Models
- Delphi 12 Athens
- Delphi 11 Alexandria
- Delphi 10.4 Sydney
- Delphi 10.3 Rio
- Delphi 10.2 Tokyo
Common Causes
- Using a nil object reference — calling a method or accessing a field on an object that was never created
- Use-after-free: using an object after it has been freed, when the pointer still holds the old address
- Buffer overrun: writing past the end of an array or string, corrupting adjacent memory
- Dereferencing an uninitialized or corrupt pointer variable
- Accessing freed heap memory through a dangling pointer that was not set to nil after Free
How to Fix It
-
Run the program inside the Delphi debugger. When Runtime Error 216 fires, the debugger will pause at the faulting instruction. Examine the Call Stack window and hover over the pointer or object variable involved to see its value — nil means it was never created.
In the IDE: Run → Run (F9) with your project open. The debugger automatically breaks on access violations and shows you the exact line.
-
Check for nil object references before using them. Use the Assigned() function: if Assigned(MyObj) then MyObj.DoSomething; Never call methods or access fields on an object without first verifying it exists.
Assigned(X) returns True only if X is not nil. It is the standard Delphi guard against nil pointer use.
-
Use FreeAndNil() to release objects instead of bare Free(). FreeAndNil sets the variable to nil immediately after freeing, so any subsequent accidental use will trigger a detectable nil check rather than a silent GPF through a dangling pointer.
A dangling pointer (non-nil but pointing to freed memory) is more dangerous than nil because nil often produces a clear error while a dangling pointer causes random corruption.
-
Enable FastMM in debug mode and check for use-after-free bugs. FastMM fills freed memory with recognizable byte patterns. If your program reads that pattern instead of valid data, FastMM's report will point to the original allocation and free locations.
FastMM debug fill pattern for freed blocks is 0x80808080. If you see values like 2155905152 ($80808080) in your data, a freed block is being read.
-
Review array and string operations for bounds overruns. Writing past the end of a static or dynamic array corrupts adjacent memory and can cause a GPF on a later — completely unrelated — memory access. Enable range checking ({$R+}) to catch bounds overruns.
A bounds overrun corrupting heap metadata is a classic cause of Runtime Error 216 that appears far from the actual bug.
When to Call a Professional
Runtime Error 216 requires debugging with the full Delphi debugger enabled. Enable FastMM in debug mode — it detects use-after-free by filling freed memory with a recognizable pattern. If the crash is in a DLL or third-party library, enable the debugger's 'Load debug DCUs' option for better stack traces.
Frequently Asked Questions
What is the difference between Runtime Error 216 and Runtime Error 210?
Runtime Error 210 is caught by Delphi's own runtime before the memory access — Delphi detects that a virtual method dispatch is about to occur on a nil object and raises a specific error. Runtime Error 216 is raised by the operating system after the CPU already attempted an illegal memory access and the OS interrupted it. Runtime Error 210 is more descriptive; Runtime Error 216 is a lower-level, harder-to-diagnose OS-level fault.
Why does Runtime Error 216 sometimes crash in a location far from the actual bug?
Memory corruption works like a slow poison. A buffer overrun or double-free corrupts heap metadata silently at one point in the program. Much later, when a legitimate memory operation tries to use that corrupted metadata, the OS detects an invalid access and raises the GPF. The crash location looks innocent because it is — the real bug happened earlier. This is why FastMM debug mode is invaluable: it catches corruption at the source.
Can Runtime Error 216 happen in third-party components or DLLs?
Yes — the GPF can occur inside any code your application executes, including third-party VCL components, Indy networking, database drivers, or Windows DLLs. Enable the Delphi debugger's 'Load debug DCUs' option (Project → Options → Debugger) to get better stack traces through system code. If the crash is in a third-party binary with no debug info, check whether there is an updated version or known bug report.