Dan Partelly wrote:
Pretty interesting.
The two problems you describe are remotely linked to each other.
What you could do here is:
- Dump the process VAD trees and see if what you think is contigous virtual
memory it
is really so. You say “using multiple sections”, and I dont really
understand what you mean.
Multiple subsequent calls to ZwMapView…() to map pieces of physicall
memory into
the address space contigous , one after another ? One impact of this is that
it would result in multiple VADs. Now as I see it, this indeed can cause
problems , (this is an educated guess,
but ill verify it in the debugger), since the OS might see that you give a
buffer which is bigger than the virtual memory described by the first walked
VAD which suposedly should describe user space virtual memory which contains
the whole buffer.
How is VAD tree dumped? Assuming win32 space the developer studio has no
such capability.
By “multiple sections” I mean this:
create a contiguous virtual memory range in a win32 process by using 2 or more
ZwMapViewOfSection() calls, nominating desired virtual address points in
user space and using physical memory adress ranges to satisfy this. Effectively
a contiguous virtual memory range is composed from chunks of physical memory.
This is similar to what NT virtual memory management does with 4K pages.
Effectively we have a ‘virtual’ memory management system that manages a pool
of memory, with min granularity of 128Kb.
Now, you say that multiple VADs are likely culprit but note following behavior:
We choose to manage portion of physical memory section in this exercise, yet
our implementation does not care whether memory section is from “PhysicalMemory”
or from a win32 unnamed file mapping object using CreateFileMapping() api.
The same exercise repeated with a win32 CreateFileMapping() object
does not have trouble with contiguous virtual memory range created from multiple
segments of file mapping.
Ultimately if I am able to paste together a virtual memory range from ‘bits’ of
file mapping then that range, given that I was allowed to create it, should be
usable in MmProbeAndLock operations, otherwise I must make sure that all
I/O and any operations that invoke MmProbeAndLock() are fully aware of
how the virtual memory range was constructed. This is a huge ask.
You may say, use Win32 file section but that is exactly what we have been
doing until we collided with NT memory management changes in Nt4SP6,
changes that are natural parto of Win2K and WinXP. So, we were forced
to resort to “PhysicalMemory” section access by reserving some with
/MAXMEM option. In the days of EISA based systems and NT3.51 we
actually had hardware that carried 128MB of memory on an EISA card
which we could manage as we are attempting to now with system ram,
and we had no trouble doing ReadFile/WriteFile.
Final item of information that may help you is that mapping that is being
done to create a virtual memory range may be done by process A for mapping
into process A but also it is done into any nominated process. Essentially,
process A is the ‘memory manager’ for several other processes.
Candidate virtual address range for a process is ‘picked’ by kernel driver
executing following two steps:
- Using ZwVirtualAlloc to allocate a full range of virtual memory in
designated process space. This provides a virtual address that may be
used.
- Free same virtual memory so that we can reuse same range for ZwMap…()
If by chance virtual memory got reallocated to some other thread then process is
repeated.
Our usage of undocumented api is forced because alternatives we have tried
are far inferior. We justify this decision by virtue of the fact our systems are
built in-house, on a specific, validated version of NT, and are thus under
our control. We are not likely to cause a headache for someone out there
that may try and install this on some future version of NT.
- Trace into MmProbeAndLockPages() and see where it faults. What im
interested here is mainly whatever the fault is in MmProbeAndLockPages() or
in any API (mainly if its inside MmAccessFault() or not) which
MmProbeAndLock() may call.
I will work towards this but it will take a little time.
If you provide me this information I would be happy to look into this
problem for you, yet
I dont think what you are trying to do is legal. Will see.
Ciao, Dan
–
Ned Kacavenda - Software Development
Colorbus Pty Ltd
1044 Dandenong Road Carnegie Victoria 3163 Australia
Direct +61 3 8574 8023, Main +61 3 8574 8000
Email: xxxxx@colorbus.com.au
web : http://www.colorbus.com http:</http:>