try/except does not catch all exceptions...?

I am trying to use __try/__except to catch crashes that may occur in my driver.
It works great for NULL pointer access, but not for a plain bad memory access.

If the driver accesses 0xfefefefe (just as a test!), I see a crash in
WinDbg, instead of my exception handler getting launched.

The crash is below. How do I catch it (and other exceptions) ?


PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or
it
is pointing at freed memory.
Arguments:
Arg1: fefefefe, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: b94ca75d, If non-zero, the instruction address which referenced the
bad memory
address.
Arg4: 00000000, (reserved)



/ Hannes.

Don
Fri Apr 22 11:31:59 CDT 2005

Right, there are a heck of a lot of faults that do not go SEH or any
catchable mechanism. You can't change this live with the fact that you
cannot catch the majority of BSOD's before the system invokes the crash
handlers.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply



"Hannes" <hannes.news@nospam.nospam> wrote in message
news:B116D89D-C221-46FC-B2CA-FD608DF2F62B@microsoft.com...
>I am trying to use __try/__except to catch crashes that may occur in my
>driver.
> It works great for NULL pointer access, but not for a plain bad memory
> access.
>
> If the driver accesses 0xfefefefe (just as a test!), I see a crash in
> WinDbg, instead of my exception handler getting launched.
>
> The crash is below. How do I catch it (and other exceptions) ?
>
>
> PAGE_FAULT_IN_NONPAGED_AREA (50)
> Invalid system memory was referenced. This cannot be protected by
> try-except,
> it must be protected by a Probe. Typically the address is just plain bad
> or
> it
> is pointing at freed memory.
> Arguments:
> Arg1: fefefefe, memory referenced.
> Arg2: 00000000, value 0 = read operation, 1 = write operation.
> Arg3: b94ca75d, If non-zero, the instruction address which referenced the
> bad memory
> address.
> Arg4: 00000000, (reserved)
>
>
>
> / Hannes.

hannes
Fri Apr 22 11:36:06 CDT 2005

After some more study, I see that this may be related to being at a bad IRQL
(too high), in which case the exception may not be caught by my handler.

I verified that the crash occurs at a point when the current IRQL is 0
(PASSIVE).

See code snippet below.

/ Hannes.

__try {
KIRQL irql = KeGetCurrentIrql();
DbgPrint("current irql = %d\n", irql);
int a;
a = *(UINT8*)0xfefefefe;
a++;
} __except(EXCEPTION_EXECUTE_HANDL­ER) {
DbgPrint("Handling exception\n");
PsTerminateSystemThread(0);
}

hannes
Fri Apr 22 11:53:01 CDT 2005

Our Windows XP system has to run without swap, and therefore can't rely on
Windows crachdumping.

I have written a beautiful exception handler, that generates proper WinDbg
dump files (directly to disk) - but it will only be innvoked for NULL pointer
exceptions, nothing else...?

Am I just plain out of luck here?

/ Hannes.

Alexander
Sat Apr 23 00:06:55 CDT 2005

Only page faults in the user address range can be caught. Access violations
in the kernel address range are causing BSOD.

"Hannes" <hannes.news@nospam.nospam> wrote in message
news:A38399A7-7AC2-459F-835C-062D09275FA7@microsoft.com...
> After some more study, I see that this may be related to being at a bad
> IRQL
> (too high), in which case the exception may not be caught by my handler.
>
> I verified that the crash occurs at a point when the current IRQL is 0
> (PASSIVE).
>
> See code snippet below.
>
> / Hannes.
>
> __try {
> KIRQL irql = KeGetCurrentIrql();
> DbgPrint("current irql = %d\n", irql);
> int a;
> a = *(UINT8*)0xfefefefe;
> a++;
> } __except(EXCEPTION_EXECUTE_HANDL-ER) {
> DbgPrint("Handling exception\n");
> PsTerminateSystemThread(0);
> }
>

Doron
Sat Apr 23 10:46:21 CDT 2005

you are out of luck here. if this were possible, bugchecks would be less
frequent (assuming that the kernel could resume to known & good state).

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Hannes" <hannes.news@nospam.nospam> wrote in message
news:D07A81C8-E0D7-4FE2-AE32-679E980BD5B6@microsoft.com...
> Our Windows XP system has to run without swap, and therefore can't rely on
> Windows crachdumping.
>
> I have written a beautiful exception handler, that generates proper WinDbg
> dump files (directly to disk) - but it will only be innvoked for NULL
> pointer
> exceptions, nothing else...?
>
> Am I just plain out of luck here?
>
> / Hannes.

Maxim
Sat Apr 23 18:55:11 CDT 2005

> Only page faults in the user address range can be caught. Access violations
> in the kernel address range are causing BSOD.

Yes.

If the faulting address is in the nonpaged range - then MmAccessFault BSODs.
Otherwise, it raises the 0xc000000d exception.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

pavel_a
Tue Apr 26 19:16:02 CDT 2005

In addition.... yes, IRQL must be < dispatch to use SEH,
because it needs a thread context.
At high IRQL, you can run on somebody else's stack.

--PA

"Hannes" wrote:
> After some more study, I see that this may be related to being at a bad IRQL
> (too high), in which case the exception may not be caught by my handler.
>
> I verified that the crash occurs at a point when the current IRQL is 0
> (PASSIVE).
>
> See code snippet below.
>
> / Hannes.
>
> __try {
> KIRQL irql = KeGetCurrentIrql();
> DbgPrint("current irql = %d\n", irql);
> int a;
> a = *(UINT8*)0xfefefefe;
> a++;
> } __except(EXCEPTION_EXECUTE_HANDL­ER) {
> DbgPrint("Handling exception\n");
> PsTerminateSystemThread(0);
> }
>