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 -  CompileAllUnits.exe - CompileAllUnits - - Initialization - 18
Unexpected (fatal) exception is shown first:
Address : $004BA333 -  CompileAllUnits.exe - EExceptionHook - - GetExceptionStackInfoProcHandler - 658
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:
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 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:
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: