2. Builds you can trust

A compiler's success message is not the last step of a EurekaLog build. The runtime units must be linked into the right module, the compiler and linker must preserve the information needed to describe its code, and EurekaLog must post-process that exact output with the intended settings. A release is useful for diagnosis only if the files you keep and deploy belong to that same build.

Chapter 1 establishes a small working application. This chapter turns that result into a repeatable build, including C++Builder, command-line compilation, deployment, and upgrades. Chapter 25 describes settings storage and runtime access in more detail; chapters 11, 16, and 24 cover symbol providers and multi-module integration.

2.1 Identify the toolchain before choosing a path

Keep a build record containing the EurekaLog version and edition, IDE product and maintenance update, personality/compiler, target platform, build configuration, selected .eof, and output filename. Separate generated units by configuration and platform. An old DCU or OBJ found earlier in a search path can silently defeat a new compiler setting; an old executable found by a post-processor can make a successful build misleading.

The important installed trees are:

<EurekaLog>\Packages\<IDEName>\
<EurekaLog>\Lib\<Platform>\Release\<IDEName>\
<EurekaLog>\Lib\<Platform>\Debug\<IDEName>\
<EurekaLog>\Lib\Common\
<EurekaLog>\Source\

The Lib Debug/Release distinction is the precompiled library set, not a guarantee that the application configuration with the same name selects it. In Delphi, Use Debug DCUs and the registered Debug DCU paths affect that selection. Source is normally a browsing path; Professional and Trial source files do not contain the implementation required for source recompilation.

Use ecc32.exe or ecc32speed.exe from the Packages directory for the IDE that produced the program. The following mapping makes the command examples concrete without requiring a separate lookup:

These are EurekaLog's identifiers, not a sequence you should calculate yourself. For example, Florence is Studio37, not Studio30. The same RAD Studio identifier applies to its Delphi and C++ personalities. Platform/compiler support is a separate question; this table does not promise equivalent features across all targets.

If you run the executable from EurekaLog's Bin directory, or copy it to another directory, its location no longer identifies the IDE. Supply the appropriate integer explicitly, for example --el_ide=29 for Athens. This affects compiler selection and interpretation of symbols, not merely the banner. Prefer a full, quoted path over a bare ecc32 found through an ambiguous PATH.

Do not copy third-party executables into the IDE's own bin directory as the normal solution. Modern IDEs can reject that directory's contents during their own product validation. A correctly selected EurekaLog Packages path avoids both that problem and an accidental toolchain choice.

2.2 Give every configuration enough information

Check these options on each configuration/platform you intend to build, including Release. Put common prerequisites in Base where appropriate, then inspect child overrides. Exact option labels vary by IDE.

For manually controlled Delphi builds, the documented minimum switches are -$D+, -GD, a -U path to the correct EurekaLog compiled units, and -DEUREKALOG;EUREKALOG_VER7. These are a minimum, not a replacement for the project's normal search paths, defines, resources, and target settings.

Keep compiler Local symbols and Reference info enabled where available. Enable Stack frames in Delphi or Standard stack frames in classic C++Builder. In Delphi, Use Debug DCUs adds the RTL/VCL line information that ordinary precompiled library units may lack; this can be especially useful in a field report, even though the configuration is named Release. Keeping debug information does not require turning the whole product into a development build.

Range checking and overflow checking are separate choices: they insert runtime checks and may change performance and where bugs become exceptions. Use them deliberately, rather than confusing them with symbol generation. Remote-debugger information is needed only for the corresponding debugger workflow. A separate TDS file can avoid embedding the debugger's own large information block in the Delphi executable.

Inspect source and include files for local directives such as {$D-}. The project checkbox cannot recover information a unit did not emit. Similarly, linking an old third-party DCU without symbols cannot create source lines just because today's project enables a Detailed MAP.

After changing these settings, changing target/configuration, or changing the EurekaLog version:

1. Clean the project's generated MAP/TDS and compiled-unit/object outputs (.dcu, .obj, .a, and other outputs used by that toolchain), not unrelated libraries or source files.
2. Rebuild the complete project and any owned dependencies whose debug settings changed. Use Build/Build All, not Compile/Make.
3. Confirm that the linker produced fresh symbol inputs and that EurekaLog processed the new output. If post-processing strips those files, inspect its output or retain the inputs before that step.

Which .eof wins?

For Project1.dpr, base settings are stored in Project1.eof. With a known Debug configuration, Project1_Debug.eof beside the project takes precedence if it exists; otherwise the base file is used. Release works the same way. These files are alternatives, not an inheritance chain: a configuration file does not merge its missing options with Project1.eof.

Create configuration files with the options dialog's Export button. Save the base settings first with OK; then customize and export each complete configuration beside the project. Close with Cancel after the configuration exports if you do not want those temporary changes written back into the base file. Keep these inputs under version control.

--el_buildconfig=Debug requests configuration-based selection. An explicit --el_config=SomeFile.eof overrides that choice; --el_buildconfig is then ignored for settings selection. An external-settings reference configured in the base options is another input to inspect (chapter 25).

Platform-specific names are not automatically implied by the Debug/Release convention. You can explicitly export Project1_Win64_Release.eof and pass it with --el_config, or use Project1_$(Platform)_$(Config).eof in build events. Ensure every combination used by the build actually has a file. Selecting an .eof does not itself select the compiler's target platform.

2.3 C++Builder needs source-level integration too

Start from an enabled project with the correct application profile. For memory/resource features, initialization order is part of correctness; a checkbox alone does not put the C++ support module first.

1. In EurekaLog options, enable the memory and/or resource features you intend to use (chapters 12, 19, and 17 describe their cost and behavior).
2. Prefer C++ Linker > Dynamic RTL = False for the straightforward integration. If Dynamic RTL is enabled, the project must define _RTLDLL; when Dynamic RTL is disabled, it must not define _RTLDLL.
3. Prefer not linking with runtime packages for the first integration. If packages are required, remove EurekaLogCore from the application's runtime-package list unless your architecture intentionally centralizes EurekaLog there. Chapter 16 describes those special arrangements. The project configuration guidance also recommends disabling Link with the Delphi RTL where applicable.
4. Add EMemLeaksBCB.cpp from EurekaLog's Lib\Common directory to the project. A project-local copy is optional; if you make one, treat it as a dependency that must be refreshed during upgrades.
5. In Project > Options > Build order, move EMemLeaksBCB.cpp to the first position.
6. In the main project .cpp (Project > View source), add USEOBJ("EMemLeaksBCB.cpp"); before every USEFORM directive.
7. Include EMemLeaksBCB.hpp and call EurekaLogInstallCpp() at the start of the application's entry point, before its normal VCL initialization. Retain the generated application's existing exception handling.

The relevant placements in a conventional VCL project are:

USEOBJ("EMemLeaksBCB.cpp");

#include <EMemLeaksBCB.hpp>
#include <vcl.h>
#pragma hdrstop
#include <tchar.h>

USEFORM("Unit1.cpp", Form1);

Then make this the first statement inside that project's existing _tWinMain function:

EurekaLogInstallCpp();

These are insertion instructions for the IDE-generated project, not a replacement entry point: leave its Application->Initialize(), form creation, Application->Run(), and generated catch handlers in place. Use the C++ support header EMemLeaksBCB.hpp for this hook, not EMemLeaks.hpp.

Finally, apply the compiler/linker requirements in section 2.2, disable Map with mangled names, and make a full project build. CodeGuard is an optional diagnostic tool, not a prerequisite; some of its options conflict with EurekaLog, so do not enable every detector at once when establishing a baseline.

Classic, LLVM, and line-number limits

A C++ MAP contains symbol names but no line numbers. On classic Win32, EurekaLog supplements it with TD32/TDS information. Turning on a Detailed MAP without TD32 cannot supply the missing lines.

The Win32 TD32 recommendation applies to classic Win32, not LLVM/Clang Win32 and Win64: LLVM emits DWARF instead, which the documented EurekaLog provider does not read. Those builds therefore do not gain source lines merely by enabling the same checkboxes. LLVM also lacks the exception context needed by frame-based tracing; select a RAW stack method for that compiler (chapter 11). Prefer the classic Win32 compiler when that is an available and acceptable target choice.

Do not confuse ordinary C++ Win64 with Windows 64-bit (Modern) introduced in RAD Studio 12.1. The compiler guidance in Does EurekaLog support CLang/LLVM/64-bit? explicitly lists Modern as not supported yet. The presence of Win64x output directories does not establish that this compiler restriction or DWARF limitation was removed. Require an explicit supported-build statement before relying on a newer support boundary.

There is also a documented Release-profile defect checked with EurekaLog 7.2.2 and C++Builder XE2–XE8: reporting can fail in Release even when debug options appear correct. The documented workaround is the Debug profile. Treat this as a historical, bounded compiler issue, not a blanket rule that every present-day C++ Release build is broken. Verify the actual configuration you will deploy, rather than silently shipping a different one.

2.4 Choose one owner for preparation and post-processing

There are three useful build arrangements:

• Let the IDE expert configure and post-process an ordinary IDE build.
• Let MSBuild pre/post-build events do it, so IDE and automation use the same commands.
• Let an external script prepare, compile, and post-process explicitly.

Do not accidentally run two competing post-processing paths. When migrating from the expert, first retain the working project setup from chapter 1, export the external configuration, and only then disable the expert's automatic involvement.

For complete manual ownership, add DoNotTouch=1 under EurekaLog options > Advanced > Custom/Manual in the project's base settings, after exporting the configuration the build will use. Do not add it to that exported configuration. You now own the compiler options and defines. DoNotTouchCompilation=1 is the narrower choice when only automatic post-processing should be suppressed; the other DoNotTouch... controls are explained in chapter 25. These settings are unrelated to the DoNotTouchEXE debugger workaround in section 2.7.

Delphi 2007+ MSBuild events

Put the following in the IDE's Project > Options > Build events, not EurekaLog's own build-events page. Each displayed command is one line. The example uses a conventional installation and Studio16 (XE2); replace both the root and IDE directory with those installed on the build machine.

Pre-build:

"C:\Program Files (x86)\Neos Eureka S.r.l\EurekaLog 7\Packages\Studio16\ecc32.exe" "--el_prepare=$(PROJECTPATH)" "--el_buildconfig=$(Config)"

Post-build, after successful compilation:

"C:\Program Files (x86)\Neos Eureka S.r.l\EurekaLog 7\Packages\Studio16\ecc32.exe" "--el_alter_exe=$(PROJECTPATH);$(OUTPUTPATH)" "--el_buildconfig=$(Config)"

The pre-build step adjusts the Delphi .dpr unit list to the selected features. The post-build step injects options and debug data into an already compiled module; it cannot repair a missing linked unit by recompiling it. Never put --el_prepare and --el_alter_exe in the same invocation.

$(PROJECTPATH) supplies the project configuration filename; $(OUTPUTPATH) supplies the actual linked target in this workflow. Preserve the semicolon and the enclosing quotes: guessing the output from just the project basename can select the wrong configuration's executable. Inspect the expanded command in the build log, especially if your build tool uses a similarly named macro for a directory rather than a complete filename.

If the IDE does not expose $(Config), use the explicit configuration name or omit that switch and deliberately use the base settings. To choose an exported platform-specific file, use the same argument in both events, for example:

"--el_config=Project1_$(Platform)_$(Config).eof"

Check that the build's working directory resolves that relative file as intended. Use an absolute filename if it does not.

For C++Builder, perform the source integration in section 2.3 and use this post-build command:

"C:\Program Files (x86)\Neos Eureka S.r.l\EurekaLog 7\Packages\Studio16\ecc32.exe" "--el_alter_exe=$(PROJECTPATH);$(OUTPUTPATH)" "--el_buildconfig=$(Config)" --el_mode=Builder

The Delphi preparation command is not a substitute for the C++ USEOBJ, header, build-order, and startup changes.

Put events in Base if they should apply to all configurations and ensure no child overrides remove them. They execute only when the builder actually honors those MSBuild events. Calling dcc32.exe directly does not execute them. A third-party builder can also bypass them. In that case use an explicit post-processing stage, not an assumption that the .dproj contains the answer.

2.5 Reproduce the build outside the IDE

Install or provision the same compiler and EurekaLog files under the build account. A headless compiler is still a compiler: force-installing EurekaLog files does not install Delphi or C++Builder. Keep the compiler environment, unit paths, settings files, and generated output directories explicit. Protect activation material and sender credentials from logs and repository commits.

For an MSBuild project with the events in section 2.4, initialize the compiler environment and invoke its Build target. The following is the documented XE2-style command sequence, with paths and names to adapt to your installation:

call "C:\Program Files (x86)\Embarcadero\RAD Studio\9.0\bin\rsvars.bat"
msbuild Project1.dproj /t:Build /p:config=Debug;platform=Win32

A separate prepare/build/post-process script

Use this alternative when the project has no active EurekaLog pre/post-build events and the IDE expert is not supplying those stages. Save it as a batch file, run it from the project directory, and substitute your installed paths. It assumes a saved Project1.dproj, a complete exported Project1_Debug.eof, correct compiler prerequisites, and a project whose output is configured to Debug\Win32\Project1.exe.

@echo off
setlocal
set "EL=C:\Program Files (x86)\Neos Eureka S.r.l\EurekaLog 7\Packages\Studio16\ecc32.exe"

"%EL%" "--el_prepare=Project1.dproj" "--el_config=Project1_Debug.eof"
if errorlevel 1 exit /b 1

call "C:\Program Files (x86)\Embarcadero\RAD Studio\9.0\bin\rsvars.bat"
if errorlevel 1 exit /b 1

msbuild Project1.dproj /t:Build /p:config=Debug;platform=Win32
if errorlevel 1 exit /b 1

"%EL%" "--el_alter_exe=Project1.dproj;.\Debug\Win32\Project1.exe" "--el_config=Project1_Debug.eof"
if errorlevel 1 exit /b 1
endlocal

The failure checks prevent a compiler failure from being followed by successful processing of a stale executable. Do not hide a missing post-processor behind IF EXIST and let the pipeline report success anyway. The output filename here is an assumption declared for this example, not a universal Delphi directory convention.

Use .dproj for Delphi 2007+, .bdsproj for Delphi 2005/2006, or .dpr for the older project format. For C++Builder 2007+ use .cbproj and --el_mode=Builder in the post-processing invocation; use .bdsproj for its 2006 format. Post-processing requires both the compiled module and its matching symbol inputs. Passing an EXE filename does not add runtime code that was never linked.

When using --el_alter_exe, specify the explicit target after the semicolon. The documented --el_platform switch is ignored with --el_alter_exe; it is not a remedy for a post-processing command that points at the wrong file.

Direct compiler builds

A manual Delphi Win32 compiler invocation needs at least these EurekaLog inputs, in addition to the rest of the project's compiler command:

dcc32 Project1.dpr "-UC:\Program Files (x86)\Neos Eureka S.r.l\EurekaLog 7\Lib\Win32\Release\Studio16" -GD -$D+ -DEUREKALOG;EUREKALOG_VER7

That example compiles but does not post-process. Run the separate prepare/alter stages as appropriate, or replace the compiler with the matching EurekaLog wrapper:

"C:\Program Files (x86)\Neos Eureka S.r.l\EurekaLog 7\Packages\Studio16\ecc32.exe" Project1.dpr "-UC:\Program Files (x86)\Neos Eureka S.r.l\EurekaLog 7\Lib\Win32\Release\Studio16" -GD -$D+ -DEUREKALOG;EUREKALOG_VER7 --el_config=Project1_Debug.eof

These commands illustrate the documented minimum, not a portable build command for an arbitrary application. Preserve all existing search paths, resource options, compiler defines, and other arguments. A practical way to obtain them is to build the working project in the IDE, open View > Messages > Build, and expand the compiler command where that IDE exposes it. For Win64 or another compiler, use that toolchain's actual compiler command; do not convert a Win32 build by changing only the EurekaLog library directory.

For a CI acceptance run, retain the expanded commands and post-processor output, then exercise the same deliberate exception in a non-shipping test build. Confirm the emitted settings and symbol behavior for each intended configuration/platform. A compiler-only green build does not meet that check.

TwineCompile: two different failures

Older TwineCompile TCTargets*.Targets files contain a TCPostLink target that calls bare ecc32.exe --el_alter_exe=$(MSBuildProjectFullPath). It can run when the EurekaLog property is defined even if no post-build event appears in your project.

First update TwineCompile where possible. Otherwise either disable its old EurekaLog post-link integration and supply your own correct event, or repair the target you own:

• 'ecc32.exe' is not recognized / exit 9009: use the full, quoted path to the correct Packages\<IDEName>\ecc32.exe. Adding that single IDE directory to PATH is possible on a one-IDE machine, but less explicit.
• Compiled file ... not found or the wrong file is processed: pass the actual linked output after the semicolon, not only the .cbproj. Supply the intended configuration/settings as well.

The published TwineCompile correction uses this Exec command within its existing TCPostLink target:

<Exec
  Condition="'$(EurekaLog)'!='' And '$(TLibLink)'!='true' And ('@(OutputOutOfDate)'!='' Or '$(ForceLink)'=='true')"
  Command='"C:\EurekaLog\Packages\Studio29\ecc32.exe" --el_mode=Builder "--el_alter_exe=$(MSBuildProjectFullPath);$(OutputPath)"'
/>

Here Studio29 means Athens and C:\EurekaLog is an example installation root. Inspect how your TwineCompile version expands $(OutputPath); the final command must identify the linked file. Add "--el_buildconfig=$(Config)" or a deliberate --el_config when your configuration needs it. Preserve the target's original link conditions. Do not retain this target and also add a second EurekaLog post-build event.

2.6 Provision files when automatic IDE registration is unavailable

The normal installer/Manage workflow is preferable (chapter 1). For a build machine without a detectable IDE, or an intentionally virtualized installation, the documented installer switches are /Force_DN for Delphi and /Force_CN for C++Builder, with N taken from section 2.1. For example, using the actual installer filename:

EurekaLog7-Enterprise.exe /Force_D18 /Force_C18

This example installs both XE4 personalities' files. It does not register an invisible IDE or install the compiler. Confirm that the corresponding components remain selected in the wizard. An activation key, if required, still must match this installer.

For a headless build, no IDE expert registration is needed. Supply the relevant paths to the build tool/compiler:

• Library/search paths: Lib\<Platform>\Release\<IDEName>, Lib\Common, and Source\Extras, all under the EurekaLog root.
• Delphi Debug DCU path, when used: Lib\<Platform>\Debug\<IDEName>.
• C++ include path: Lib\Common, along with the generated-header paths appropriate to the installed library set and the project's existing configuration.
• Source browsing path, if wanted for local development: Source. This is not the same as a compiler search path.

Remove obsolete EurekaLog paths that point at a different installed version. Ensure the service account can read the compiler and EurekaLog files, write the project's output directory, and access any explicitly selected configuration. Use the complete command from the working IDE setup rather than guessing additional C++ compiler paths.

For an older 32-bit IDE requiring manual package registration, the documented procedure is:

1. Close the IDE and make the matching EurekaLogCore<version>0.bpl and its shipped debug companions available in the Windows system directory for a 32-bit process (normally SysWOW64 on 64-bit Windows). This file supports the IDE packages; it is not an instruction to add the Core package to every application.
2. Start the IDE and open Components > Install packages. Remove stale EurekaLog package registrations, then add and enable EurekaLogExpert<version>0.bpl and, if needed, EurekaLogComponent<version>0.bpl from the correct Packages\<IDEName> directory.
3. In Tools > Options, set the library, Debug DCU, browsing, and C++ include paths above. Repeat the platform-specific library/debug-path setup for Win64 targets rather than reusing Win32 paths.
4. Reopen the application, remove stale per-project overrides of those EurekaLog paths, and rebuild.

This manual-installation procedure is for the 32-bit IDE. Do not apply its system-folder copying instructions blindly to the newer 64-bit IDE: use the matching installer and Manage registration there. On any normal installation, Manage is safer than copying BPLs by hand because it handles registration and package placement together.

For Turbo Explorer or Delphi 7 Personal without an expert, create options with Start > EurekaLog > Tools > Settings Editor and save a project .eof. In the Delphi .dpr, place EMemLeaks, EResLeaks, and ExceptionLog7 first in the uses list. Add the integration required by your profile; the documented VCL example also uses EAppVCL for Forms hooks and EDialogWinAPIMSClassic for its dialog. Enable the compiler/MAP requirements, build, then explicitly post-process with the correct ecc32 and --el_config. Until that last step, merely linking those units leaves an incomplete EurekaLog setup. Repeat post-processing after every link. This Delphi workaround is not a substitute for the C++ procedure in section 2.3.

2.7 Deploy a matched module, not a folder of guesses

For the usual Inject EurekaLog debug information setting, the module contains EurekaLog options and its converted debug information. You do not normally need to ship the build's MAP/TDS just to use that injected provider. This does not eliminate your application's ordinary DLL or runtime-package dependencies.

Choose and record the debug-information policy:

When storing all names externally, each compilation gets a new .elsym under %APPDATA%\Neos Eureka S.r.l\EurekaLog\Symbols\, and a convenience copy beside the output. The build/compilation ID is the matching key; a product filename alone is not. Archive release symbols from the build account, not only from a developer's interactive account. PE Analyzer displays the project and compilation IDs. Chapter 4 explains restoring names in the Viewer.

For local IDE debugging, normally leave Strip non-EurekaLog debug info off. For production with injected EurekaLog information, stripping can remove MAP/TDS/DWARF inputs after conversion without depriving the injected provider of its own data. If you want to retain those original inputs for other tools, archive them before stripping. Do not promise source-level IDE debugging after removing the IDE's own symbols.

Packages and DLLs

Instrument each module whose own addresses need useful descriptions. An EXE's Detailed MAP is not a source map for code in another DLL or BPL. The Package profile adds module options and debug data to the BPL, but no EurekaLog runtime code; runtime code normally resides in the EXE, or in a deliberately chosen shared Core package. Do not give a BPL an EXE or standalone-DLL profile just to obtain symbols.

For DLLs, choose the profile that matches who hosts them and where EurekaLog is initialized. Code inclusion, shared memory management, report ownership, and safe unloading are architecture decisions (chapters 16 and 29), not consequences of using --el_alter_exe. Build and deploy compatible module sets together; post-process each owned module with its own matching MAP/debug files. For an external DLL you cannot rebuild, use the available matching symbol format and provider rather than inventing source lines that its exported names do not contain (chapter 11).

Keep the final EXE/DLL/BPL set and any required .edbg files together. Archive the matching .elsym, exact compiler/build settings, and source revision privately. Do not replace release symbols with those of a later rebuild that happens to have the same version string. Perform EurekaLog's executable modification before final signing/protection steps unless you deliberately use the documented external-data workflow for an already signed/protected executable; verify the resulting artifact, not an earlier unsignable intermediate.

Convert a Visual Studio DLL's PDB into EurekaLog data

This is a symbol-conversion workflow, not a way to inject a Delphi exception tracer into arbitrary C++ code. Use the single-tracer arrangement described in chapter 16: EurekaLog runs in the host, and the external DLL supplies code and matching symbols. Keep language-specific exceptions inside their documented DLL boundary; conversion does not make incompatible exception ABIs interoperable.

1. In the Visual Studio DLL project, enable Linker > Debugging > Generate Debug Info. Set C/C++ > General > Debug Information Format to Program Database (/Zi), or the documented Edit and Continue alternative (/ZI) when appropriate for that toolchain.
2. Build the DLL and retain its matching PDB in the same folder. A Visual Studio MAP is not a substitute: EurekaLog's MAP parser handles Delphi/C++Builder linker output, not arbitrary text MAP formats.
3. In EurekaLog Settings Editor, create and save an external settings file, for example MSSample.eof, with debug information set to Inject. Select the desired symbol-name and encryption policy. There is no Delphi project from which to obtain these settings; most runtime options in this file are irrelevant because no EurekaLog runtime code resides in this DLL.
4. From the DLL/PDB/settings directory, run the post-processor. Here the root and tool path are examples to replace with the installed tool:

"C:\EurekaLog\Packages\Studio29\ecc32.exe" "--el_alter_exe=NUL;MSSample.dll" "--el_config=MSSample.eof" --el_source=PDB

NUL explicitly stands for the absent Delphi/C++Builder project. The actual target follows the semicolon; --el_config provides the build settings; --el_source=PDB replaces the default Delphi/C++Builder MAP input with the matching MSSample.pdb. The command follows the documented external-DLL conversion form; it does not invoke the Visual Studio compiler.

Check the processed DLL in PE Analyzer for injected EurekaLog information, then exercise the DLL through the enabled host and inspect a known internal function in the resulting report. With converted information injected, the target needs neither the PDB nor a PDB runtime provider merely to resolve those converted symbols. Retain the original PDB privately if other debugging tools need it.

Alternatively, leave the PDB unconverted, enable Microsoft Dbg/PDB in the host's debug-information providers, and deploy the matching PDB with the DLL plus a suitable DbgHelp.dll from Microsoft Debugging Tools (also supplied in EurekaLog's Bin/Bin64 trees). Match the helper's bitness to the process; the Windows system copy is not the documented replacement for this deployment. Chapter 11 covers provider behavior. Do not strip the external debug material and then expect that provider to recover it.

When injection breaks the IDE debugger

A documented C++Builder failure is a debugger that will not load the modified executable, or loads it with disabled breakpoints. This is distinct from the older Release-profile defect in section 2.3.

Check IDE updates and ensure debugger symbols have not simply been stripped. If injection remains the relevant difference, temporarily change Debug information from Inject to Add. If that is insufficient, use Advanced > Custom/Manual and set:

DoNotTouchEXE=1

This tells the post-processor not to open/modify the EXE. A failure that persists then is evidence against that particular executable-modification mechanism; it does not by itself rule out every other integration issue.

Both workarounds change deployment requirements. Either ship the matching .edbg, or restore Inject, set DoNotTouchEXE=0, and rebuild before release. Do not leave a local debugging workaround in a deployment pipeline that copies only the EXE. The source describes this as a workaround, not a confirmed fix for every C++ debugger failure.

2.8 Diagnose a build that produces no useful symbols

Use the nearest failing stage rather than toggling every option:

1. No EurekaLog build messages: inspect whether the expert or explicit post-build stage ran. A direct dcc32 command does not run MSBuild events. Check DoNotTouchCompilation, configuration-specific events, and third-party link targets.
2. Post-processing reports a missing compiled file: compare the expanded target path with the link output. Pass project;actual-module explicitly. Check configuration, platform, working directory, and filename extension.
3. A freshly built program has no compilation information or an immediate Trial warning: inspect code/data versions in PE Analyzer. Confirm the correct installer and all search paths; mixed runtime units and injected data can be rejected as incompatible. Also check that preprocessor conditionals have not hidden/duplicated the .dpr uses clause or switched its program/library/package keyword beyond the simple project parser's understanding.
4. Your own Delphi routine has no line: inspect its debug directive, compiled-unit age, MAP generation, and post-processing input. Rebuild that unit with debug information; a post-process-only rerun cannot manufacture the missing mapping.
5. Only RTL/VCL frames lack lines: check Use Debug DCUs and the library actually linked. Do not mistake missing source files for missing line records: symbol generation and the Viewer's later source lookup are separate stages.
6. Classic C++ Win32 names exist without lines: inspect TD32/TDS generation and the post-processing inputs. A MAP alone is insufficient.
7. LLVM C++ names exist without lines: apply the documented compiler limitation from section 2.3, not the classic TD32 remedy.
8. Reports work on the developer machine only: check .edbg deployment, .elsym availability, cached passwords, and user-specific paths. Reproduce on a clean target with precisely the distribution files.
9. Only DLL/BPL frames are unresolved: inspect that module's profile, symbols, provider, and compilation identity rather than rebuilding only the host EXE.

A stack can remain incomplete for reasons beyond symbol storage, including stack reconstruction limits and the exception context supplied by the compiler. Chapters 11 and 27 separate those problems from ordinary build omissions. Use chapter 5 when EurekaLog's own processing fails.

2.9 Upgrade or rebuild EurekaLog without mixing generations

Before an upgrade, keep the old installer/version record, application source and settings, any local EurekaLog source changes, build scripts, and a matched set of release artifacts/symbols. An old .ellicense may expire; keeping an installer is not a promise that an old activation file will work forever.

Close all IDEs, follow the installer's removal/replacement procedure, and select every required IDE/personality again. Re-register under each developer account as needed. Confirm that IDE and project paths no longer select the old installation. Refresh a copied EMemLeaksBCB.cpp from the new installation rather than unknowingly retaining the old support source.

Clean generated application/dependency units and rebuild every affected target/configuration. Do not copy a new ecc32.exe over a machine still linking old EurekaLog DCUs and call that an upgrade. Repeat the first-report check and the relevant module/thread paths before promoting the release. Preserve existing release symbols; upgrading the tools does not make a newly generated symbol file match an old executable.

IDE maintenance-build incompatibility

Errors such as The procedure entry point could not be located, Unit was compiled with different version, or Could not compile used unit can arise when an IDE update changes binary compatibility. Precompiled EurekaLog packages are built against the supported IDE update current at that EurekaLog release, not every maintenance build ever shipped.

Without full source, choose an installer built for the installed IDE maintenance release or update the IDE to the build required by the installer. With Enterprise source, rebuilding for the installed IDE is another route. Do not infer compatibility from the presence of a Studio29 directory alone: multiple Athens updates share that identifier. Re-registering a binary cannot change its ABI.

Enterprise: a controlled recompilation

This procedure builds the runtime library and IDE packages from the installed Enterprise source. Keep the original files recoverable rather than deleting your rollback copy.

1. Close all projects and IDE instances. Determine the correct <IDEName> from section 2.1.
2. Allow the one-time build to write its installed output directories: use the Manage tool's Register EurekaLog for development mode where available, appropriate targeted write permissions, or an elevated IDE for this rebuild only.
3. With IDEs still closed, run Manage as administrator and Unregister EurekaLog for that IDE. This removes IDE registration, paths, and installed system copies of its packages; it leaves the installation tree on disk.
4. Move/rename the old outputs in Packages\<IDEName> (including a Win64 subfolder if present) and Lib\<Platform>\<Config>\<IDEName> for the combinations being rebuilt. Keep Lib\Obj and Lib\Common intact. If you are not rebuilding ecc32/ecc32speed, keep those tools available: the recompilation guidance says they need not be rebuilt for an IDE change.
5. Open the corresponding Projects\<IDEName>\EurekaLogGroup.groupproj. Ensure the output directories exist. Build EurekaLogCore in Release for the project's applicable platforms, then in Debug for those platforms. Next build the IDE packages EurekaLogExpert and EurekaLogComponent in Debug, with a matching Debug Core build available.
6. Do not mix Core and IDE-package configurations in one package set. In particular, Debug can define DEBUG_EL_CODE; inconsistent settings can cause unit-version and entry-point errors. The preceding order deliberately leaves a matching Debug Core for the Debug IDE packages while preserving separately generated Release library files.
7. Check the resulting layout: BPL/BPI outputs belong in Packages; DCU/HPP/LIB/A/OBJ/O outputs belong in their Lib configuration/platform directories. Some older IDEs misplace outputs, especially generated C++ files. Keep generated files out of Source and correct misdirected output paths before continuing.
8. Close the IDE, run Manage, and use Register EurekaLog (recommended) to register the rebuilt packages and their system copies. Then rebuild an application and exercise its reporting path.

Warnings about units implicitly imported into an EurekaLog package are expected in the documented rebuild procedure. That does not make unrelated compilation errors harmless. The shipped packages contain injected EurekaLog diagnostic information that a simple source rebuild does not recreate, so output sizes can differ; Manage may even identify a locally rebuilt package as an older EurekaLog generation because that metadata is absent. Do not use that display alone as a verdict on the rebuilt source version.

For recompilation on demand rather than rebuilding all package outputs, the Enterprise development registration mode can put source on the compilation path. The manual equivalent is to use Source, Source\Common, and Lib\Obj\Win32 or Lib\Obj\Win64 as library/search paths, with a writable, dedicated project unit-output directory and no stale precompiled EurekaLog units masking the source. These are compiler paths, not browsing paths. A full Core-package build is the simpler way to recreate a complete precompiled library set.

Recompiling the Viewer is a different task: its source depends on DevExpress components not supplied with EurekaLog. Rebuilding the bundled ZLib object files requires ZLib source. Neither is required merely to rebuild EurekaLog's runtime library for your IDE.

2.10 Disable, remove, or roll back deliberately

Three operations have different effects:

• Disable EurekaLog in a project/configuration: keep the integration for later use, but choose not to activate it in that build. Chapter 25 covers configuration selection and code guarded by EUREKALOG.
• Unregister EurekaLog in Manage: remove that user's IDE integration while keeping the files installed. This does not strip EurekaLog from previously built executables.
• Remove EurekaLog from the project: open Project > EurekaLog options > Reset, then choose Remove EurekaLog, not merely Disable. This deletes the project's EurekaLog settings; manually written dependencies still need removal.

For full project removal, remove manual EurekaLog calls, unit references, and components, including TEurekaLogEvents and the form unit's EComponent reference. In C++, remove the manually added support file, USEOBJ, header, and startup call when they are no longer used. Remove your own EurekaLog build events/scripts and any TwineCompile override that would continue post-processing. Rebuild from clean generated outputs.

If a hidden unit reference remains, close the IDE, temporarily unregister EurekaLog with Manage, reopen the project, and perform a full build. The compiler's missing-unit errors identify remaining dependencies; repair them, then restore IDE registration for other projects if needed. Do not remove every unit beginning with E indiscriminately—identify actual EurekaLog dependencies.

For rollback, restore the previous coherent EurekaLog installation or saved rebuilt package/library set, its compatible IDE environment, and the corresponding project/settings revision. Clean and rebuild all affected modules. Never roll back only the post-processor or only the runtime DCUs. Keep the newer build's reports and symbols associated with that newer build; a rollback is not a reason to overwrite its diagnostic archive.

A release is ready for diagnosis when the final build has the intended runtime integration, a successful post-processing stage, an exercised report path, and matching retained/deployed symbol material. None of these can be inferred solely from the fact that the application starts.