> Why not send down a buffer from user-mode using an IOCTL with a direct
buffering method as you are already doing, and just not complete
the=20
IRP for that request until you are done sharing the buffer between=20
user-mode and kernel-mode? Pend this IRP in your driver, and when=20
done with the buffer, use your second IOCTL to indicate that this IRP
should be completed.
I don’t seem to be having much joy with this solution.
I’ve modified the driver to call IoMarkIrpPending() and return
STATUS_PENDING. Unfortunately, when I run it, I find that control does
seem to be being passed back to my application. It would seem that
returning STATUS_PENDING from my DriverControl routine (and/or not calling
IoCompleteRequest()) prevents the MemoryManager from returning control to
the application.
Is this really the case or am I doing something wrong?
If the former then what would be the best way to achieve what I require
(i.e. locking down buffers to share between User Mode and a mapped PCI
device)?
Thanks,
Richard
-----Original Message-----
From: xxxxx@cix.co.uk [mailto:xxxxx@cix.co.uk]
Sent: Wednesday, April 16, 2003 11:30 AM
To: NT Developers Interest List
Subject: [ntdev] Problems migrating MmProbeAndLockPages()
from=20
W2K to XPI have a WDM driver that works on W2K, but crashes on XP.
To investigate this, I have run up the application on the=20
checked build of XP. When the application is run, it
encounters=20
a breakpoint and in the debug output, I see
“*** Assertion failed: (MemoryDescriptorList->MdlFlags & (=20
MDL_PAGES_LOCKED | MDL_MAPPED_TO_SYSTEM_VA |=20
MDL_SOURCE_IS_NONPAGED_POOL | MDL_PARTIAL | MDL_IO_SPACE)) =
=3D=3D 0
*** Source File: d:\xpclient\base\ntos\mm\iosup.c, line 312”This appears to be happening in the DispatchControl() routine=20
that handles an IOCTL. The IOCTL in question is defined as
CTL_CODE(FILE_DEVICE_UNKNOWN, 0x510, METHOD_IN_DIRECT,
FILE_ANY_ACCESS)The code that appears to be causing the problem would seem to be
MmProbeAndLockPages(Irp->MdlAddress, UserMode,=20
IoModifyAccess);The ASSERT statement output appears to imply that it is the
MDL=20
that is at fault. However, it is my understanding that the
MDL=20
is validated by the Memory Manager, and that if it were not=20
valid, control would not be passed to the driver.In addition to wrapping the call in a __try, __except block=20
(should have be done initially), I also intend to include
code=20
to check that the mdl is non-Null.I am faced with the prospect that either:
- Something that was legal on W2K is not legal on XP.
- Some that was illegal on W2K but could be got away with,=20
cannot be got away with on XP.If (1) then can anyone point me towards any references that=20
would cover such differences? If (2) then can anyone see=20
anything illegal about what is being done above? Is there a=20
conflict in using METHOD_IN_DIRECT in the IOCTL definition
and=20
then using MmProbeAndLockPages() with IoModifyAccess?By the way, when XP is loading, I notice the following debug
output:
“MM: Loader/HAL memory block indicates large pages cannot be=20
used for
80002000->8001BD7F
MM: Loader/HAL memory block indicates large pages cannot be used
for
81153000->81393FFF
MM: Disabling large pages for all ranges due to overlap”
I’m assuming that this is to be expected and is not involved
in=20
the problems that I am observing.Any help would be appreciated.
Thanks,
Richard