| • |
redesigned settings dialog
|
|
The madExcept settings dialog needed a complete redesign to make space
for many new options. I think it looks quite nice now... :-) Hopefully it's
a bit more intuitive, too.
|
| • |
thread safe assistants
|
|
You can create assistants (= a number of forms where each form is a step of an
assistant) at designtime in the madExcept
settings dialog. These assistants are fully thread safe (not using any VCL
stuff) and can be automatically shown at specific situations, e.g. if the user
presses the "mail bug report" button. This can be used to ask the user for his
name and email address, or to ask him what he did to produce the crash. The
forms/assistants are fully configurable, similar to how the Delphi object
inspector works for VCL forms. Supported controls are labels, edits/memos,
check boxes, buttons and images. Optionally you can tell madExcept to
automatically add the edit/memo/checkbox content to the bug report.
|
| • |
exception box variations
|
|
By default madExcept shows the full exception
box, but not yet the bug report details. You can instead opt to show a
normal message box with just an "OK"
button instead. Or you can show a normal message box with an "OK" and a
"Details" button, which when being pressed shows the full exception box with
the bug report details. Also you can choose to show a madExcept assistant
instead of a normal box. Whatever you like.
|
| • |
exception filters
|
|
You can determine specific behaviour for
specific exception classes. E.g. you can turn off bug report creation for
some exception classes, or show a simple message box instead of the full blown
up madExcept exception box etc... Quite flexible. |
| • |
resizable exception box with tabs
|
|
When you click on "show bug report" the old builds of madExcept showed a boring
scrolling monospaced memo field. I've now removed that and instead I'm showing
the seperate bug report sections in seperated tabs. The contents of each
section are nicely formatted by using owner draw list views. Looks quite good
(IMHO at least). Furthermore in "show detail" mode the exception box is now
resizable. Finally sections added by plugins are auto formatted. Depending on
the content of the section they are either shown in a mono spaced list view or
in a variable spaced list view or in a memo field.
|
| • |
hyper jump functionality
|
|
If in the exception box you click on "show bug report" and if you then double
click items in the exception callstack, madExcept will automatically switch to
the Delphi IDE editor window for you and open the double clicked unit at the
specified line number taken from the callstack. madExcept uses the relative
address and line number information, so this will even work, if the sources are
slightly changed. You need to have the correct project loaded and successfully
compiled, though.
|
| • |
threaded bug report creation
|
|
In earlier versions madExcept first created the bug report and then showed the
exception box. Now the exception box is shown as early as possible. The bug
report is calculated in a secondary thread and updates the exception box, when
it's complete. If the user aborts the box before the bug report is fully
created, the bug report creation is aborted (except if you turned features like
auto mailing or auto saving on). These changes result in a significantly
improved response time for the end user.
|
| • |
extended runtime package support
|
|
In earlier versions you were not allowed to compile madExcept into one of your
own packages. Instead you had to compile it into the executable file. Nor were
you allowed to use madExcept_.bpl as a runtime package. Now this all changed.
You may use madExcept_.bpl as a runtime package. Alternatively you may compile
madExcept.pas etc into one of your own packages, if you prefer that. Either way,
in order to enable madExcept in this situation there must be one module (exe or
package) which is compiled with madExcept "enabled". This module must be loaded
before the madExcept runtime package is initialized (ideally that module should
be statically linked). Usually you should either compile the exe with madExcept
enabled or the runtime package in which madExcept.pas is contained. Of course
you can compile multiple (or all) modules with madExcept enabled. madExcept
will then for each exception use the settings which are stored in that module
in which the exception occurred.
|
| • |
bug report plugins
|
|
You can now write your own
plugins for madExcept. These show up in the
madExcept settings dialog. You can also
share your plugins with other madExcept users. Installation of the plugins is
fully automated by madExcept. A simple double click on the plugin file suffices.
You can download some sample plugins here:
|
| • |
madExcept settings stored in the resource section
|
|
This has multiple advantages:
| • |
the string length of all the madExcept captions&texts is not limited, anymore
| | • |
you can access (read & write at runtime) the settings of not only your own
module, but of all modules in your process
| | • |
most translation tools will now automatically detect madExcept's strings
| | • |
you can check via a resource editor (e.g. "Resource Hacker") which
madExcept settings a specific exe/dll is using
|
|
| • |
settings accessible at runtime through an IInterface
|
|
By calling MESettings you get an interface which gives you access to the
most important madExcept settings. By using "MESettings(someModuleHandle)" you
can get an interface to the settings of another module, which you can change at
runtime, too. The other module will automatically notice that and behave
accordingly.
|
| • |
exception information encapsulated in an IInterface
|
|
Again this gives us multiple advantages:
| • |
the callback function declarations
are simple now (only 2 parameters) and won't have to change so often, anymore
| | • |
you get easy access to all the parts of the bug report, e.g. you can easily
delete or add bug
report header items
| | • |
you can ask the exception interface to notify you when the bug report is
fully rendered
|
|
| • |
exception interface is descendent of settings interface
|
|
Might sound strange at first, but it does make sense. The
exception interface inherits the
settings properties from the settings
interface. This enables you to adjust the settings for a specific exception
context, only. You no longer need to modify the global settings for one
exception and later restore the old state. When an exception occurs, the
exception interface is automatically initialized with the current active global
settings.
|
| • |
duplicate bug report detection
|
|
There's a exception information item named
CallstackCrc now,
which contains 3 hexadecimal numbers. The first one is a crc of the exception
location. The 2nd one is a crc of the whole crashing/frozen callstack. The 3rd
is a crc of all Delphi/BCB threads.
These crcs can be used to check whether two bug
reports are identical in some parts or not at all. The crcs are calculated so
that rebuilds of the same application with different absolute code addresses
won't change the crcs. That means even when bug reports of different versions
of your project come in, the crcs can still help to identify which bug reports
are identical - as long as the relative address offsets of all callstack items
remain unchanged.
madExcept internally makes use of these crcs to
realize the new feature save settings -> don't
save duplicate exceptions. When madExcept notices that an exception is
already contained in the bugreport file, it removes the old text from the file
and stores the new bug report text at the end of the file instead. In this case
a new header item named "count" is automatically added to the new bug report
text which counts how often this specific exception has occurred.
|
| • |
HTTP upload functionality
|
|
Alternatively to using SMTP mailing you
can now upload bug reports via HTTP.
Optionally you can use authentication or/and add
custom HTTP fields.
The bug report itself is uploaded as a text file.
|
| • |
new attachment options
|
|
You can now at design time comfortably specify
additional attachments to be sent with
each bug report. Some or all attachment files can now optionally be
zipped. You can choose which files shall
be zipped into which zip archives. You also have full control over all file and
zip names etc...
By default the bug report is now sent as a text file attachment and no longer
in the mail body (except when using "mailto" mailing, since that doesn't
support attachments). This change was done for several reasons. One is HTTP
uploading, another one is that putting the bug report into the mail body made
problems with some mail clients (which broke the format). Just another reason
is that the attachment solution introduces the option to register a specific
file extension for the bug report - which is not used right now by default,
though. If you still prefer the old solution of mailing the bug report in the
mail body, you can reenable that solution by specifiying
%bugReport% as the mail body text.
|
| • |
madExcept configuration dialog
|
|
There's a new global (project independent)
madExcept configuration dialog now
available in Delphi's "Tools" menu. It offers you the possibility to configure
how the madExcept IDE wizard behaves.
|
| • |
additional exception context information
|
|
You can now ask where the exception was caught, and depending on that there
might be context related information available. E.g. when an exception is
caught during TThread.Execute you can get the
related TThread object.
Or when an exception was caught during dynamically loading a package, you can
ask which package the
program tried to load etc...
|
| • |
send & please wait progress boxes
|
|
A nice little box with an icon and a progress bar is now shown during SMTP
mailing and HTTP uploading, displaying the different phases of sending (the
strings can be customized/translated, of
course). A similar box is also shown if madExcept is busy with calculating the
bug report, but if (for some reason) the exception box is not visible at that
time. This happens rarely only, but it can happen, e.g. if an exception occurs
during the initialization/finalization of a dll.
|
| • |
no own settings for some modules
|
|
The new feature
basic settings -> this module gets no own
madExcept setings allows you to build an application which has all
madExcept settings stored in the executable file. All further dlls and bpls
can then be compiled without madExcept settings stored in - although being
compiled with madExcept enabled. These modules will then automatically find
and use the settings stored in the executable.
Of course you can still store settings for the dlls/bpls, too, if you like.
madExcept then automatically for each exception chooses those settings which
are stored in the module, in which the exception occurred. This way you can
e.g. realize different email addresses for bug report mailing, depending on
in which module the exception ocurred.
|
| • |
limit screen shot to our own app windows
|
|
If you like you can tell madExcept to only
include windows of our own app into the screenshot. All parts of the screen
not being covered by our windows are then simply white boxed.
|
| • |
bug report sending in background thread
|
|
madExcept can now send the bug report in a
background thread. So the end user can continue using your program while
the bug report is being sent to you. The progress window is shown in the bottom
right corner of the screen in this mode.
|
| • |
auto save only if bug report doesn't get sent
|
|
The bug report is now by default only
automatically saved, if the end user
doesn't manually send the bug report to you. I think this makes a lot of sense
in most situations, because why saving the bug report, if you got it via mail,
anyway?
|
| • |
include minimal debug info only
|
|
When activating the feature include minimal
debug info only, madExcept no longer stores the function names and line
number information into your exe. This way reverse engineers don't profit from
madExcept any longer. However, the bug reports given out by madExcept in this
mode are not of much use in raw form. In a later build I'll add a tool which
will be able to convert such raw reports into full bug reports by feeding the
tool with the original full map files.
|
| • |
cpu registers & stack dump
|
|
madExcept now shows which state the CPU
registers had when the exception was raised. Also a
stack dump is added to the bug report.
(Of course you can turn it all off, if you don't like it).
|
| • |
support for UPX and Shrinker
|
|
Both UPX and Shrinker modify the PE image header and do not undo these changes
even after compression in memory! I consider that a bug. But since the UPX
guys didn't even respond to me, I've now added support for this strange
behaviour to madExcept. Actually madExcept now repairs what UPX and Shrinker
forgot to do.
|
| • |
out of memory protection
|
|
madExcept now preallocates 2MB of memory during initialization. Plus it
reserves 16MB of address range (reserving doesn't consume memory). If an
exception is raised, madExcept frees all that, so that it can safely do its
work, without running into memory problems. After the exception handling is
done, madExcept tries to restore the preallocations & prereservations.
|
| • |
safecall exception handling
|
|
In the old madExcept builds and versions there was an (undocumented) function
named "HookSafeCallExceptions". The reason for this was that the Borland logic
of catching safecall exceptions in "TObject.SafeCallException" didn't work for
access violations. I've now removed that undocumented function
"HookSafeCallExceptions" and instead I'm now (during madExcept initialization)
simply patching the RTL so that the mentioned RTL bug is gone.
|
| • |
list of running processes
|
|
You can now ask madExcept to add a list of
running processes to the bug report, with priorities, process ids and
session ids.
|
| • |
new icons, now adjustable
|
|
There are new default icons for the exception
box buttons. Also there is now a big icon for the exception box and for the
progress boxes. All icons can be
customized at design time.
|
| • |
pausing exception catching
|
|
You can now pause madExcept's
automatic exception catching powers. Please use it wisely, though.
|
| • |
"mail bug report" -> "send bug report"
|
|
Since HTTP uploading was added, the text
"mail bug report" didn't really fit, anymore. So I've renamed a lot of things
from "mail" to the more general "send".
|
| • |
check whether binary file is corrupt (via crc)
|
|
If turned on, madExcept checks whether the
binary file contains bit faults (via a checksum stored in the PE header).
If the checksum check fails, a message box is shown and the process is
terminated.
|