5. When EurekaLog itself needs diagnosis

The application fails, but there is no report. Or adding EurekaLog makes a fast operation slow. Or the only thing on screen is an Internal Error dialog. These are different investigations. Do not begin by disabling every option: that can remove the observation as well as the defect.

Start with a reproducible operation and keep one known configuration as a baseline. Record the exact executable you ran, the account that ran it, and whether a debugger was attached. Change one relevant setting, rebuild when required, and repeat the same operation. A useful result explains which stage changed—not merely that one run appeared to work.

5.1 Choose the failing stage

A build-time ecc32 error is not an exception in your application. An IDE diagnostic log is not an application diagnostic log. A successful connection test does not prove a real report and its attachments fit the server's limits. Keep these distinctions throughout the investigation.

5.2 No report: walk from the binary to the handler

First prove which program is running

Open Tools → EurekaLog → PE Analyzer in the IDE, or EurekaLog → Tools → EurekaLog PE Analyzer from the Start menu. Select the EXE or DLL actually deployed and click Analyze. Check:

• The compilation date and path identify the build you intended to run.
• Is EurekaLog image: True and the reported code version match the intended EurekaLog build.
• Code and Data Compile IDs match exactly where the module contains both code and data.
• The Units detail includes the expected EurekaLog units; inspect the injected options too.

Packages and lightweight DLLs can intentionally contain data without a full EurekaLog runtime. Do not diagnose their data-only status as a failed ordinary EXE build; check the host/module design in chapters 16 and 2. A data format version of 8.0.00 is also documented as valid for EurekaLog 7.

If the result is wrong, stop changing runtime options. Inspect the active Debug/Release and target platform configuration, the selected EurekaLog project type, the .eof settings selected for that build, and the complete post-processing output. For example, Project1_Release.eof can override base Project1.eof settings in Release. Perform a full Build, not just Compile, after switching configurations. Reinspect the output and ensure the launcher/service/host loads that same file. Chapter 2 provides the complete build and deployment procedure; chapter 1 covers missing or misregistered IDE integration.

Dropping TEurekaLogEvents on a form does not install EurekaLog in the project. Enable it through Project → EurekaLog Options; the component only receives events from an installed runtime.

Then prove activation in the failing thread

Three conditions must hold: EurekaLog is installed in the process/module arrangement, globally active, and active in the thread that raises the exception. The following complete helper can be added to a diagnostic unit with SysUtils and EBase in its uses clause. Call it inside the thread being investigated, before the failing operation, and record the returned text in your existing diagnostic output:

function EurekaLogActivationSnapshot: string;
begin
  Result := Format('Installed=%s; Global=%s; CurrentThread=%s', [
    BoolToStr(IsEurekaLogInstalled, True),
    BoolToStr(IsEurekaLogActive, True),
    BoolToStr(IsEurekaLogActiveInThread(0), True)]);
end;

0 means the current thread. Testing only on the main thread says nothing about a worker. EBase can be used even when EurekaLog is not installed. The documented startup default enables the main thread, not every background thread. Chapter 21 explains thread integration and exception boundaries.

If global or thread state is false, search your setup and cleanup paths for SetEurekaLogState and SetEurekaLogStateInThread, and inspect the thread options. Restore the state your design requires at the correct scope: SetEurekaLogState(True) changes global state; SetEurekaLogStateInThread(0, True) changes the current thread. Neither installs missing runtime code. Do not blindly turn everything on inside an error handler and hide an unbalanced disable operation elsewhere.

Finally follow the exception's ownership

1. Did the debugger stop first? In a controlled test, continue so the application's handler can run, or launch the same binary without the debugger. An IDE exception notification is not the EurekaLog dialog. Keep debugger-dependent leak/hang options in mind when comparing runs.
2. Was the exception raised and then swallowed? A local try/except that substitutes a result owns that exception. Automatic unhandled-exception reporting is not a promise to report every handled exception. Put a breakpoint in that handler or enable debugger exception notifications to find it. If this exception should be reported, call EBase.HandleException(E) from its on E: Exception do handler, or redesign the boundary deliberately; do not simply turn all handled exceptions into user-visible failures.
3. Is this an expected exception or EAbort? Expected processing suppresses reports, sending, restart and technical details. HandleException does nothing for EAbort. Use a normal Exception, actually raised, for your controlled reporting test; constructing an exception object without raising it is not the same test.
4. Who owns Application.OnException? Inspect assignments, TApplicationEvents components, and AppEvnts/VCL.AppEvnts in the units list. Section 5.3 gives the integration repair.
5. Does the project profile fit the host? A VCL message-loop hook cannot stand in for an ISAPI, service, DLL or unsupported-framework boundary. Use the correct profile and explicit handler integration where needed (chapter 16 for DLL boundaries and chapter 2 for project setup), not a guessed GUI profile because it produces a dialog.
6. Is reporting deliberately suppressed? Check the effective report-saving/dialog/sending settings and your EurekaLog event handlers. Conditional configuration and handler decisions can change them at runtime. In a disposable reproduction, remove customization one piece at a time. A dialog, a saved report and a delivered report are three separate outcomes.

A plain exception raised by a temporary VCL button handler, without a surrounding application try/except, is a useful comparison with a failing worker or library operation. Use it only in a diagnostic build and remove the button afterwards. Success on that button narrows the problem to the other execution path; it does not prove all threads or modules are integrated.

5.3 The VCL handler that quietly replaced automatic reporting

EurekaLog 7 respects Application.OnException. If you assign it, EurekaLog assumes you intend to handle the exception yourself. This differs from the older 5.x/6.x behaviour described in the migration guidance. VCL events are not multicast: a later assignment wins.

TApplicationEvents installs its own Application.OnException routing, even if you did not assign its OnException event. In some Delphi versions, merely including VCL.AppEvnts can affect that routing even without a component instance. Therefore:

• If you do not need the component or handler, remove it and remove the unused AppEvnts or VCL.AppEvnts unit. Removing only the event body is not an equivalent experiment.
• If your application needs that handler, explicitly pass the exception to EurekaLog.

For a VCL form named TMainForm, add SysUtils and EBase to the form unit's appropriate uses clauses. Declare this method in the form class and implement it in that same unit:

procedure TMainForm.ApplicationException(Sender: TObject; E: Exception);
begin
  EBase.HandleException(E);
end;

Assign it either to Application.OnException during form initialization, or to the existing TApplicationEvents.OnException in the Object Inspector. Use the component's event when retaining the component; do not create two competing owners of Application.OnException. The method signature is the normal VCL exception-event signature. It borrows E: do not free the exception. Keep any custom work short and exception-safe. In particular, do not call Application.HandleException from its own OnException callback and recurse through the same routing.

HandleException(E) processes the already-raised exception; with EurekaLog installed and active, its configured processing includes reporting. Without EurekaLog installed, the routine has a simple error-display fallback. That fallback is why seeing a message is not proof that EurekaLog was installed: repeat the PE/activation checks above.

If a TApplicationEvents exception handler is unassigned, VCL may call Application.ShowException. EurekaLog can intercept that path through low-level hooks, which explains why changing hook options can expose a previously hidden integration gap. Prefer the explicit handler above when you own the boundary. Section 9.3 covers moving observation/customization into EurekaLog events instead of competing with the VCL handler.

5.4 Capture what EurekaLog is doing internally

Application logging answers “what did my code do?” Internal logging answers “which EurekaLog hooks, exception-processing steps, dialogs and send operations ran?” Both can use ELogging, but ordinary ELog calls or ELogOpen alone do not switch on internal tracing.

Build with the tracing code present

For the normal precompiled installation, enable Project → Options → Use Debug DCUs and make a full Build. This selects EurekaLog's debug library, not merely your application's Debug label. An explicit search path to the matching debug library is an alternative. The documented layout is <EurekaLog installation>\Lib\Win32\Debug\<IDE-name>\; choose the files for your actual platform and installed IDE, not an example's Studio number.

C++Builder projects may contain direct paths to EurekaLog objects/libraries. Inspect those paths: changing a search directory will not override an explicit link to a Release file. Select the matching Debug files and rebuild the entire project.

If you rebuild EurekaLog from source with the Enterprise edition, enable DEBUG_EL_CODE in the project conditional symbols or in Source\Common\ELDefines.inc before the full rebuild. Defining that symbol in an application that still links precompiled Release EurekaLog files does not insert missing diagnostic code.

Activate one logging mode

Run the prepared application from a command prompt. Replace the example executable with yours:

"C:\Apps\ReportProbe\ReportProbe.exe" --el_debug_unique

When launch arguments cannot be changed, the documented alternative is an empty marker file: ReportProbe.exe-el_debug, ReportProbe.exe-el_debug_standalone, or ReportProbe.exe-el_debug_unique. Contents do not matter. The name uses the host EXE including its extension, even for a DLL or package: for Host.exe loading Plugin.dll, use Host.exe-el_debug, not Plugin.dll-el_debug.

No marker search-directory contract is specified. Do not infer it from the log-output directories below. If a marker does not activate the mode in your host, use an explicit launch argument or the code-controlled method rather than assuming the absence of a log proves EurekaLog never ran.

Choose an explicit file when account or host paths are awkward

This complete diagnostic-only unit opens a permanent log and enables internal tracing. Include it in the project so it initializes early, before your application makes other ELogging calls. Create C:\ELDiagnostics beforehand and grant the application's execution account write access; change the literal to another existing, approved directory if necessary. Do not deploy this fixed-path diagnostic helper as production configuration.

unit InternalEurekaLogDiagnostics;

interface

implementation

uses
  ELogging;

initialization
  ELogOpen('C:\ELDiagnostics\runtime.csl');
  EL_Debug := True;
end.

EL_Debug := True is ignored for internal tracing if the linked EurekaLog files lack DEBUG_EL_CODE. Opening a permanent file must be the first logging action. This helper also cannot recover activity from before its own initialization; use startup switches when that earlier activity is the subject of the investigation.

Find, preserve and compare the output

After the process exits, first look alongside the application file. If that folder is not writable, the documented fallback is the running account's application-data area, commonly:

%APPDATA%\Neos Eureka S.r.l\EurekaLog\Bug Reports\your-executable\

The account matters more than the interactive user's Explorer window:

• A service running as Local System uses that account's profile, not yours. Documented examples include C:\Windows\System32\config\systemprofile\AppData and its SysWOW64 counterpart, depending on the process/OS arrangement.
• A low-integrity process can use C:\Users\<account>\AppData\LocalLow\Neos Eureka S.r.l\EurekaLog\Bug Reports\your-executable\.
• A further documented fallback is C:\Windows\Temp when the normal locations are unavailable; this is not a guarantee against all permission or disk failures.
• Runtime packages can put the output under the EurekaLogCore or custom package directory/name rather than the EXE name, including an application-data directory named for the .bpl.

If you cannot locate it, inspect the IDE's Event Log for the emitted output filename, or run Sysinternals DebugView while starting the application with the switch. DebugView can show the location, not capture the .csl diagnostic stream itself. An explicit ELogOpen path removes location ambiguity but still needs the correct account permissions and tracing-enabled build.

Capture one working run and one failing run, preserving both files before starting again; non-unique modes can overwrite the previous output. In CodeSite File Viewer, group entries by thread and, if useful, category. Compare the last corresponding operation and the first meaningful divergence. A hook never reached suggests a different problem from a hook reached followed by a failure while building or sending a report. The log narrows the investigation; it does not make every last entry the cause.

Turn internal tracing off after use. Remove the switch from launchers and IDE shortcuts, remove marker files, and remove the diagnostic-only unit or EL_Debug := True assignment. Restore the intended library/configuration and fully rebuild. Tracing can materially slow the application and alter timing; it is not a normal production or everyday-development mode. Preserve the evidence securely before removing temporary logs, which may contain paths, exception text and other private data.

5.5 “It became slow when I enabled EurekaLog”

Measure one named operation with the same input, bitness and configuration. Separate startup from steady-state work, and test both with and without a debugger when relevant. Do not benchmark an internally traced run against an untraced baseline and call the difference normal reporting cost.

The main discriminators in KnowHow 92 are:

Disabling the memory filter or hooks is a discriminating experiment, not a default solution. It changes coverage. In particular, collecting allocation call stacks for leak checking costs much more than merely storing per-block checking metadata. Turn off Catch memory leaks first when you do not need those stacks for the deployed workload; review Active only when running under debugger so that you know which runs actually collect them. If necessary, compare individual memory checks while keeping Enable extended memory manager installed. Only then consider removing the filter, with its lifetime-tracking and checking consequences understood (chapter 22).

For a bounded hot path, chapter 22 explains scoped leak-registration controls; chapter 12 covers thread activation. Do not paste a disable/enable pair around arbitrary work without restoring the correct prior state and accounting for exceptions and allocations that escape the scope.

Historical overhead estimates are not a ceiling. Workloads dominated by small allocations, exception traffic or short-lived threads behave very differently from arithmetic in a loop. A change that removes reports may make a benchmark faster without fixing the expensive design.

5.6 “Out of memory” is a diagnosis to make, not a setting to turn off

First preserve the complete numeric message, not just its first line. An OOM breakpoint in ELowLevel.DebugBreak, reached through EBase.PanicModeOn, indicates a fatal-condition diagnostic path; it does not establish that the breakpoint or EurekaLog caused the allocation failure.

KnowHow 98 distinguishes memory checks from leak checks. The filter can remain installed with leak checking off. Each allocation still carries checking metadata; leak-stack collection needs more. Its illustrative figures are 32 extra bytes without leak checking and 272 with it, describing the layouts in that article—not portable constants for every EurekaLog version, architecture or configuration. Tiny blocks amplify per-allocation overhead. Measure the actual two RTL totals instead of applying a universal percentage or comparing unmatched builds.

Read the fields together

Values can move between the failed request and report creation. Use their pattern rather than expecting every counter to reconcile byte-for-byte.

Choose the branch that fits the evidence

1. Process address space exhausted. A normal Win32 process near 2 GiB of occupied address space can fail even with tens of GiB of free system memory. Large-address-aware Win32 can have up to 4 GiB on 64-bit Windows; the historical 3 GiB case on 32-bit Windows also depends on the OS's configuration. KnowHow 98 cites 8 or 128 TiB for Win64, depending on Windows version: do not turn those historical values into a guarantee for every system. Reduce the working set of live data, load on demand, offload large data, reduce unnecessary concurrency, or consider Win64. If testing large-address-aware Win32, use the IDE's Enable large addresses option where available and test the application and dependencies for high-address compatibility. Also check that the diagnostic Reserve lower memory option is not needlessly reducing available space.
2. System commit exhausted. Address space may be plentiful while Total available (page file) is very low. Inspect paging-file policy, free disk space for growth, RAM and other processes. Restoring adequate paging/commit capacity addresses this branch; increasing address width alone does not create system memory.
3. EurekaLog overhead dominates. A large gap between the two RTL values is evidence that metadata for many small blocks matters. For example, roughly 356 MiB requested versus 1.93 GiB including overhead near a Win32 ceiling is a very different case from 1.76 versus 1.81 GiB. Reduce small allocations or collect fewer diagnostic features. Disable leak checking first if it is not needed; removing the filter is a final explicit trade-off, not the universal OOM fix.
4. Non-RTL occupancy dominates. If even the larger RTL total is much smaller than the virtual total, investigate DLLs, mappings, direct OS allocations, thread stacks and other non-RTL use. This gap directs the investigation outside RTL block totals; it does not identify a specific library, or prove that all occupancy is leaked memory.
5. Fragmentation. When address-space and system capacity remain adequate but the largest free region is too small, aggregate free bytes cannot satisfy the contiguous request. Check for leaks, then reduce allocation churn and separate long-lived from short-lived storage/pools. A long-lived service can fragment without leaking. Do not assume every object held at a checkpoint is a leak.
6. Allocation fails despite ample apparent capacity. Investigate corruption of the memory manager or another allocation failure. This is a strong discriminator, not proof from counters alone. The manager may request a much larger chunk than your small request: KnowHow 98 gives approximately 1.2 MiB as an example for the FastMM arrangement it discusses. Thus a 1 KiB request can fail with a 1.13 MiB free region. Verify the manager/version's actual needs before calling the numbers contradictory. With genuinely ample capacity, follow section 20.8 and enable appropriate developer-side memory diagnostics rather than hiding the failure.

These branches can coexist: a small extra diagnostic allocation can push a process already at its address-space limit over the edge. “It works without EurekaLog” proves sensitivity to the changed layout/overhead/timing, not that the application has no leak or corruption.

5.7 Internal Errors, debuggers and protected executables

When reporting another exception fails

An Internal Error is an unexpected fatal exception while EurekaLog is capturing or processing another exception. Recursively reporting each new failure would itself lead to a crash or hang, so normal collection, saving and sending may no longer be possible.

Preserve all the text. The unexpected fatal exception appears first; ActiveObj and ActiveAddr at the end identify the original exception. Section names the reporting stage where the failure was discovered. Last... fields reflect the last thread-exception state; they do not necessarily add another independent cause. An internal-error stack can stop at the reporting boundary because walking through the failing code again is unsafe.

Panic mode emits debug messages, can notify an attached debugger with a forced software breakpoint, disables EurekaLog in threads to avoid recursive failures, and installs a fallback memory-manager arrangement. It is not an invitation to continue ordinary work with a possibly corrupted process.

On an isolated reproduction:

1. Start from the first unexpected failure rather than running through several access violations.
2. Use full debug information and Use Debug DCUs, removing local {$D-} directives that would prevent useful symbols. Keep stopping on exceptions and non-user breakpoints enabled.
3. Temporarily remove your custom EurekaLog event-handler code to check whether it throws during report construction. Preserve the difference in behaviour.
4. Use the extended memory checks, or a separately configured compatible full-debug memory manager, to look for earlier corruption. Follow chapter 22 rather than combining conflicting managers.
5. Capture internal runtime logs as in section 5.4, including a working comparison if available.

The documented low-level bypasses are not repairs: EBase._AllowBypassInternalErrors := True together with EBase._InternalError := nil bypasses the normal internal-error handler; EExceptionHook._ForceEurekaLogForInternalErrors := True attempts normal reporting even for fatal exceptions. The latter may crash without producing the fallback report. Do not ship those settings as a way to conceal failures; restrict any such experiment to a disposable diagnostic run where losing the report or process is acceptable. Neither setting reveals an otherwise guaranteed cause.

Debugger/profiler communication

External debuggers and profilers need the debug format they understand. Preserve matching MAP/TDS or other required symbols (chapter 2). EurekaLog hooks can usually remain installed. If startup fails specifically under an external debugger/profiler, compare a launch with:

--el_DisableDebuggerPresent

This disables EurekaLog's debugger communication, such as thread naming and debug output; it does not remove EurekaLog from the program or diagnose memory corruption. Automatic AQTime detection is documented, while other tools may need the switch. Record the exact tool and version, and do not generalize a result to every debugger. Recheck outside that tool as well.

Antivirus and protectors

An antivirus alert, quarantine or denied file access is evidence to investigate; merely having an antivirus installed is not a root cause. Preserve the alert, path, timestamp and product/version. Check whether it acted during installation/build, binary launch, hook installation, or report-file creation. Do not use permanent broad exclusions as a diagnostic substitute. Reproduce under an approved isolated test policy; protectors and security tooling can conflict with hooks, but that general possibility does not prove a particular incident.

For a packer/protector, keep both the working unprotected build and the failing protected build:

1. Inject EurekaLog data before packing/protecting. Run the protector from EurekaLog's successful post-build event, not the IDE's earlier post-build event. Chapter 2 gives build ordering.
2. Use internal tracing if the protected program cannot run under a debugger.
3. Change one relevant protector or EurekaLog option at a time. Integrity checks, low-level/code hooks, cached speed optimizations and exception interception are different conflicts. If hooks are removed, supply a deliberate exception boundary such as section 5.3; the disappearance of an error dialog is not success if reporting has simply been disconnected.
4. Prefer preserving the memory filter where compatible: it tracks exception-object lifetime without requiring the same code hooks. Turning off all memory features can remove that fallback.
5. Where the protector permits it, compare preserving resources, avoiding VM transformation and disabling its hook/debugger detection or OS-function virtualization. These are test changes, not a universal recommended production protection policy.

There is a hard limit: if virtualization or dynamic code changes break the relationship between machine code and debug information, EurekaLog cannot reconstruct meaningful original source lines merely by enabling another provider. Restore a symbol-compatible transformation for code you need to diagnose, or accept that coverage limit. A successful launch is not proof that protected code still yields correct stacks.

5.8 Diagnose the IDE and post-processor in their own process

For a missing menu or registration problem, follow chapter 1 first; runtime options in your EXE cannot repair the IDE expert. For compiler/linker prerequisites, platform/IDE-specific ecc32, post-processing order and stale outputs, follow chapter 2. Once those checks isolate an internal tool failure, collect the tool's own log:

• IDE: close it, add --el_debug to a diagnostic IDE shortcut, launch, reproduce the operation, then close it normally. Look for el_debug.csl in %APPDATA%\Neos Eureka S.r.l\EurekaLog\Bug Reports\bds.exe\, or in the IDE's bin folder if writable. Older IDE executables use their own names. Remove the switch afterwards.
• Manual ecc32/ecc32speed: add --el_debug to the existing command while preserving all original build arguments. Keep the exact invocation and full output.
• IDE-driven post-processing: enable EurekaLog's Debug output and Troubleshooting options, rebuild, and copy the .csl filename printed immediately after the ecc32 header. The documented default is %APPDATA%\Neos Eureka S.r.l\EurekaLog\Bug Reports\ecc32.exe\; writable/development installations may instead write beneath <EurekaLog installation>\Packages\<IDE-name>\.

The supplied EurekaLog tools/IDE expert already include diagnostic code; the application-specific Debug-DCU preparation is not required for their own tracing. An IDE log records IDE activity, not your application's run. Likewise, an ecc32 log diagnoses post-processing rather than a crash in the resulting executable. Disable these diagnostic settings after capturing the problem.

5.9 Leave the next investigator a reproducible question

If the documented checks do not identify a cause, prepare evidence before contacting support or handing the issue to another developer:

• A small source reproduction and exact steps, with expected versus observed results. Never make the reader guess which button, account, thread or shutdown stage matters.
• Exact EurekaLog version including update/hotfix/beta, edition, IDE/compiler version and update, Win32/Win64 target, project type, Debug/Release configuration and effective .eof settings.
• Windows version/build, debugger or profiler, security product/protector version, execution account and integrity/elevation context, launch command, and writable-output location.
• The actual EXE/DLL/BPL layout: host, full versus lightweight modules, runtime packages/shared memory manager, and whether each participating module was rebuilt with the same intended setup.
• Complete compiler/linker/ecc32 output and PE Analyzer findings for build problems. Preserve the matching executable, symbols and source revision privately so a later rebuild does not destroy the evidence.
• Original reports/internal-error text, full OOM numeric fields where applicable, working/failing .csl logs, and the exact single-variable comparisons already attempted.
• Reproduction frequency and observations that remain uncertain. Distinguish “the configuration changed and the symptom disappeared” from “this statement fixed the reproduced cause.”

Review archives before sharing: reports, paths, command lines, screenshots, logs and attachments can contain credentials or personal/business data. Provide only necessary material through the approved support channel. Do not publish a production binary or customer data merely because it would make reproduction easier.

Success is not always an immediate fix. Sometimes it is a precise remaining question: the correct binary is active in the correct thread, the local handler forwards the raised exception, and a particular protected build fails at a particular reporting stage. That is a much stronger starting point than “EurekaLog does not work”—and it does not pretend the evidence proves more than it does.