RE: Problems migrating MmProbeAndLockPages() from W2K to XP

NTDEV
1

You shouldn’t be calling MmProbeAndLockPages, it has already been done for
you. The fact that this works on w2k is a bug. The assertion is documented
in the DDK.

-----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

You are currently subscribed to ntdev as:
xxxxx@stratus.com To unsubscribe send a blank email to
xxxxx@lists.osr.com

2

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
>