Delphi EExternalException — What It Means & How to Fix It

What Does This Error Mean?

EExternalException is raised when the CPU or operating system signals an error that Delphi does not map to a more specific exception class. It usually carries a numeric exception code that identifies exactly what went wrong at the hardware or OS level. This is a low-level error that often indicates memory corruption, an illegal CPU instruction, or a problem in a third-party DLL.

Affected Models

All Delphi versions
RAD Studio
Applications using third-party DLLs or COM components

Common Causes

An exception code from an external DLL or COM component that Delphi does not recognise as a specific type
Memory corruption caused by a buffer overrun or writing past the end of an array, causing the CPU to fault
An illegal CPU instruction — usually caused by jumping to an invalid memory address and trying to execute it as code
Stack corruption caused by mismatched calling conventions when calling external DLL functions
An external hardware exception such as a privileged instruction or alignment fault in native code

How to Fix It

Note the ExceptionCode property of the EExternalException. This is a hex number (like $C0000005). Look it up — $C0000005 is access violation, $C000001D is illegal instruction, $C0000094 is divide by zero at the CPU level.

Microsoft documents the full list of NTSTATUS codes. Most external exceptions map to well-known Windows system error codes.
Check the calling convention of any external DLL functions you are using. If you declare a DLL function as stdcall but it is actually cdecl, the stack will be corrupted after the call, leading to unpredictable crashes.

In Delphi: procedure MyFunc; cdecl; external 'mylib.dll'; — use the correct calling convention keyword. Check the DLL's documentation.
Enable range checking and overflow checking in your project options during development. These catch array overruns and arithmetic overflow before they corrupt memory.

Project → Options → Compiler → Runtime error checking. Enable Range checking and Overflow checking. Remove them for the final release build if performance is critical.
If the exception comes from a COM component or third-party DLL, update it to the latest version. The vendor may have fixed the crash. Also verify you are initialising COM correctly with CoInitialize/CoInitializeEx before using COM objects.

COM errors in threads are common — each thread that uses COM must call CoInitialize separately.
Use a crash reporting tool (madExcept, EurekaLog, or FastMM4 in full debug mode) to get a detailed report including the call stack and memory state at the time of the crash. This is essential for diagnosing memory corruption bugs.

FastMM4 in FullDebugMode is particularly useful — it detects use-after-free errors and buffer overruns that would otherwise be very hard to find.

When to Call a Professional

EExternalException from a DLL or COM component often requires help from the component vendor. If it appears in your own code, it points to serious memory corruption that needs careful debugging. For production crashes with this error, a tool like madExcept or EurekaLog that captures a full memory dump will be essential.

Frequently Asked Questions

What does exception code $C0000005 mean?

$C0000005 is the Windows code for an access violation — reading from or writing to a memory address you do not have access to. In Delphi this is usually caught and re-raised as EAccessViolation. If you see it as EExternalException instead, it happened in code that does not go through Delphi's exception mapping — typically in a DLL or assembly code.

What is the difference between EExternalException and EAccessViolation?

EAccessViolation is Delphi's mapped version of the $C0000005 exception — Delphi recognises this specific code and raises a named, friendly exception. EExternalException is the catch-all for any CPU or OS exception that Delphi does not have a specific mapping for. Both originate from the same mechanism but EExternalException carries a raw numeric code instead of a named type.

How do I find which DLL is causing the external exception?

Run your application in the Delphi debugger with 'Stop on all exceptions' enabled. When the exception fires, look at the call stack window. The bottom of the stack shows the DLL module name where the exception originated. If the DLL has no debug symbols, the stack may show only memory addresses — use a tool like Process Explorer to map those addresses to DLL names.