You can click on the tabs in the left side of the image:
The bug report consists of multiple sections. The header of each bug report contains general informations about the PC on which the exception occurred. Some examples are the running operating system and the current state of the resources. After that the callstack of the crashing thread and (if different) also the callstack of the main thread is listed.
Next the callstacks of all running threads are also listed, if there are any apart from the crashing thread and the main thread. If you don't like that many thread call stack traces, you can turn that feature off. In that case only the crashing and the main thread are listed.
By default madExcept adds an exception location disassembly, a list of the cpu registers and also a stack dump. All these sections are mainly interesting for people who understand assembler code and want the maximum information about the exception they can get. So you can turn all that off, too.
If you don't like that monster call stack traces you can hide callstack items which have no line number information. This often reduces the length of the call traces quite dramatically.
The thread callstacks always contain the absolute address and line number of each callstack item. Additionally madExcept can show the address offset to the beginning of the procedure and the line number offset to the beginning of the procedure. These can be useful e.g. if you have sources which have changed slightly in comparison to those with which the crashing application was originally built. The relative information is much more probable to still be the same.
The disassembly can be adjusted to your wishes. You can let madExcept format the disassembly output for you. In that case jump labels and delimiter lines are automatically added, which makes bigger disassemblies much better readable. This option makes sense only if you choose a quite high limit for the disassembly length (see below) or if you don't limit it at all.
You (probably) never know in which function an exception will occur. If it happens to happen in a very big function, the disassembly can easily reach thousands of lines. So it is recommended to limit the number of asm instructions - or in other works to limit the length of the disassembly. You don't need to, but I recommend it. The limits are always used for the assembler line count before and after the exception location. That means, if you choose a limit of 5 instructions, the disassembly will be 11 instructions long (or shorter, if the to-be-disassembled function is not that big).
You can create your own plugins and register them into madExcept. The properly registered plugins are listed and can be enabled for each project. In the moment when you activate a plugin, the plugin unit is automatically added to the uses clause of your project. If you're interested in writing your own plugins, please head on over here.