This article is a part of basic procedures.

When any error occurs (like unhandled exception or leak) - EurekaLog generates a so-called bug report. This report can be saved to file and/or send to you (as developer of application). One file can holds many bug reports. See this article for more information about bug reports.

Bug report includes one or more call stacks, some information about application and system, and also may include additional files (like screenshot or current opened document in your application, etc).

Saving bug report to file

You can save bug report to file. Saving bug report is enabled by default, so you actually need to disable it, if you don't want/need it. Saving bug report is useful, when you want to analyze the problem after application was closed.

Note: it is recommended to use System Log for Win32 service applications.

To enable or disable saving bug report to file - go to "Bug report" section in EurekaLog project options and enable or disable "Save bug report to file" option.

Usually EurekaLog bug report file have extensions of .el, .elp or .elx - depending on format of bug report. Only .el file extension is available for saving reports - meaning a simple text bug report. Other types of reports (.elx and .elp) are intendant only for sending to developers.

You can configure saving bug report to file on the same page.

First, you can specify a folder to store bug report. Default is a subfolder in "%APPDATA%\Neos Eureka S.r.l\Bug reports\" (see also). Empty string means default path (i.e. the same folder - "%APPDATA%\Neos Eureka S.r.l\Bug reports\").

Note: you can open this folder with bug reports by opening Start / Programs / EurekaLog / Bug reports menu item.

If you want to save bug report to the same folder as executable module - use ".\" folder. You can also use any other relative path, like this for example: ".\Reports".

Note: if your selected folder will be write-protected at run-time, EurekaLog will revert it to default. If path doesn't exist - it will be created.

All bug reports are saved in the same file, so new bug reports do not overwrite old reports - they appended to the end of the same file. You can specify a maximum amount of reports, which one file can hold. By default it's 32 (it's "Max reports in one file" option). A typical default bug report has 100 Kb in size, so 32 reports will take approximately 3,2 Mb at maximum. When limit is reached (by count, not by size), the oldest report (which is stored first) will be deleted.

If you don't need or want to store multiple reports - you can specify a value of 1. This will emulate case "new report overwrites old". This behaviour is a good idea for developer's machine.

Since capacity of file can be limited, you may be interested in storing information with maximal usefulness. For example, you may don't want for this file to hold a 32 bug reports of the very same error, which occurs 5 times a day. You can enable "Do not save duplicate errors" option to take care of this situation. When this option is enabled - file will contain only unique bug reports. If current bug reports represents an problem, which was already saved in the file - the file will not be appended with new bug report. Instead, a error's count will be increased as +1. How EurekaLog knows, which reports are duplicates and which are not? It uses a so-called Bug ID. Reports with the same Bug ID's values are treated as equal (even though they aren't - obviously, their date-times are different). Reports with different Bug IDs will be saved to file anyway.

Option "Delete file at version change" may be useful, if you don't want to get old bug reports, when you've released a new version of your application. If you enable this option - then be sure to use version information in your project and to increase it with new build/release. Once enabled, this option will delete bug report's file, if it holds reports from previous version of your application.

Configuring bug report's content

Call stack is a central piece of information inside any bug report. Since it plays such important role - there are many options and features for call stacks. Because there is a lot of information to describe these options - this information is separated into its own article.

You can configure other information (not call stack; auxiliary information) which you want to include in the bug report. Just go to "Bug report / Content" section in EurekaLog project options and enable or disable parts of information to include in bug report.

While some people tends to enable everything - it may be not be a very good idea. Collecting information takes time. Collecting everything will result in freezing your error dialogs for short amount of time. Is it really needed? If your application doesn't work with printer - why collect printer information? If your application doesn't communicate with other applications - what can be useful in processes list?

Usually, it's a lot better to include only required information - disable everything and enable only option which can be useful for your kind of application. For example, a Win32 service can collect information about current account and its privileges. A text editor with printing feature can capture information about installed printer. An application with extensive graphic work can include a monitor and video-card information. And so on.

Also, be aware that your application may be considered as harmful (spy-ware) by customers, if it collects extensive information which is definitely not needed (like monitor information for non-GUI applications).

Note: project options may affect bug report detalization.

See also: