When I generate a kernel memory dump from a xen core dump, the resulting dump is always bigger than what Windows would itself generate, and I’m curious as to why.
To determine which pages I need in the dump I’m traversing the PTE tables to see which pages are mapped for the kernel process, so I’m assuming that Windows has additional information about mapped pages that aren’t actually in use, and I’m wondering if I could get at that information.
If I free a block of memory from nonpaged pool, does Windows unmap it, or keep it mapped for performance reasons? If the latter, can I get at the list of unmapped pages in a way that is not too fragile?
It’s not really that much of a big deal… even when my memory.dmp is nearly 2x the size of the one Windows would generate, it’s still less than 10% of what a full memory dump would be so it still eases the burden on my download link. I’m still curious though.
Thanks
James
Note that PTEs can map either physical memory or device memory. So the
display has an immense number of pages mapped which represent its memory
buffer. So you should check the physical addresses to make sure they are
in the range of your RAM and not include those which map device memory.
Don’t know if this is the issue, because you give little detail, but from
what I’ve seen, I’m guessing that might be the problem.
joe
When I generate a kernel memory dump from a xen core dump, the resulting
dump is always bigger than what Windows would itself generate, and I’m
curious as to why.
To determine which pages I need in the dump I’m traversing the PTE tables
to see which pages are mapped for the kernel process, so I’m assuming that
Windows has additional information about mapped pages that aren’t actually
in use, and I’m wondering if I could get at that information.
If I free a block of memory from nonpaged pool, does Windows unmap it, or
keep it mapped for performance reasons? If the latter, can I get at the
list of unmapped pages in a way that is not too fragile?
It’s not really that much of a big deal… even when my memory.dmp is
nearly 2x the size of the one Windows would generate, it’s still less than
10% of what a full memory dump would be so it still eases the burden on my
download link. I’m still curious though.
Thanks
James
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
Most of this difference is likely due to system cache mappings and unused portions of the initial nonpaged pool, both of which are excluded from OS-created kernel dumps.
I don’t think there is a supported way for you to find and exclude these ranges though.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Monday, September 24, 2012 4:11 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] unallocated physical pages
When I generate a kernel memory dump from a xen core dump, the resulting dump is always bigger than what Windows would itself generate, and I’m curious as to why.
To determine which pages I need in the dump I’m traversing the PTE tables to see which pages are mapped for the kernel process, so I’m assuming that Windows has additional information about mapped pages that aren’t actually in use, and I’m wondering if I could get at that information.
If I free a block of memory from nonpaged pool, does Windows unmap it, or keep it mapped for performance reasons? If the latter, can I get at the list of unmapped pages in a way that is not too fragile?
It’s not really that much of a big deal… even when my memory.dmp is nearly 2x the size of the one Windows would generate, it’s still less than 10% of what a full memory dump would be so it still eases the burden on my download link. I’m still curious though.
>
Note that PTEs can map either physical memory or device memory. So the
display has an immense number of pages mapped which represent its
memory buffer. So you should check the physical addresses to make sure
they are in the range of your RAM and not include those which map device
memory.
Don’t know if this is the issue, because you give little detail, but from what
I’ve seen, I’m guessing that might be the problem.
Before I put a check for “if (pfn > highest_pfn)” I was getting crashes due to out-of-bounds on my bitmap when I hit things like PCI registers, so I’ve already caught that one.
Thanks
James
James,
Before I put a check for “if (pfn > highest_pfn)” I was getting crashes
> > due to out-of-bounds on my bitmap when I hit things like PCI
registers,
> so I’ve already caught that one.
Thanks
James
You’re assuming that highest_pfn < 4 GiB, is that correct?
Regards,
George.