You can click on the tabs in the left side of the image:
The first option link in madExcept code defines whether madExcept is trying to get its code linked into your exe/dll/bpl file. Normally this is the recommend thing to do. madExcept will then consequently add itself to your project's uses clause. There are situations where it can make sense to turn this option off. E.g. if you have a package which doesn't directly call any madExcept functions, this package doesn't necessarily have to link to madExcept. If the exe file already links to madExcept, that is good enough to protect all runtime packages from exceptions, too.
If your exe is compiled with madExcept, and if you have a bunch of dlls or packages, then it can make sense to define which files get their own madExcept settings and which don't. One reasonable configuration would be to store madExcept settings in the exe file, only. As a result all dlls and packages would then share the exe's madExcept settings. You can realize this configuration by activating the option link in madExcept settings in your exe project, and by deactivating it in all your dll and package projects. A different and of course also valid approach would be to configure some (or all) dlls and packages to have their own separate madExcept settings, too. That would allow you to e.g. specify different bug report email receivers for different dlls or things like that.
If you disable the option link in function names and line numbers, madExcept will only store the function addresses into your exe/dll file, but no unit names, function names and line numbers. The one and only motivation for doing this would 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, obviously. You can "compile" such 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. So if you want to use madExcept this way, it is your responsibility to store the "mad" file for every release build of your software.
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 to 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.
If you want to get the "Windows Client Software Logo", you will have to meet a couple of funny requirements specified by Microsoft. One rule is that your application is not allowed to handle critical exceptions on its own. Instead you have to let the OS handle the exception. IMHO this is a pretty stupid rule, but that's just the way it is. The "Windows 7 Client Software Logo" PDF (download) reads: "Some applications may be designed to handle crash data internally due to sensitive user information or digital rights issues. To be eligible for the Windows 7 logo in such a case, ISVs must send an e-mail to: firstname.lastname@example.org with technical justification outlining why the application must process unhandled exceptions internally". So you can try to contact Microsoft to get around this stupid rule. But if for whatever reason Microsoft declines, you can activate the madExcept option conform to "windows logo" requirements, which will force madExcept to pass access violations to the OS instead of handling them itself. The disadvantage is that you no longer get a madExcept report about access violations. So this is definitely not recommended.
Before releasing a new version of your software, you may want to do some extra testing to make sure your software is as stable as possible. The options in the "active error search" category allow you to test your software for hidden bugs like memory leaks, resource leaks, buffer overruns etc.
The madExcept code which is responsible for finding these bugs is not compiled into your exe/dll file. Instead it's located in "madExcept32.dll". If you activate any of the "active error search" options, your exe/dll will then during madExcept initialization locate and load the "madExcept32.dll". On your development PC this will happen automatically. If you want to use the "active error search" functionality on other PCs, you should copy the "madExcept32.dll" file to your exe/dll folder. Currently, the "active error search" functionality only supports 32bit processes.
The option report resource leaks will tell madExcept to carefully analyze the behaviour of your software and find and report leaks of any kind. Supported leak types are all kinds of memory allocations (both by the Delphi memory manager and by win32 allocation APIs), kernel handle leaks, GDI handle leaks, user handle leaks, shell handle leaks etc etc. Leaks are reported when your exe/dll is closed/unloaded.
The option instantly crash on buffer overrun/underrun replaces the Delphi memory manager with a different one which is optimized to find bugs, on the cost of memory consumption and performance. With this option activated, any buffer overrun (or underrun) will directly result in a crash, which will then result in a proper madExcept crash report, allowing to you easily find the buggy source code. Normally, buffer overruns are often undetected and only result in crashes much later in the life of the process. The madExcept debug memory manager will also produce an instant crash whenever you try to access a freed buffer. You can find more information about these features here.