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 IRP for
that request until you are done sharing the buffer between user-mode and
kernel-mode? Pend this IRP in your driver, and when done with the buffer,
use your second IOCTL to indicate that this IRP should be completed.
–
Bill McKenzie
Compuware Corporation
http://www.compuware.com/products/driverstudio
wrote in message news:xxxxx@ntdev…
>
> Thanks Mark,
>
> > You shouldn’t be calling MmProbeAndLockPages, it has already been done
for
> > you.
> Yes, I understand that the MDL is already locked by the Memory Manager,
> but the purpose of the IOCTL is to increment the number of locks on the
> MDL. In this way, when control returns from the driver, there will still
> be a remaining lock. Obviously, there is a complementary IOCTL that calls
> MmUnlockPages(). The texts that I read imply that there can be multiple
> locks on pages. However, the ASSERT suggests that MmProbeAndLock() cannot
> be performed on pages that are already locked.
>
> I know that this is not good practice, but the application programmers
> needed a buffer that they could share with a PCI device. My case against
> this method crumbled when it was found to work on W2K. I’m told that it is
> major upheaval to change this design.
>
> Of the matrix of tests, we find
> 1. Windows 2000 release build works.
> 2. Windows XP release build crashes, probably when the buffers are being
> used.
> 3. Windows XP checked build ASSERTs when MmProbeAndLock() is called
> (earlier than case 2).
> It is possible that the checked build of W2K might also ASSERT in the same
> place. I will have to check. As you suggest, the W2K release build might
> have just ignored the problem.
>
> > The fact that this works on w2k is a bug.
> So it sounds like
> “2. Something that was illegal on W2K but could be got away with, cannot
> be got away with on XP.”
> applies.
>
> > The assertion is documented in the DDK.
> I read “The MDL is not in proper state for this function call”.
>
> Is there a way that this scheme can be implemented?
>
> 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 W2K to XP
> > >
> > >
> > > I have a WDM driver that works on W2K, but crashes on XP.
> > >
> > > To investigate this, I have run up the application on the
> > > checked build of XP. When the application is run, it
> > > encounters a breakpoint and in the debug output, I see
> > > “Assertion failed: (MemoryDescriptorList->MdlFlags & (
> > > MDL_PAGES_LOCKED | MDL_MAPPED_TO_SYSTEM_VA |
> > > MDL_SOURCE_IS_NONPAGED_POOL | MDL_PARTIAL | MDL_IO_SPACE)) == 0
> > > Source File: d:\xpclient\base\ntos\mm\iosup.c, line 312”
> > >
> > > This appears to be happening in the DispatchControl() routine
> > > 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,
> > > IoModifyAccess);
> > >
> > > The ASSERT statement output appears to imply that it is the
> > > MDL that is at fault. However, it is my understanding that
> > > the MDL is validated by the Memory Manager, and that if it
> > > were not valid, control would not be passed to the driver.
> > >
> > > In addition to wrapping the call in a try, except block
> > > (should have be done initially), I also intend to include
> > > code to check that the mdl is non-Null.
> > >
> > > I am faced with the prospect that either:
> > > 1. Something that was legal on W2K is not legal on XP.
> > > 2. Some that was illegal on W2K but could be got away with,
> > > cannot be got away with on XP.
> > >
> > > If (1) then can anyone point me towards any references that
> > > would cover such differences? If (2) then can anyone see
> > > anything illegal about what is being done above? Is there a
> > > conflict in using METHOD_IN_DIRECT in the IOCTL definition
> > > and 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 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 the problems that I am observing.
> > >
> > > Any help would be appreciated.
> > >
> > > Thanks,
> > > Richard
> > >
>
>