This article is for application developers, which use EurekaLog exception tracer tool. If you are not a developer of the application - please, contact developers of application and let them know about this issue.

Sometimes your application may show "EurekaLog crash report", also known as "Internal Error bug report". This article explains such reports.

A typical internal error report in EurekaLog

What are internal errors

Internal error is (fatal) exception raised during capturing information about another exception (non-fatal). This exception is unexpected and it indicates wrong state of your application. When such exception is encountered - EurekaLog stops application and shows internal error report. It's not possible to continue normal work after encountering fatal exception. Internal error report is generated to avoid application's hang or crash (indeed: exception -> capture information about exception -> get another exception -> capture information about exception -> get yet another exception -> etc. until hang or crash). It's not possible to perform normal exception processing (collect call stack, save bug report file, send bug report to developers) for the same reasons.

How to read internal error report

Original (non-fatal) exception is shown last (as ActiveXYZ):

ActiveObj : (Exception) Error Message

ActiveAddr : $004C197E - [00400000] CompileAllUnits.exe - CompileAllUnits - - Initialization - 18[78]

Unexpected (fatal) exception is shown first:

Address : $004BA333 - [00400000] CompileAllUnits.exe - EExceptionHook - - GetExceptionStackInfoProcHandler - 658[263]

Module : CompileAllUnits.exe

Exception : EAccessViolation

Message : Access violation at address 004BA333 in module 'CompileAllUnits.exe'. Write of address 00000000

Location where fatal exception was discovered is indicated by "Section":

Section : GetExceptionStackInfoHook

Middle part of internal error report (LastXYZ) shows value of ExceptionManager.LastThreadException. Usually this part doesn't hold any additional valuable information.

Unfortunately, it's not possible to create proper call stack for internal error report: because collecting call stack means calling the crashed code again (so it's highly likely that it will cause another crash). That's why call stack show only location, which has detected the problem (up to GetExceptionStackInfoHook in the above example), not the location which has actually encountered a problem (there is no info in call stack about routines called from GetExceptionStackInfoHook).

What causes internal errors

Internal errors can be caused either by bugs in EurekaLog's code or by bugs in your code. Usually, fatal exception is access violation exception occurred when EurekaLog collects information about ordinal exception.

Internal errors can be caused by the following reasons:

•

Allowing application to continue to work after it encounters its first unhandled exception. Unknown exception (especially access violation) puts your application into unknown state. This state may be unstable, so any further work may cause crashes. For example, you may get access violation exception due to memory corruption bug in your code. And you continue to run your application after handling this exception. However, memory state is still corrupted. Thus, when next exception occurs, and EurekaLog tries to work with it - EurekaLog may trigger access violation exception due to corrupted memory.

•	Bugs in EurekaLog code.

•	Bugs in your code.

What is panic mode

When EurekaLog encounters unexpected exception during processing of another exception - it puts itself into so-called "panic mode". This is "safe-fallback" mode designed to continue work to complete creation of internal error report.

Panic mode:

•	Outputs debug messages to indicate failure condition;

•	Notifies attached debugger (if present) about failure condition by triggering forced software breakpoint. If you're running application under debugger - you can stop on this breakpoint and investigate the crash;

•	Disables EurekaLog in all threads. This is done to avoid calling crashed code for any possible further exceptions;

•	Installs memory manager replacement. This is done to allow allocating and disposing memory blocks when internal error was caused by corrupted memory manager state.

Panic mode is used for all fatal exceptions, not just for internal errors. For example, when EurekaLog discovers corruption of memory block with its debugging memory manager - it puts itself into panic mode to allow to continue work despite memory corruption.

How to solve internal errors

Unfortunately, it's not possible to get exact reason for internal error from internal error report. That's because internal error report is created when fatal exception is discovered, not when it occurs. So, report doesn't contain information about exact location of the problem, only indication to generic code's section. Internal error report allows you to know that something is wrong in your application, but you need to do additional work to figure out reason.

If you have reproducible test case to invoke internal error - please, contact EurekaLog support to get assist with resolving your issue.

Otherwise, you may try the following:

•	Configure your project for maximum debugging. Most notably (but not suffice): enable "Use Debug DCUs" option and remove any {$D-} directives in your code;

•	Try to run your application under debugger. Do not disable stopping on exceptions and non-user breakpoints. You can try to investigate reason or capture screenshots to submit them later to EurekaLog's support;

•	Try to enable "Enable extended memory manager" option;

•	Try to disable "Enable extended memory manager" option and use 3rd party debugging memory manager (such as FastMM in full debug mode or SafeMM);

•	Try to comment your customization code. Exceptions raised by your event handlers sometimes may lead to internal errors;

•

Try to set _AllowBypassInternalErrors global variable (EBase unit) to True and set _InternalError global variable to nil (do this in any place before internal error occurs). See if this can give you more information in internal error report. These options will disable creation of internal error reports and will allow you to continue your application's work on your own risk;

•

Try to set _ForceEurekaLogForInternalErrors global variable (EExceptionHook unit) to True (do this in any place before internal error occurs). See if this can give you more information in internal error report. This option will enable EurekaLog for fatal exceptions (as mentioned above: EurekaLog is disabled by default for fatal exceptions). Of course, internal error reports must be enabled;

•	Try to use internal debug mode.

How to change default behavior of internal errors handler

EurekaLog allows you to customize default behavior for internal errors via low-level customizations. You can use the following low-level possibilities:

•	EBase._InternalError - allows you to install your own internal error handler. You can use this to show another message, to create another bug report, etc. You can also to reset this handler to nil.

•	EBase._AllowBypassInternalErrors - allows you to ignore internal errors. This option has no effect if _InternalError handler is assigned.

•	EExceptionHook._ForceEurekaLogForInternalErrors - allows you to use EurekaLog for internal errors. This possibly may collect more information about fatal exception, but also may cause application's crash without creating internal error report.