Windbg Message - "Page 3cab6f not present in the dump file"

jcgriff2

Co-Founder / Admin
BSOD Instructor/Expert
Microsoft MVP (Ret.)
Staff member
Joined
Feb 19, 2012
Posts
21,541
Location
New Jersey Shore
I've seen it before and, as I recall, it points to pages that aren't included in that kind of dump (I only recall seeing it in minidumps).
I'd presume that it would be present in a full dump, but have never bothered to check and see.

The other possibilities that I'd think of would be memory issues that corrupted that page, or a problem with the dump capturing process that would have corrupted that page.
 
Has anyone ever come upon a dump where Windbg gives the message "Page 3cab6f not present in the dump file." (memory address of course varies).

That message is from a thread at Windows Forums - WinDbg ignore missing pages! - Windows Forums

Be sure to click on the spoiler to see the Windbg output - "Spoiler: Debug Message".

I missed the spoiler in my initial reply post - WinDbg ignore missing pages! - Windows Forums

Thanks for the help!

John

I believe it's trying to display information which has been paged out to disk, which isn't available in a minidump.
Obviously with a Kernel memory dump or Full memory dump you're almost never going to see it because you'll have that information available.
 
I believe it's trying to display information which has been paged out to disk, which isn't available in a minidump.

Not particularly, as it would just show as invalid, pagefile: 0, and what offset in memory it's located at (as far as !pte goes). Here's my terrible one minute diagram:

Code:
proc # here: kd> !pte blah blah
                      VA blah blah
PDE at blah blah                    PTE at blah blah
contains blah blah                  contains blah blah
pfn blah blah         ------------     not valid
                                 PageFile: 0 < -- means we're off on the page file
                                 Offset: <-- location in memory on pagefile here
                                 Protect: blah blah

Rarely do you actually get !pte to dump anything in a small dump though as we know, you gotta get lucky.

@John, if you do a !pte 3cab6f, if the PXE and PPE are available, you'll be able to see the output + the fact that the page directory and page table are missing. If PEB is in fact missing, this implies that the debugger is trying to access the user portion of the address space, which obviously isn't in anything but a complete dump, so it 's displaying in text form that the page it's trying to access isn't present.
 
I believe it's trying to display information which has been paged out to disk, which isn't available in a minidump.

Not particularly, as it would just show as invalid, pagefile: 0, and what offset in memory it's located at (as far as !pte goes). Here's my terrible one minute diagram:

Code:
proc # here: kd> !pte blah blah
                      VA blah blah
PDE at blah blah                    PTE at blah blah
contains blah blah                  contains blah blah
pfn blah blah         ------------     not valid
                                 PageFile: 0 < -- means we're off on the page file
                                 Offset: <-- location in memory on pagefile here
                                 Protect: blah blah

Rarely do you actually get !pte to dump anything in a small dump though as we know, you gotta get lucky.

@John, if you do a !pte 3cab6f, if the PXE and PPE are available, you'll be able to see the output + the fact that the page directory and page table are missing. If PEB is in fact missing, this implies that the debugger is trying to access the user portion of the address space, which obviously isn't in anything but a complete dump, so it 's displaying in text form that the page it's trying to access isn't present.

Of course... My bad. I completely forgot and had a brain dead moment.
 
Last edited:
Why exactly would the PEB be missing imply that the debugger is trying to access user mode address space?

It doesn't particularly, good catch. My example is kind of confusing, sorry. It doesn't always have to be PEB that's paged out, and as you noted, it doesn't imply it's user mode either.

For example, if you ran !pte and saw:

Code:
PEB is paged out (Peb.Ldr = 000007ff`fffd6018).

then that would imply that it was in user address space. If it was fffff instead, it's kernel.
 
Why exactly would the PEB be missing imply that the debugger is trying to access user mode address space?

It doesn't particularly, good catch. My example is kind of confusing, sorry. It doesn't always have to be PEB that's paged out, and as you noted, it doesn't imply it's user mode either.

For example, if you ran !pte and saw:

Code:
PEB is paged out (Peb.Ldr = 000007ff`fffd6018).

then that would imply that it was in user address space. If it was fffff instead, it's kernel.

Well the PEB is the user mode portion of the process data structure. We don't really know what it does because it's an undocumented feature, which isn't surprising given that it's initialised by the native API, which is also undocumented. (Mostly).

The best way to work out whether it is user mode or Kernel mode, of course is to check the virtual address.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top