Differences between PAGE_FAULT_IN_NONPAGED_AREA and KERNEL_MODE_EXCEPTION_NOT_HANDLED

Hi

Can you please tell me the differences between

  • PAGE_FAULT_IN_NONPAGED_AREA

and

  • KERNEL_MODE_EXCEPTION_NOT_HANDLED with STATUS_ACCESS_VIOLATION?

I am asking this because;

  • For PAGE_FAULT_IN_NONPAGED_AREA , this link ( http://www.osronline.com/article.cfm?article=335 ) says that: “The most common reason for this bugcheck is a driver de-referencing a bad pointer.”

  • For KERNEL_MODE_EXCEPTION_NOT_HANDLED with STATUS_ACCESS_VIOLATION this link( http://www.osronline.com/article.cfm?id=49 ) says that: “As for STATUS_ ACCESS_VIOLATION, it almost always means a thread tried to dereference an uninitialized, NULL, or corrupted pointer.”

PAGE_FAULT_IN_NONPAGED_AREA means pretty much exactly what the bugcheck
code says. Its what you get if the page fault handler encounters a fault
in a region that should not have been paged out. For instance if you
happen to build an MDL to non-paged pool and then accidentally unmap the
memory from the MDL that is the bugcheck you are going to get. Nonpaged
pool should never page fault. There are other ways to arrive at this of
course, but that should give you the general idea.

The KERNEL_MODE_EXCEPTION_NOT_HANDLED STATUS_ACCESS_VIOLATION is more
general, and just means that you accessed an address that is simply invalid
(vs. its supposed to be valid).

t.

On Wed, Jul 18, 2012 at 1:23 PM, wrote:

> Hi
>
> Can you please tell me the differences between
> - PAGE_FAULT_IN_NONPAGED_AREA
>
> and
>
> - KERNEL_MODE_EXCEPTION_NOT_HANDLED with STATUS_ACCESS_VIOLATION?
>
> I am asking this because;
>
> - For PAGE_FAULT_IN_NONPAGED_AREA , this link (
> http://www.osronline.com/article.cfm?article=335 ) says that: “The most
> common reason for this bugcheck is a driver de-referencing a bad pointer.”
>
> - For KERNEL_MODE_EXCEPTION_NOT_HANDLED with STATUS_ACCESS_VIOLATION this
> link( http://www.osronline.com/article.cfm?id=49 ) says that: “As for
> STATUS_ ACCESS_VIOLATION, it almost always means a thread tried to
> dereference an uninitialized, NULL, or corrupted pointer.”
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

PAGE_FAULT_IN_NONPAGED_AREA bugchecks always indicates an invalid kernel
reference to kernel memory (though not all invalid kernel memory references
result in this bugcheck). While servicing the page fault, the page fault
handler will determine that the kernel address is bogus and crash the system
(what else could it do?).

KERNEL_MODE_EXCEPTION_NOT_HANDLED with STATUS_ACCESS_VIOLATION is slightly
different. The bugcheck code itself means that a structured exception was
raised in kernel mode (e.g. ExRaiseStatus) and no registered structured
exception handler caught the exception. Thus, the exception made it back to
the default exception handler, which simply bugchecks the system with the
NTSTATUS value passed to ExRaiseStatus.

Exceptions are raised for all sorts of reasons in the O/S, so it’s fairly
common to get a KERNEL_MODE_EXCEPTION_NOT_HANDLED bugcheck (for amusement
you can even generate your own by calling ExRaiseStatus without an exception
handler). However, the quote you cited is speaking specifically to fact that
exceptions are raised by the page fault handler as a result of references to
invalid *user* memory. That is to say, references to invalid memory in the
low 2GB (or 8TB) of the addressing space.

So, if I dereference an invalid user address from my driver, the page fault
handler will execute. The page fault handler looks at the faulting address,
determines that it falls within the user portion of the address space, and
calls ExRaiseStatus(STATUS_ACCESS_VIOLATION). If my driver wraps the user
mode access in an exception handler, I can catch the exception and return an
error to the user. If I fail to wrap the access in an exception handler,
I’ll get a KERNEL_MODE_EXCEPTION_NOT_HANDLED/STATUS_ACCESS_VIOLATION
bugcheck. Note that due to the fact that the NULL value happens to be in the
low part of the addressing space exceptions are also raised on NULL pointer
dereferences (assuming that you’re < DISPATCH_LEVEL).

Finally, just for completeness, it is possible for an access violation to
also be raised for some kernel addresses. This is far more rare in my
experience, but worth keeping in mind in case you see it.

-scott


Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…

Hi

Can you please tell me the differences between

  • PAGE_FAULT_IN_NONPAGED_AREA

and

  • KERNEL_MODE_EXCEPTION_NOT_HANDLED with STATUS_ACCESS_VIOLATION?

I am asking this because;

  • For PAGE_FAULT_IN_NONPAGED_AREA , this link (
    http://www.osronline.com/article.cfm?article=335 ) says that: “The most
    common reason for this bugcheck is a driver de-referencing a bad pointer.”

  • For KERNEL_MODE_EXCEPTION_NOT_HANDLED with STATUS_ACCESS_VIOLATION this
    link( http://www.osronline.com/article.cfm?id=49 ) says that: “As for
    STATUS_ ACCESS_VIOLATION, it almost always means a thread tried to
    dereference an uninitialized, NULL, or corrupted pointer.”

Thank you all…

> Can you please tell me the differences between

  • PAGE_FAULT_IN_NONPAGED_AREA

and

  • KERNEL_MODE_EXCEPTION_NOT_HANDLED with STATUS_ACCESS_VIOLATION?

You get first for invalid nonpaged memory pointer, and second for any other junk pointer.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

> Finally, just for completeness, it is possible for an access violation to

also be raised for some kernel addresses.

Trivial. If the junk pointer value points to paged pool - this occurs.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Junk pointers in kmode cause:

IRQL_NOT_LESS_OR_EQUAL on DISPATCH_LEVEL and higher
otherwise, PAGE_FAULT_IN_NONPAGED_AREA if the junk pointer value happened to be in nonpaged address range.
otherwise, KERNEL_MODE_EXCEPTION_NOT_HANDLED/STATUS_ACCESS_VIOLATION

They all have the same cause: junk pointer.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

>> Finally, just for completeness, it is possible for an access

> violation to also be raised for some kernel addresses.

Trivial. If the junk pointer value points to paged pool - this occurs.

Not true. Invalid paged pool references (e.g. use-after-free where the entire page has been freed and its PTE is now invalid) generate PAGE_FAULT_IN_NONPAGED_AREA bugchecks, just like invalid non-paged pool references.

“Maxim S. Shatskih” wrote in message news:xxxxx@ntdev…

Trivial. If the junk pointer value points to paged pool - this occurs.

I think you’re interpreting the bugcheck code too literally, you still get a
page fault in non-paged area in this case. What would raising an exception
even mean here? Who would be responsible for catching the exception and
handling it?

-scott


Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Maxim S. Shatskih” wrote in message news:xxxxx@ntdev…

Finally, just for completeness, it is possible for an access violation to
also be raised for some kernel addresses.

Trivial. If the junk pointer value points to paged pool - this occurs.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com