To understand this bugcheck code, it’s first necessary to understand what a "page fault" is. If you’re not completely sure you understand this concept, read the article So, Exactly What Is A Page Fault here at OSR Online.

The Windows Memory Manager reserves pre-defined ranges of kernel virtual address space for specific uses. Because the Windows operating system utilizes virtual memory, the Memory Manager does not necessarily assign physical memory to every possible kernel virtual address within its pre-defined ranges. The Memory Manager knows that some of its kernel virtual address ranges are used for pageable memory, and other ranges are used for non-pageable memory. For example, the kernel virtual address space that is reserved for use by the non-paged pool is (obviously) part of one of the Memory Manager’s non-pageable address spaces.

Whenever the Memory Manager detects a page fault (that is, a failure to translate a kernel virtual address to a physical address) in one of its pre-assigned address ranges in which the memory is supposed to be non-pageable, it halts system execution with a PAGE_FAULT_IN_NONPAGED_AREA bugcheck.

The only thing that can cause one of these page faults is an inadvertent reference by a kernel mode component to an invalid memory address that just happens to correspond to one of the Memory Manager’s pre-assigned non-pageable address ranges. The most common reason for this bugcheck is a driver de-referencing a bad pointer.

There are basically innumerable things that can happen that can lead to an invalid memory access, so tracking down these bugchecks can sometimes be particularly difficult. Some of the most common reasons for these bugchecks are buffer overruns and underruns, or accessing of a completely bogus address.

When analyzing these crash dumps, it is either immediately obvious who caused the problem or it can take some serious detective work. The bugcheck parameters for this particular code are the invalid address that was accessed, whether the access was a read or a write, and the address of the instruction that caused the invalid access. Here are some things to think about when analyzing these dumps:

1) Why is the address bad?

a) Was it previously freed? The !pool WinDBG command can be helpful in determining this.

b) Is this potentially a buffer underrun? A buffer overrun? To determine this, you will need to look at how the address is being used. If, for example, the address is being used in a copy operation, starting your analysis believing it to be a buffer overrun might not be a bad assumption (but just don’t forget that it might not be the right assumption!).

c) Is the address just completely bogus? The !pool command is also useful here, as is the !pte command

2) Where did the address being accessed come from?

3) At which point did the address become bad? Was it previously used successfully by another component?

Using the information gathered from the above steps you can usually begin to get a better idea as to where things went wrong.

Using Driver Verifier and the checked build of Windows should allow you to better pinpoint the offending driver in the system. If the driver is not a driver that you have any control over, the only available option is disabling the driver until a fixed version is available.

Here’s an example that puts the above guidelines to use and tracks down a misbehaving driver. For clarity, the WinDBG output in this example has been stripped down to the parts important to our discussion.

OK, so our system bugchecked because we tried to read address 0xFF8B6000, presumably while trying to complete an IRP_MJ_QUERY_VOLUME_INFORMATION IRP. The address looks reasonable and the bugcheck info is telling me that the address is in the nonpaged address space, so let’s see what the debugger says about the address:

That wasn’t much help, but because the !pool command didn’t tell me that the address had been freed, I’m going to assume that we’re not dealing with a memory access to freed pool. This may be a completely invalid assumption, but it allows me to move on for the moment.

The page table entry for the nonpaged address that we accessed is invalid, which is why the system bugchecked. The faulting IP from the bugcheck info is a rep movsd instruction, which is a copy instruction on the x86. So, I’m going to assume for the time being that this bugcheck occurred because of a buffer overrun. With that info in hand, I can move on to step two and figure out where the address came from.

Looking in the DDK documentation, I see that IRP_MJ_QUERY_VOLUME_INFORMATION IRPs all use METHOD_BUFFERED. Therefore, when I find the IRP that is being completed here, its data buffer is going to be at Irp->AssociatedIrp.SystemBuffer. Now, unfortunately, the last two calls on the call stack that I’ve been given aren’t documented. This means that I have no idea what their parameters are and so I have no idea where to find the IRP. Because of that, I have to find the IRP the hard way. Dumping all of the memory contents starting at the last frame’s EBP (0xBED4EC7C) and executing the !irp command on anything that looks like an IRP eventually leads to success:

That system buffer address looks awfully suspect in terms of the address that generated the blue screen, so let’s see what we can find out about it:

I can see here that the allocation that the system buffer address lies in is valid from 0xFF8B5FE0 up to but not including 0xFF8B6000, the address that killed us. Taking a look at the completion status of the IRP:

Aha! The offending driver in this case has returned STATUS_BUFFER_OVERFLOW with the Information field set to the number of bytes needed to complete this request. Unfortunately, what this driver writer didn’t realize was that STATUS_BUFFER_OVERFLOW is simply an informational message and the I/O Manager will go ahead and copy the number of bytes specified by Information out of the system buffer and into the user’s buffer (remember, these IRPs are all METHOD_BUFFERED). Note that these are not the same semantics that you get when returning the error code STATUS_BUFFER_TOO_SMALL, which is what the developer meant to return. If a driver completes an IRP with that code, the user is returned the number of bytes needed to complete the request but no data is copied.

So, because of this mishap, when the IRP was completed with IoCompleteRequest the I/O Manager attempted to copy 0x1C bytes of data starting at address 0xFF8B5FE8 into the user’s buffer, which led to a buffer overrun and a PAGE_FAULT_IN_NONPAGED_AREA bugcheck.