Sharing memory between user mode and a device driver
harold
I have two user mode(Win32) program. One user mode program need to share
another's memory(Buffer)
For performance and other reasons, I can not use Win32 API
"MapFileView" to share memory. I need Kernel mode driver. The following
is what I did:
1. Use IOCTL (Method = Buffered) to pass the address of the Buffer to
Kernel mode driver.
Note: above line is in Dispatch routine.
2. Then do Mdl = IoAllocateMdl(Buffer, BufferSize, FALSE, FALSE, NULL);
MmProbeAndLockPages(Mdl, KernelMode, IoModifyAccess);
3. Then second user mode program try to use IOCTL to pick up UserAddress
as follows:
UserAddress = MmMapLockedPages(Mdl, UserMode);
But this line cause the NT crash. the dumped message say "IRQL not
less or equal"
I check the IRQL of MmMapLockedPages(UserMode), It run below ( < )
Dispatch level.
But WinNT DDK say the IRQL of Dispatch routine is less than Dispatch
level. I also search
all the newsgroup about this topic, some example suggest to use above
call under IOCTL.
Did I do sth wrong? I also try to put MmMapLockedPages under
(IRP_MJ_CREATE).
It is not crash. But still cause problem. How should I do?
Any suggestion will be greatly appreciated!!
Harold
Virgil Smith
1. Are you checking the return value of MmProbeAndLockPages to make
sure it was sucessful?
2. As to file mapping not being acceptable for performance reasons, I
assume you just need the memory locked. Given that I seem to remember
a user mode function for locking memory (VirtualLock). I remember it
mainly because the fact that the docs say it is implemented as a stub
under 95 (supposed to work under NT though) that returns TRUE
(success), not FALSE (failure) is one of my favorite examples of pure
MS crap. I think this function might keep you from needing a KM
driver for this at all (maybe), however, I don't remember the docs
exactly and I think it might be that rather than hard locking the
memory it just forces it permanently into the processes working set so
that at any point the process is active those address ranges are in
memory. If it only forces those pages into the processes working set,
then maybe you can call VirtualLock from both apps and get the
performance you need, but then again it may have to be swapped in/out
too much when switching processes to keep the performance level up.
Harold
Thank you for your suggestion.
>I've never done this before, but two things come to mind
>
>1. Are you checking the return value of MmProbeAndLockPages to make
>sure it was sucessful?
Yes, It's correct.
>2. As to file mapping not being acceptable for performance reasons, I
>assume you just need the memory locked. Given that I seem to remember
>a user mode function for locking memory (VirtualLock). I remember it
>mainly because the fact that the docs say it is implemented as a stub
>under 95 (supposed to work under NT though) that returns TRUE
>(success), not FALSE (failure) is one of my favorite examples of pure
>MS crap. I think this function might keep you from needing a KM
>driver for this at all (maybe), however, I don't remember the docs
>exactly and I think it might be that rather than hard locking the
>memory it just forces it permanently into the processes working set so
>that at any point the process is active those address ranges are in
>memory. If it only forces those pages into the processes working set,
>then maybe you can call VirtualLock from both apps and get the
>performance you need, but then again it may have to be swapped in/out
>too much when switching processes to keep the performance level up.
But will VirtualLock allow one process to access another process's memory
under
WinNT? I can pass the pointer to another Win32 program by using API
PostMessage,
so Can this program just use the this pointer to access the memory?
Anyway, I really appreciated your suggestion!
Harold
-Paul
-Paul
harold wrote in message <3601227A...@signalogic.com>...
Jamie Hanrahan
Organization: Kernel Mode Systems, San Diego, CA
Mime-Version: 1.0
Newsgroups: comp.os.ms-windows.programmer.nt.kernel-mode
On Thu, 17 Sep 1998 11:50:47 -0500, "Harold" <har...@signalogic.com>
wrote:
>Thank you for your suggestion.
>
>>I've never done this before, but two things come to mind
>>
>>1. Are you checking the return value of MmProbeAndLockPages to make
>>sure it was sucessful?
>
>
>Yes, It's correct.
>
>>2. As to file mapping not being acceptable for performance reasons, I
>>assume you just need the memory locked. Given that I seem to remember
>>a user mode function for locking memory (VirtualLock). I remember it
>>mainly because the fact that the docs say it is implemented as a stub
>>under 95 (supposed to work under NT though) that returns TRUE
>>(success), not FALSE (failure) is one of my favorite examples of pure
>>MS crap. I think this function might keep you from needing a KM
>>driver for this at all (maybe), however, I don't remember the docs
>>exactly and I think it might be that rather than hard locking the
>>memory it just forces it permanently into the processes working set so
>>that at any point the process is active those address ranges are in
>>memory. If it only forces those pages into the processes working set,
That's what it does. However, outswapping on systems with
modern-sized memories is really rare, and in any case, only happens to
processes whose threads have ALL been waiting for a long time. If
he's that busy I wouldn't worry about it. Or to put it another way,
if his system DOES have to resort to outswapping, he's going to have
other performance problems anyway.
>>then maybe you can call VirtualLock from both apps and get the
>>performance you need, but then again it may have to be swapped in/out
>>too much when switching processes to keep the performance level up.
>
>
>But will VirtualLock allow one process to access another process's memory
>under WinNT? I can pass the pointer to another Win32 program by using API
>PostMessage, so Can this program just use the this pointer to access the memory?
No, you will have to use the regular file mapping mechanism to set up
a shared memory reason, and THEN use VirtualLock from both processes.
Given that, and given that your system doesn't outswap, there would be
no benefit to resorting to a kernel-mode driver to set up a shared
buffer.
--- Jamie Hanrahan, Kernel Mode Systems, San Diego CA (j...@cmkrnl.com)
Drivers, internals, networks, applications, and training for VMS and Windows NT
NT kernel driver FAQ, links, and other information: http://www.cmkrnl.com/
Please reply in news, not via e-mail.