On 2007-11-25, Jeremi Reda <Jer...@reda.fsworld.co.uk> wrote:
> One of the requirements for Vista certification is,
> "If a fault (such as an Access Violation) is injected into an application, > the application must allow Windows Error Reporting to report this crash."
> I use Delphi 5 and any Access Violation is ultimately handled by the Delphi > exception handler which shows a simple message box.
> Is there any way to let the Access Violation fall through to the Windows > Error Reporting facility?
Don't know how, but I do know where, replace application.onexception handler. Maybe replacing it with an empty method will even propagate it to windows via SEH.
I think this MS requirement is just plain silly for Delphi developpers as e.g. MadExcept and others will give you a very usefull stacktracke in case of a exception which can be mailed directly to the developper where MS error reporting surely won't/can't interpret the Delphi stack etc. so it would only be able to record memory addresses and CPU state etc. but that's not too helpfull. And by using this Windows error reporting MS can possibly see all your problems because afaik their servers handle this. I'm not too fond of this. Requiring a decent error handling is justified but requiring one so tight coupled to MS is bad! (shouldn't somebody tell this the EU commission? ;-))
> I think this MS requirement is just plain silly for Delphi developpers as > e.g. MadExcept and others will give you a very usefull stacktracke in case > of a exception which can be mailed directly to the developper where MS > error reporting surely won't/can't interpret the Delphi stack etc. so it > would only be able to record memory addresses and CPU state etc. but > that's not too helpfull. And by using this Windows error reporting MS can > possibly see all your problems because afaik their servers handle this. > I'm not too fond of this. Requiring a decent error handling is justified > but requiring one so tight coupled to MS is bad! > (shouldn't somebody tell this the EU commission? ;-))
Vista-certification isn't compulsory. If you don't agree with it, you can still sell your programs as vista-compatible.
> I think this MS requirement is just plain silly for Delphi developpers > as e.g. MadExcept and others will give you a very usefull stacktracke in > case of a exception which can be mailed directly to the developper where > MS error reporting surely won't/can't interpret the Delphi stack etc. so > it would only be able to record memory addresses and CPU state etc. but > that's not too helpfull.
You at least can see the stack traces of exported functions. If Delphi could support the Microsoft debugging format (PDB) too you would see everything like variable content, thread states etc. at the crash. Additionally all the tools available for Intel or Microsoft products could be fully used with Delphi, e.g. profilers like VTune.
> And by using this Windows error reporting MS > can possibly see all your problems because afaik their servers handle > this.
You can download the reports of your own application from the Microsoft servers, if you have been registered. AFAIK Microsoft simply drops the reports of unregistered applications.
> I'm not too fond of this. Requiring a decent error handling is > justified but requiring one so tight coupled to MS is bad! > (shouldn't somebody tell this the EU commission? ;-)) > Greetings
> On 2007-11-25, Jeremi Reda <Jer...@reda.fsworld.co.uk> wrote: >> One of the requirements for Vista certification is,
>> "If a fault (such as an Access Violation) is injected into an >> application, >> the application must allow Windows Error Reporting to report this crash."
>> I use Delphi 5 and any Access Violation is ultimately handled by the >> Delphi >> exception handler which shows a simple message box.
>> Is there any way to let the Access Violation fall through to the Windows >> Error Reporting facility?
> Don't know how, but I do know where, replace application.onexception > handler. Maybe replacing it with an empty method will even propagate it to > windows via SEH.
I already use Application.OnException to do my own exception handling. Leaving this empty simply hides the exception.
I agree with the other comments about the need for this, but I am being forced down this road by my customer. Normally you can always find how to do things in Delphi, but I've been searching for days and can't find anything. Can anyone else help?
Jeremi Reda wrote: > I already use Application.OnException to do my own exception > handling. Leaving this empty simply hides the exception.
How about in your Application.OnException handler just putting
raise e;
It pops up in the IDE a few times, but it eventually pops out to the OS and kills the application just like a visual basic application.
If you wanted to be more creative you could use AcquireExceptionObject to increment the use count on the exception in Application.OnException and then save off the address and exception, terminate the application, and then raise the exception inside your dpr (after Application.Run). That seems to work to.
Here is the DPR code
------
begin GlobalException := nil; GlobalExceptionAddr := nil; Application.Initialize; Application.MainFormOnTaskbar := True; Application.CreateForm(TForm3, Form3); Application.Run; if assigned(GlobalException) then raise GlobalException at GlobalExceptionAddr; end.
-----
Declare your globals as
-----
var GlobalException: Exception; GlobalExceptionAddr: Pointer;
-----
And then your new Application.OnException handler
-----
procedure TForm3.ApplicationEvents1Exception(Sender: TObject; E: Exception); function ReturnAddr: Pointer; asm MOV EAX,[EBP + 4] end; begin GlobalExceptionAddr := ReturnAddr; GlobalException := E; AcquireExceptionObject; Application.Terminate; // Maybe set a flag first. . . end;
-----
Same result, a little more elegant and control.
I am presenting a session for CodeRage on Exceptions, although I didn't do this in the presentation. Would have been a good idea though I guess. I'll add the code to the download for the session though.
OK, so I am going to comment on my code before someone else does:
> var > GlobalException: Exception; > GlobalExceptionAddr: Pointer;
OK, so ideally those should be ThreadVar or in some other way made thread safe. Maybe you could just use ExceptObject instead. I might play with that more.
>> I already use Application.OnException to do my own exception >> handling. Leaving this empty simply hides the exception.
> How about in your Application.OnException handler just putting
> raise e;
> It pops up in the IDE a few times, but it eventually pops out to the OS > and kills the application just like a visual basic application.
> If you wanted to be more creative you could use AcquireExceptionObject > to increment the use count on the exception in Application.OnException > and then save off the address and exception, terminate the application, > and then raise the exception inside your dpr (after Application.Run). > That seems to work to.
> Here is the DPR code
> ------
> begin > GlobalException := nil; > GlobalExceptionAddr := nil; > Application.Initialize; > Application.MainFormOnTaskbar := True; > Application.CreateForm(TForm3, Form3); > Application.Run; > if assigned(GlobalException) then > raise GlobalException at GlobalExceptionAddr; > end.
> -----
> Declare your globals as
> -----
> var > GlobalException: Exception; > GlobalExceptionAddr: Pointer;
> -----
> And then your new Application.OnException handler
> -----
> procedure TForm3.ApplicationEvents1Exception(Sender: TObject; E: > Exception); > function ReturnAddr: Pointer; > asm > MOV EAX,[EBP + 4] > end; > begin > GlobalExceptionAddr := ReturnAddr; > GlobalException := E; > AcquireExceptionObject; > Application.Terminate; // Maybe set a flag first. . . > end;
> -----
> Same result, a little more elegant and control.
> I am presenting a session for CodeRage on Exceptions, although I didn't > do this in the presentation. Would have been a good idea though I > guess. I'll add the code to the download for the session though.
better use MadExcept or something like this... ...that's the reason why I'm against this MS requirement. They only see their solutions but not the needs of the user using their software!
You can assign your own exception procedure even lower in the code: If you assign such a proc to the RaiseExceptionProc variable (in system.pas) you can wreck all kinds of fun havoc.
