This is "External tools" page in EurekaLog project's options.
External tools options
Options on "External tools" page allow you to customize EurekaLog behavior for integration with other 3rd party software. This page contains options from other pages.
1. "Delete service files after compilation" option allows you to clean up your project from unnecessary files. EurekaLog asks linker to generate .map/.tds/.drc files to read debug information from them. Once debug information is injected - these files are no longer needed. This option can be used to delete them automatically. See EurekaLog's basics for more information. You can turn this option off to keep files untouched (if you want them for other 3rd party software).
Turn this option off for external debuggers, profilers and debug information convertor tools (such as map2dbg).
2. "Reduce file size" option removes relocation table from file. This reduces file's size for about 10% (however, enabling EurekaLog also increases file's size).
It's recommended to always keep this option on.
Note: this option have no effect for DLL and packages.
When you compile a DLL (or a package which is a Delphi-specific DLL in disguise), the linker includes what is known as a relocation table. This table includes information about what addresses must be fixed up by the OS loader in the (likely) event that the DLL must be loaded at a different address than its intended-at-compile/link-time base address. You see, all DLLs come with a base address that is the "ideal" loading address of that module. The OS will try to load the DLL at this address to avoid the overhead of runtime rebasing (patching the in-memory pages of the DLL forces it to be paged in from disk and prevents cross-process sharing of the DLL pages). That's why you should set the Image base option in the Linker page of the project options of DLL and package projects. The default Image base that Delphi uses is $00400000 for both applications, DLLs and packages - and thus by default all DLLs and packages will need to be rebased - as that address is reserved for the process' EXE file.
The implication is that an EXE file will always be loaded at the fixed virtual address $00400000 and that it will never need to be rebased. Alas, it doesn't really need its relocation table and we can safely remove it, shrinking the size of the .EXE without affecting its behavior or performance.
3. "Check file corruption" option adds check for file corruption in your project. If you enable this option, EurekaLog will calculate a CRC checksum of the compiled file and store it inside file. EurekaLog will also read this checksum from file on its startup (launch). If your executable was modified, EurekaLog will display an appropriate message and shutdown your application immediately:
EurekaLog detected changes in executable file
You can use this option to ensure that your code wasn't modified.
Turn off for digitally signed files, packers or protectors.
4. "Use speed optimizations" option enables caching of kernel information to improve performance of stack tracing.
Turn off for packers and protectors.
Note: this option will be automatically disabled when "Detalization level" option is set to "Show any (including RAW addresses)" or "Show any item belong to executable module (unknown locations within DLL)" value.
It is recommended to keep this option unchecked unless you suffer from slow work of your application.
5. "Use low-level hooks" option allows or forbids using of low-level hooks. Low-level hooks use code injection (e.g. overwrite code with JMP machine instruction).
Using low-level hooks allows you to capture low-level information such as CPU state. Low-level hooks are also required for additional WER functionality. However, a documented way of installing low-level hook is available only in Windows XP and later. For older OS - undocumented hack will be used. If this option is unchecked - EurekaLog will use RTL functionality and will not install low-level hooks.
Turn off for packers and protectors.
Important note: turning off low-level hooks means that EurekaLog will not install additional hooks for API functions. This means that EurekaLog will not intercept important system calls. For example, EurekaLog will not hook ExitThread function, which means EurekaLog will not know when a thread exits. This will lead to thread information stored forever - until application terminates. You can call internal _NotifyThreadGone or _CleanupFinishedThreads functions to notify EurekaLog about thread's termination. Such manual notifications can be avoided by using EurekaLog's wrappers (TThreadEx, for example).
6. "Delay call stack creation until handle stage" option postpones analyzing exception for later stages of processing.
Please, see this article for detailed explanation of delayed (deferred) call stacks.
Enable this option for better performance.
Disable this option for better detalization and compatibility.
Note: enabling some advanced features of EurekaLog (such as handling safecall exceptions, using exception filters with "Exception Kind" <> "All", etc.) may require creating call stack earlier than usual (for example: to detect if exception is raised within safecall wrapper), so this option will have no effect.
7. "Handle every SafeCall exception" option is used to catch safecall-exceptions with EurekaLog. This option is useful in COM servers, COM applications and other interface-related code.
When this option is off - safecall exceptions will be handled by default processing which usually means losing information about error location.
When this option is on - safecall exceptions will be handled by EurekaLog and then by default processing.
Usually it's a good idea to disable error dialogs and visual feedback for safecall exceptions since these exception will be handled by calling code (which will display error message).
Alternative for this option is to invoke EurekaLog manually from your SafeCallException handler.
8. "Catch handled exceptions" option will enable EurekaLog for all exceptions. By default EurekaLog processes only exceptions which are unhandled (see handled/unhandled terms definitions).
It's not recommended to use this option. That's because "handled" for exception means that this exception is expected and it was handled by code. Therefore, it's better to setup proper exception handling in your code. This option is used primary as last resort measure to work with "bad" code (the code which hides unhandled exceptions).
Be sure to setup proper exception filtering when you enable this option. Often it's a good idea to disable error dialogs and visual feedback for handled exceptions.
9. "Capture stack only for exceptions from current module" (.csoCaptureOnlyModuleExceptions) option allows you to speed up execution by ignoring all exceptions outside of your executable module.
Since normal practice for exceptions is to handle them within the same module - exceptions usually do not leave module (i.e. they are not shared between modules). This means that you're usually interested only in exceptions from the same module. This option allows you to ignore any other exception.
Note: this option is extremely useful in applications with plug-ins (including COM modules).
It's recommended to keep this option checked when possible. Disable this option for packaged applications or other application types which includes sharing exceptions between modules.
11. "Configure external tools run" option allows you to specify commands to invoke during building process. You can place a call to external tool (such as packer, protector or debug information converter).
Delphi 2009+: order of actions during project's compilation is as follows:
Note: you must post-process executable with EurekaLog first, and only after this - you can post-process executable with packer/protector/digital signature tool. On the other hand, debug information converter may be run before or after EurekaLog's post-processing - it doesn't matter (as long as debug information is present and untouched).
12. "Customize debug information providers" option allows you to customize debug information reader classes ("providers"). You may want to enable additional providers to be able read debug information supplied by external tools.
13. "Customize memory manager" option allows you to customize debugging memory manager. It's highly recommended to keep "Enable extended memory manager" option turned on (you can disable other memory checking options if you want to). Installing filter on memory manager will allow EurekaLog to track life-time of exceptions objects without need to install code hooks.