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.

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...

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

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.

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...

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
news07A81C8-E0D7-4FE2-AE32-679E980BD5B6@microsoft.com...

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

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: