Root > Integral parts > Options > Advanced page

Advanced page

Previous pageReturn to chapter overviewNext page   

This is "Advanced" page in EurekaLog project's options.



Advanced options


This page allows you to set advanced EurekaLog options. There are also some sub-categories:



1. "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.



2. "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).



Each safecall exception is considered to be handled exception. Keep that in mind when you setup exception filters or write event handlers.
This option has no effect if "Catch handled exceptions" option is enabled (see below).
This option requires extended memory manager enabled.
It's a good idea to include fix for QC report #81725 when you use "Handle every SafeCall exception" option.
Internally, "Handle every SafeCall exception" option installs hook for ComObj.HandleSafeCallException routine (when low-level hooks are allowed) or scans exception's call stack for _HandleAutoException routine (when low-level hooks are not installed). The later can cause building call stack for all exceptions even with "deferred call stacks" option set.


Alternative for this option is to invoke EurekaLog manually from your SafeCallException handler.


See also:



3. "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.


Note: you should use "Handle every SafeCall exception" option for safecall-exceptions instead of "Catch handled exceptions" option.

Note: this option requires extended memory manager enabled.



4. "Use safe mode to handle special exceptions" option allows EurekaLog to process otherwise fatal exceptions.


Enable to get EurekaLog reports on all possible exceptions. Application will be closed/restarted when fatal exception occurs. We recommend to keep this option enabled.
Disable if you want to avoid application restarts. Application may crash or produce internal EurekaLog crash report when fatal exception occurs. We do not recommend to disable this option.


EurekaLog may take additional steps to produce reports for fatal exceptions. For example, if your application have buffer overflow bugs that damage internal control structures of memory manager - EurekaLog will still be able to handle such exception by entering the emergency "safe mode".



It is not possible to continue normal execution of application once "safe mode" was activated. That is why your application will be closed or restarted once fatal exception will be processed;
EurekaLog will break into debugger when "safe mode" is activated (you will be inside DebugBreak routine called from PanicModeOn routine), so you can inspect exception immediately;
It is not always possible to tell if exception will be fatal ahead of time. That is why EurekaLog will enter "safe mode" for all exceptions of certain type (which can potentially be fatal);
If you want to allocate memory and fail on "out of memory" error, while still having this option activated - use EurekaTryGetMem function from EMemLeaks unit.



5. "Call RTL OnException event" option will invoke default processing for exception after processing exception by EurekaLog. Use this option to get default behaviour (such as error dialogs), but still use EurekaLog features.


Usually it's a good idea to disable error dialogs and visual feedback when enabling this option.


It's not recommended to use this option. It's primary used for backward compatibility with old EurekaLog versions. New code should consider using RTL error dialog instead.



5. "Low-level injection hooks" option allows or forbids using of low-level hooks. Low-level hooks use code injection (e.g. overwrite machine code with JMP CPU instruction).


Using low-level hooks allows EurekaLog to act automatically. Otherwise, you need to call EurekaLog manually. Additionally, 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.


It is recommended to keep this option enabled when possible. Disable it only for special cases.


Important Note: We do not recommend to change this option from default value ("Allow all") when compiling with LLVM.


Low-level hooks in external modules ("Allow all" or "Allow for external modules only"):

Installs hook for KiUserExceptionDispatcher (Windows 2000 only; Windows XP and above: EurekaLog uses VEH (Vectored Exception Handling)): allows EurekaLog to react on exceptions and collect CPU state;
Installs hook for CreateThread/ExitThread:
oallows EurekaLog to automatically track threads (see note below);
oallows EurekaLog to produce better multi-threading reports (e.g. indicate thread's creator, etc.);
Installs hook for RaiseException:
oallows EurekaLog to better track non-Delphi exceptions (see also "Capture stack only for exceptions from current module" option);
oallows EurekaLog to track thread name changes;
oallows EurekaLog to build proper call stacks for LLVM software exceptions.

Disable this option (set to "Disable all") if you are using software protection tool that monitors integrity of whole process.

Disable this option (set to "Allow for current module only") if you are loading and unloading several DLLs with EurekaLog in a different order (e.g. load A.dll, load B.dll, unload A.dll, unload B.dll).

Disable this option (set to "Allow for current module only") when there are conflicts with 3rd party hooks/exception tracers from external DLLs.

Important Note: Do not disable this option for application build with LLVM. Additionally, EurekaLog will not be able to track threads when this option is disabled. It is recommended to use BeginThreadEx/TThreadEx or (for any other thread) call SetEurekaLogStateInThread function to enable EurekaLog in thread and call EThreadsManager._NotifyThreadGone function to notify EurekaLog about thread's termination.


Low-level hooks in current module ("Allow all" or "Allow for current module only"):

Installs hook for TObject.Destroy:
oallows EurekaLog to track life time of exception objects (only for LLVM and Delphi 2007/C++ Builder 2007 and earlier; Delphi/C++ Builder 2009 and above (without LLVM): EurekaLog uses new SysUtils.Exception class);
oallows EurekaLog to make better reports for memory errors;
oallows EurekaLog to catch handled exceptions;
Installs hook for HandleSafeCallException: allows EurekaLog to automatically react on safecall exceptions;
Installs hook for TComponent.SetName: allows EurekaLog to track component names when reporting memory problems;
Installs hook for TThread.Execute: allows EurekaLog to automatically handle exceptions in TThread (obsolete feature);
Installs hook for System.@HandleAutoException: allows EurekaLog to fix issue #81725 ("TObject.SafeCallException can be not called in certain cases");
Installs various hooks for handle stage - as set in options (for example, VCL.Forms.TApplication.ShowException for VCL Forms application, VCL.SvcMgr.TApplication.DoHandleException for service application, etc.): allows EurekaLog to handle (process) exceptions automatically. Otherwise you will need to call EurekaLog manually.

Disable this option (set to "Allow for external modules only") if you are using software protection tool that monitors integrity of application (current module).

Important Note: Do not disable this option on Delphi/C++ Builder 2007 and earlier. Do not disable this option when compiling with LLVM. Otherwise EurekaLog will not be able to track life time of exceptions.



6. "Stack Reserve for handling overflows" (.ThreadStackGuarantee) option sets the minimum size of the stack that will be available during any stack overflow exceptions. This is useful for handling stack overflow exceptions; the application can safely use the specified number of bytes during exception handling. If the specified size is less than the current/previous reserve size - it will be ignored. Therefore, you cannot use decrease the stack reserve. This value cannot be larger than the reserved stack size (1 Mb by default).


Set to 0 to disable this feature.


Stack reserve will be applied automatically for all threads created while EurekaLog is active. Alternatively, you may call EnsureThreadStack function in any thread to apply the option to the calling thread.


Usually it is not necessary to change/increase this option, because EurekaLog will automatically process any stack overflow exception in a standalone background service thread.


This option is ignored on Windows XP and earlier systems.



See also:

Send feedback... Build date: 2023-09-11
Last edited: 2023-03-07
The documentation team uses the feedback submitted to improve the EurekaLog documentation. We do not use your e-mail address for any other purpose. We will remove your e-mail address from our system after the issue you are reporting has been resolved. While we are working to resolve this issue, we may send you an e-mail message to request more information about your feedback. After the issues have been addressed, we may send you an email message to let you know that your feedback has been addressed.

Permanent link to this article: