This is "Restart&Recovery" page in EurekaLog project's options.
Restart and recovery options
Options on "Restart&Recovery" page allow you to customize EurekaLog behavior for restarting application on errors.
1. "None/Restart/Terminate" (.AutoCrashOperation, .AutoCrashNumber, .AutoCrashMinutes) option specifies action to trigger when more than specified number of errors occurs in less than specified amount of time interval. None option will disable this feature. Restart option will automatically restart application. Terminate option will automatically close application.
Use this option to automatically restart/terminate application in case of "exception spam" - i.e. when large numbers of exception occurs in a short amount of time.
|•||It's not recommended to enable both options (restart in dialogs and this feature) to avoid confusion for end-users. If you do enable both options - be sure to select same values in both options (e.g. "restart" + "restart" or "terminate" + "terminate", but not "restart" + "terminate" or "terminate" + "restart");|
|•||When number of errors is set to 1 - application will be restarted/terminated after first exception regardless of timeout;|
|•||Only unhandled exceptions (i.e. processed by EurekaLog) are counted. If exception is not handled by EurekaLog - it will not be counted. Thus, it's perfectly possible to build application with heavy exception usage.|
|•||This is global counter. Be extra careful to use it in multi-threaded applications, as exceptions from multiple threads will be counted within the same timeout interval. For example, if you set to terminate application after 10 errors within 1 minute, and you have 10 threads, and each thread will raise 1 exception - then your application will be terminated;|
|•||This setting specify "time window" to monitor exceptions. It is designed to close application if it is "rushed" with exceptions. This is very similar to "Show restart checkbox after N error" setting in dialogs. For example, if there is 10 exceptions total, one exception each second - then application will be terminated after 10 seconds, even though this setting says "Terminate after 10 errors in 1 minute" - because this is what just happened: you get your 10 exception within 1 minute time window;|
|•||EurekaLog may terminate your application regardless of these options when it encounters a fatal problem. For example, out of memory error or memory corruption will generate bug report and terminate your application - because it is not possible to continue normal execution after memory problems. See also "Use safe mode to handle special exceptions" option.|
2. "Log application's exits" (.LogAppExits) option will create a log file with call stack for unexpected application's exits. Use this option to diagnose unexpected termination of your application.
Important Note: Created process exit log file is not subject to usual exception processing. E.g. it will not show any dialog, will not be send to developers, etc. This is because log may be created for expected application's exits. If you want to receive such log from a remote PC - you can ask user to send it manually, send it on next startup, or attach it to your next exception report.
|•||This option works only for applications. It does nothing for DLLs;|
|•||If you do not see a file for the exit log:|
|o||This option will output log file name via OutputDebugString, so you can catch it in a debugger or DebugView tool;|
|o||This option will not capture a normal exit from your application (e.g. when your application reaches end in main dpr file, or when Halt is used);|
|o||This option installs hooks for TerminateProcess, TerminateThread, ExitProcess, ExitThread. In other words, it will not be able to catch termination of your application from external application. This external application may also be WER (Windows Error Reporting). If you need to diagnose termination of your application by another app - use Windows Debugging Tools;|
|•||This option will catch exits from application caused by EurekaLog itself (like restarting your application);|
3. "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 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).|
Build date: 2020-06-30
Last edited: 2020-04-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: https://www.eurekalog.com/help/eurekalog/restart_recovery_page.php