Let's look at a little demo, consisting of one tiny application and an even
tinier DLL. The application's project file looks like this:
|
program CrashApp;
uses
madExcept,
madLinkDisAsm,
Forms,
CrashUnit in 'CrashUnit.pas' ;
*.
begin
Application.Initialize;
Application.CreateForm(TCrashForm, CrashForm);
Application.Run;
end.
|
|
As you can see, there's nothing to speak about, just one unit with a form.
The unit looks like this:
|
unit CrashUnit;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls;
type
TCrashForm = class(TForm)
CrashButton: TButton;
procedure CrashButtonClick(Sender: TObject);
private
-
public
-
end;
var
CrashForm: TCrashForm;
implementation
*.
procedure CrashDllProc; external 'crashDll.dll';
procedure CrashProc;
begin
CrashDllProc;
end;
procedure TCrashForm.CrashButtonClick(Sender: TObject);
begin
CrashProc;
end;
end.
|
|
You can see that we have one button, which when being clicked
on calls a function in our DLL. Furthermore we've enabled madExcept
support for our project in the madExcept settings dialog, which
results in "madExcept" and "madLinkDisAsm" being automatically added to the
project's uses clause. That's all. Now let's see how the DLL looks like:
|
library CrashDll;
uses madExcept, madLinkDisAsm, SysUtils;
*.
procedure CrashDllProc;
begin
integer(nil^) := 0;
end;
exports CrashDllProc;
end.
|
|
The DLL does nothing but export one function, which raises an access
violation, when being called. Okay, now let's compile both projects, run the
application, press the button and see what happens. Point the mouse at the
tabs of the window to see the contents of the other tabs.
If we follow the call stack from the bottom to the top we begin with line 14
in the project, which is the line "Application.Run". The next stack item in
our own sources is the line in "TCrashForm.CrashButtonClick", where the
"CrashProc" is called. In between we can follow the way in which the code
walked from the message loop in "Application.Run" to our button click event
handler. Okay, the next stack item in our sources is the line in "CrashProc",
where the function from the DLL is called. Finally we're reaching the real
exception location, which is inside of the DLL.
This demo is very short and easy just to give you a first idea of how
madExcept works. If you want to see a more detailed and complicated
demo, please look in the "Demos" folder of your madExcept installation or
directly download the
ExcCatch demo.