|
|
You can click on the tabs in the left side of the image:
The first option include minimal debug info only gives you the option to tell madExcept to not include function names and line numbers into your binary (exe/dll/bpl) file. The one and only motivation for activating this option should be protection from reverse engineering. Without function names and line numbers reverse engineers have no advantage from the fact that you're using madExcept. However, *you* have a disadvantage: The bug reports you'll get from your customers will miss function names and line numbers. You can compile such "bad" bug reports to full bug reports by using the tool "madCompileBugReport". This tool needs access to the "mad" file which madExcept created when your binary file got compiled & linked.
The option this module gets no own madExcept settings should be used when your application consists of a whole bunch of modules (dlls/bpls) and when you want all those modules to share the same madExcept settings. In this case store the settings into the main module (probably the exe) and activate this option for all the other modules. The other modules will then automatically find & use the settings stored in your main module.
By default madExcept checks whether your binary file seems to have bit faults or not. This is done by calculating a checksum and comparing it to the checksum stored in your binary file's PE header. If the checksum is found to be incorrect, madExcept will complain. If your binary file is the executable, madExcept will show a warning box and then close your application. If your binary file is a dll or package, madExcept will raise an exception.
If you turn the check for frozen main thread option on, madExcept periodically checks at runtime whether your main thread still reacts on messages. If it does not react for the specified time (default 60 seconds), an exception is raised. This functionality should help you finding and locating infinite loops and dead locks. Since each bug report contains the callstack of all threads of the current process, you can often quite easily see, what each thread was doing and who possibly waited on whom and why.