GPF trapping

I am developing a Pocket PC application directly using Microsoft clarm.exe
compiler. Is there a way to trap GPFs so when they occur the application not
just simply exit without any GPF message ?

I have tried to use UnhandledExceptionFilter() but without success.

I really appreciate your help.

Lars

Lisa
Sat Jun 18 19:56:05 CDT 2005

Don't know anything about clarm.exe
But it's unclear to me if you DO or do NOT want to GPF errors to show?

Surely you only want to show them for debugging, because the aim should to
prevent the crash, not simply supress it.

"Lars" <lars@nowhere.com> wrote in message
news:OaVrOCCdFHA.1276@tk2msftngp13.phx.gbl...
>I am developing a Pocket PC application directly using Microsoft clarm.exe
>compiler. Is there a way to trap GPFs so when they occur the application
>not just simply exit without any GPF message ?
>
> I have tried to use UnhandledExceptionFilter() but without success.
>
> I really appreciate your help.
>
> Lars
>

Lars
Sun Jun 19 02:27:29 CDT 2005

Lisa,

clarm.exe is the Microsoft C/C++ compiler for Pocket PC (ARM compatible)
version.

What I want is to see an error for a GPF (as Windows on PC does), because I
have detected that when a GPF occurrs on Pocket PC, the application simply
quits without any error at all.

Lars

ctacke/>
Sun Jun 19 07:46:19 CDT 2005

GPFs will display a dialog if they happen in the primary thread. Worker
threads GPFs often will just exit silently. Lisa's comment applies in both
cases - you should be doing error trapping, not relying on the system to
show a dialog.

-Chris

"Lars" <lars@nowhere.com> wrote in message
news:eJdZpBKdFHA.2500@TK2MSFTNGP10.phx.gbl...
> Lisa,
>
> clarm.exe is the Microsoft C/C++ compiler for Pocket PC (ARM compatible)
> version.
>
> What I want is to see an error for a GPF (as Windows on PC does), because
> I have detected that when a GPF occurrs on Pocket PC, the application
> simply quits without any error at all.
>
> Lars
>

Lars
Sun Jun 19 13:31:10 CDT 2005

Chris,

> GPFs will display a dialog if they happen in the primary thread.

That is not what we get here. On the primary thread, application also exits
silently on a GPF, thus making quite difficult to know what is going on.

regards,

Lars

ctacke/>
Sun Jun 19 22:20:43 CDT 2005

You're still depending on some dialog from the system, which is really not a
good programming or debugging technique. Use exception handling.

-Chris


"Lars" <lars@nowhere.com> wrote in message
news:u1fZh0PdFHA.3880@tk2msftngp13.phx.gbl...
> Chris,
>
>> GPFs will display a dialog if they happen in the primary thread.
>
> That is not what we get here. On the primary thread, application also
> exits silently on a GPF, thus making quite difficult to know what is going
> on.
>
> regards,
>
> Lars
>

Lars
Mon Jun 20 02:17:14 CDT 2005

Chris,

> You're still depending on some dialog from the system, which is really not
> a good programming or debugging technique. Use exception handling.

Yes, you are right, though the problem is that I have to use C source code.

I can't have exception handling on C language as far as I know.

regards,

Lars

ctacke/>
Mon Jun 20 06:13:37 CDT 2005

Look in help under __try and __except

-Chris


"Lars" <lars@nowhere.com> wrote in message
news:%236MsmgWdFHA.3052@TK2MSFTNGP10.phx.gbl...
> Chris,
>
>> You're still depending on some dialog from the system, which is really
>> not a good programming or debugging technique. Use exception handling.
>
> Yes, you are right, though the problem is that I have to use C source
> code.
>
> I can't have exception handling on C language as far as I know.
>
> regards,
>
> Lars
>

Lars
Mon Jun 20 11:30:25 CDT 2005

Chris,

> Look in help under __try and __except

Thanks a lot! Exactly what I needed :-)

regards,

Lars