dev.emsdn.com

I have an app which is loading a 3rd party DLL. The DLL is causing an
access violation in certain circumstances. The DLL cannot be modified
and fixed so I was wondering and hoping if there is some way to ignore
the AV error so it doesn't popup a windows error dialog.
I can't use tryexcept in my code because the error occurs while the
DLL is doing it's own thing, not when I'm calling a function directly in
the DLL, so there is no where to put the tryexcept encapulation.
The debugger can catch the error so there must be some way to get around
it. I've tried a TAException event but this is not being
triggered.
Any ideas?
Delphi mailing list -Delphi (AT) elists (DOT) org

How are you linking in the dll, are you dynamically loading the dll on
the fly, or do you have it statically linked? If you are loading
dynamically you should be able to use the tryexcept in your code. If
you load it statically then you really cant trap any errors generated by
the dll unless it is around the calling procedure/function.

Regards
Martin.

Ross Levis wrote:

>I have an app which is loading a 3rd party DLL. The DLL is causing an
>access violation in certain circumstances. The DLL cannot be modified
>and fixed so I was wondering and hoping if there is some way to ignore
>the AV error so it doesn't popup a windows error dialog.
>
>I can't use tryexcept in my code because the error occurs while the
>DLL is doing it's own thing, not when I'm calling a function directly in
>the DLL, so there is no where to put the tryexcept encapulation.
>
>The debugger can catch the error so there must be some way to get around
>it. I've tried a TAException event but this is not being
>triggered.
>
>Any ideas?
>
>
>Delphi mailing list -Delphi (AT) elists (DOT) org
>
>

Delphi mailing list -Delphi (AT) elists (DOT) org

The DLL is being loaded dynamically but in a static kind of way. It
stays loaded for a long time and sits there doing it's thing. It's
while it's doing it's own thing, not interacting with my app, that an AV
can occur. I believe the DLL uses a separate thread to perform some
activities. The AV occurs just after it's finished doing what it needs
to do, so I don't need the DLL to continue at that stage; I can unload
it, but I was hoping to be able to stop the AV appearing to the user.

The Delphi (7) debugger is able to trap the error and display the memory
address where it's jumping to, so I thought perhaps there is a way for
my app to trap it as well.

Ross.

Message
From: "Martin" <marty_one (AT) internode (DOT) on.net>
To: "Borland's Delphi Discussion List" <delphi (AT) elists (DOT) org>
Sent: Thursday, 13, 2005 1:17 PM
Subject: Re: Ignoring AV errors in DLL's

How are you linking in the dll, are you dynamically loading the dll on
the fly, or do you have it statically linked? If you are loading
dynamically you should be able to use the tryexcept in your code. If
you load it statically then you really cant trap any errors generated by
the dll unless it is around the calling procedure/function.

Regards
Martin.

Ross Levis wrote:

>I have an app which is loading a 3rd party DLL. The DLL is causing an
>access violation in certain circumstances. The DLL cannot be modified
>and fixed so I was wondering and hoping if there is some way to ignore
>the AV error so it doesn't popup a windows error dialog.
>
>I can't use tryexcept in my code because the error occurs while the
>DLL is doing it's own thing, not when I'm calling a function directly
>in
>the DLL, so there is no where to put the tryexcept encapulation.
>
>The debugger can catch the error so there must be some way to get
>around
>it. I've tried a TAException event but this is not being
>triggered.
>
>Any ideas?

Delphi mailing list -Delphi (AT) elists (DOT) org

When a exception is raised, operating system code starts looking for some
code to handle that exceptions. The S looks for this code using a structure
similar to a stack frame created somwhere else (I think it creates a
linked-list of pointers, with the top of the list at FS:[0]). If it gets to
the bottom of the list and there's no handler, it calls something that's
called the default exception handler. Generally this handler is set by
Windows and is the one that displays the error message.

The good news: SetUnhandledExceptionFilter!

I used this method to change the behaviour of one of my applications so
Windows would not "eat" certain fatal error messages and turn them into the
"send/don't send" message!

Unfortunatelly I do not know if this proc works on a app-by-app or on
thread-by-thread bases. I also have VERY little info on how to actually use
it (I've got a VERY confusing comment next to it in my own app!)

Ross Levis wrote:
The DLL is being loaded dynamically but in a static kind of way. It
stays loaded for a long time and sits there doing it's thing. It's
while it's doing it's own thing, not interacting with my app, that an
AV can occur. I believe the DLL uses a separate thread to perform
some activities. The AV occurs just after it's finished doing what
it needs to do, so I don't need the DLL to continue at that stage; I
can unload it, but I was hoping to be able to stop the AV appearing
to the user.

The Delphi (7) debugger is able to trap the error and display the
memory address where it's jumping to, so I thought perhaps there is a
way for my app to trap it as well.

Ross.

Message
From: "Martin" <marty_one (AT) internode (DOT) on.net>
To: "Borland's Delphi Discussion List" <delphi (AT) elists (DOT) org>
Sent: Thursday, 13, 2005 1:17 PM
Subject: Re: Ignoring AV errors in DLL's
--
How are you linking in the dll, are you dynamically loading the dll on
the fly, or do you have it statically linked? If you are loading
dynamically you should be able to use the tryexcept in your code. If
you load it statically then you really cant trap any errors generated
by the dll unless it is around the calling procedure/function.

Regards
Martin.

Ross Levis wrote:
>
>I have an app which is loading a 3rd party DLL. The DLL is causing
>an access violation in certain circumstances. The DLL cannot be
>modified and fixed so I was wondering and hoping if there is some
>way to ignore the AV error so it doesn't popup a windows error
>dialog.
>>
>I can't use tryexcept in my code because the error occurs while
>the DLL is doing it's own thing, not when I'm calling a function
>directly in
>the DLL, so there is no where to put the tryexcept encapulation.
>>
>The debugger can catch the error so there must be some way to get
>around
>it. I've tried a TAException event but this is not
>being triggered.
>>
>Any ideas?
>

Delphi mailing list -Delphi (AT) elists (DOT) org

Delphi mailing list -Delphi (AT) elists (DOT) org

Hi Cosmin

This seems to work great.

function ExceptionFilter(ExceptionPointers: TExceptionPointers):
LongInt;
begin
Result := $ffffffff;
end;

SetUnhandledExceptionFilter(@ExceptionFilter);

No AV error is produced and the program continues on as usual. I'm now
wondering if ExceptionPointers provides some information on the details
of the error.

Many thanks,
Ross.

Message
From: "Cosmin Prund" <pcosmin (AT) adicomsoft (DOT) ro>
To: "Borland's Delphi Discussion List" <delphi (AT) elists (DOT) org>
Sent: Thursday, 13, 2005 9:46 PM
Subject: Re: Ignoring AV errors in DLL's

When a exception is raised, operating system code starts looking for
some
code to handle that exceptions. The S looks for this code using a
structure
similar to a stack frame created somwhere else (I think it creates a
linked-list of pointers, with the top of the list at FS:[0]). If it gets
to
the bottom of the list and there's no handler, it calls something that's
called the default exception handler. Generally this handler is set by
Windows and is the one that displays the error message.

The good news: SetUnhandledExceptionFilter!

I used this method to change the behaviour of one of my applications so
Windows would not "eat" certain fatal error messages and turn them into
the
"send/don't send" message!

Unfortunatelly I do not know if this proc works on a app-by-app or on
thread-by-thread bases. I also have VERY little info on how to actually
use
it (I've got a VERY confusing comment next to it in my own app!)

Ross Levis wrote:
The DLL is being loaded dynamically but in a static kind of way. It
stays loaded for a long time and sits there doing it's thing. It's
while it's doing it's own thing, not interacting with my app, that an
AV can occur. I believe the DLL uses a separate thread to perform
some activities. The AV occurs just after it's finished doing what
it needs to do, so I don't need the DLL to continue at that stage; I
can unload it, but I was hoping to be able to stop the AV appearing
to the user.

The Delphi (7) debugger is able to trap the error and display the
memory address where it's jumping to, so I thought perhaps there is a
way for my app to trap it as well.

Ross.

Message
From: "Martin" <marty_one (AT) internode (DOT) on.net>
To: "Borland's Delphi Discussion List" <delphi (AT) elists (DOT) org>
Sent: Thursday, 13, 2005 1:17 PM
Subject: Re: Ignoring AV errors in DLL's
--
How are you linking in the dll, are you dynamically loading the dll on
the fly, or do you have it statically linked? If you are loading
dynamically you should be able to use the tryexcept in your code. If
you load it statically then you really cant trap any errors generated
by the dll unless it is around the calling procedure/function.

Regards
Martin.

Ross Levis wrote:
>
>I have an app which is loading a 3rd party DLL. The DLL is causing
>an access violation in certain circumstances. The DLL cannot be
>modified and fixed so I was wondering and hoping if there is some
>way to ignore the AV error so it doesn't popup a windows error
>dialog.
>>
>I can't use tryexcept in my code because the error occurs while
>the DLL is doing it's own thing, not when I'm calling a function
>directly in
>the DLL, so there is no where to put the tryexcept encapulation.
>>
>The debugger can catch the error so there must be some way to get
>around
>it. I've tried a TAException event but this is not
>being triggered.
>>
>Any ideas?

Delphi mailing list -Delphi (AT) elists (DOT) org

Hi Rob

The named constant for that return value is
Exception_Continue_Execution

Yes, I tried that first but D7 doesn't appear to have it defined.

And remember that this function needs to be a stdcall function.

I should have realized that but I failed to add stdcall to the function.

Its parameter should be a _pointer_ to a TExceptionPointers record.

I didn't notice that either. I will declare a type PExceptionPointers =
^TExceptionPointers and use that in the function.

Thanks,
Ross.

Delphi mailing list -Delphi (AT) elists (DOT) org