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. ----- Original Message ----- From: "Cosmin Prund" <[EMAIL PROTECTED]> To: "Borland's Delphi Discussion List" <[email protected]> Sent: Thursday, October 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 OS 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. > > ----- Original Message ----- > From: "Martin" <[EMAIL PROTECTED]> > To: "Borland's Delphi Discussion List" <[email protected]> > Sent: Thursday, October 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 try..except 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 try..except 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 try..except encapulation. >> >> The debugger can catch the error so there must be some way to get >> around >> it. I've tried a TApplication.OnException event but this is not >> being triggered. >> >> Any ideas? _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
