Vista certification - Errors to be handled by Windows Error Reporting

[Jeremi Reda]

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?

[Marco van de Voort]

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.

[Markus.Humm]

Hello,

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? ;-))

Greetings

Markus

[Chris Morgan]

Vista-certification isn't compulsory. If you don't agree
with it, you can still sell your programs as vista-compatible.

cheers,

Chris

[Andre Kaufmann]

Markus.Humm wrote:
> Hello,
>
> 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
>
> Markus

Andre

[Jeremi Reda]

"Marco van de Voort" <mar...@stack.nl> wrote in message
news:slrnfkj56g....@snail.stack.nl...

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?

[Graeme Geldenhuys]

Markus.Humm wrote:
> 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!

It's probably so that Microsoft has a better chance to steal even more
information about your system (installed hardware/software).

Regards,
- Graeme -

__________________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

[Gert de Boom]

Here is a link to a partly succesful attempt:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2123486&SiteID=1

Maybe it wil get you on the right track?

Gert

[Jim McKeeth]

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.

Is that what you were looking for?

--
-Jim McKeeth
www.DaviniciUnltd.com

[Jim McKeeth]

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.

Additionally

> function ReturnAddr: Pointer;
> asm
> MOV EAX,[EBP + 4]
> end;

+ 4 is wrong. I'm not going to figure out the right amount at this
moment, but +4 is wrong.

--
-Jim McKeeth
www.DavinciUnltd.com

[Jeremi Reda]

Thanks,

As you say, this does call the Windows Error Reporting screen and allows me
to send details to MS.

I'm not sure how I'd find the problem from the information that gets sent to
MS, but that's another problem.

Thanks

Jeremi

"Jim McKeeth" <j...@mckeeth.org> wrote in message
news:474b...@newsgroups.borland.com...

[Markus.Humm]

Hello,

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!

Greetings

Markus

[Jim McKeeth]

There were a number of issues with that code. I reworked it into a
much better solution:

http://www.davinciunltd.com/2007/11/crashing-like-vb/

You can download the code from there too.

Enjoy, and good luck!

--
-Jim McKeeth
www.DaviniciUnltd.com

[Dean Hill]

>There were a number of issues with that code. I reworked it into a
>much better solution:
>
>http://www.davinciunltd.com/2007/11/crashing-like-vb/

Only MS could get away with taking a dev environment tool problem and
converting it into a "feature".

---

Dean

--- posted by geoForum on http://delphi.newswhat.com

[Thaddy]

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.