I’m using MmMapLockedPagesSpecifyCache and MmUnlockPages
to map and unmap an MDL in UserMode address space. This
generally works under XP and 2000.
However, I have an excerciser that runs my driver, and repeatedly
creates frames, maps them, ummaps them and deletes the frames. All
from the same process. This generally runs forever under Windows
2000. Under XP, whether or not it works forever depends on the size
of the “frame” I’m creating. Larger frames seem to eventually lead
to the XP machine crashing, whereas the same software, with the same
settings on the same machine (dual boot) works fine under Win2000.
The only tricky thing in this is that the MDL is created from pages
that I allocate via AllocateCommonBuffer calls, a page at a time.
This frame is intended to be shared with a PCI card.
I’ve checked with the performance monitor and PTEs don’t seem to
be leaking, nor does memory esem to be leaking. If they were, it
wouldn’t run forever on lightly loaded systems.
Any ideas what might be going on here? I’m not getting error
returns from MmMapLockedPagesSpecifyCache. I check.
Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”
abuse@xo.com
xxxxx@ftc.gov
Perhaps the bug is elsewhere, and the frame size difference changes the way memory is
allocated. e.g., you are writing off the end of some structure, but in the cases where
it doesn’t crash, this in unallocated or unimportant.
“Stephen Williams” wrote in message news:xxxxx@ntdev…
>
>
> I’m using MmMapLockedPagesSpecifyCache and MmUnlockPages
> to map and unmap an MDL in UserMode address space. This
> generally works under XP and 2000.
>
> However, I have an excerciser that runs my driver, and repeatedly
> creates frames, maps them, ummaps them and deletes the frames. All
> from the same process. This generally runs forever under Windows
> 2000. Under XP, whether or not it works forever depends on the size
> of the “frame” I’m creating. Larger frames seem to eventually lead
> to the XP machine crashing, whereas the same software, with the same
> settings on the same machine (dual boot) works fine under Win2000.
>
> The only tricky thing in this is that the MDL is created from pages
> that I allocate via AllocateCommonBuffer calls, a page at a time.
> This frame is intended to be shared with a PCI card.
>
> I’ve checked with the performance monitor and PTEs don’t seem to
> be leaking, nor does memory esem to be leaking. If they were, it
> wouldn’t run forever on lightly loaded systems.
>
> Any ideas what might be going on here? I’m not getting error
> returns from MmMapLockedPagesSpecifyCache. I check.
> –
> Steve Williams “The woods are lovely, dark and deep.
> steve at icarus.com But I have promises to keep,
> steve at picturel.com and lines to code before I sleep,
> http://www.picturel.com And lines to code before I sleep.”
>
> abuse@xo.com
> xxxxx@ftc.gov
>
>
>
>
xxxxx@syssoftsol.com said:
Perhaps the bug is elsewhere, and the frame size difference changes
the way memory is allocated.
In this test, I’m allocating the same size frame each time. Also,
this test is not writing to the frame at all, just allocating it,
mapping it, unmapping it and releasing it; rinse, lather, repeat.
Buffer overruns elsewhere in the driver are a good guess and I’ve
been looking for that possibility, but nothing is turning up. And
skipping only the map/unmap prevents the crash, even though no-one
is accessing the mapped frame in this test.
Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”
abuse@xo.com
xxxxx@ftc.gov
“Stephen Williams” wrote in message news:xxxxx@ntdev…
>
>
> I’m using MmMapLockedPagesSpecifyCache and MmUnlockPages
…
> of the “frame” I’m creating. Larger frames seem to eventually lead
> to the XP machine crashing, whereas the same software, with the same
> settings on the same machine (dual boot) works fine under Win2000.
>
It’s sorta hard to guess what might be going on from the information you
provide.
Two obvious questions:
1) Are you running with the checked kernel and HAL (if not, you should)
2) What’s the crash dump say?
Peter
OSR
> I’m using MmMapLockedPagesSpecifyCache and MmUnlockPages
…
of the “frame” I’m creating. Larger frames seem to eventually lead
to the XP machine crashing, whereas the same software, with the same
settings on the same machine (dual boot) works fine under Win2000.
xxxxx@osr.com said:
What’s the crash dump say?
I’m running the kernel with debugger support enabled, and it stops
in the call to MmMapLockedPagesSpecifyCache, specifically within its
call to MmLockPageableImageSection.
It’s acting as if the system is running out of something, but I don’t
know what. I use AllocateCommonBuffers to allocate the pages of my
frame, I use IoAllocateMdl to allocate the MDL that holds these for
mapping, I use MmMapLockedPagesSpecifyCache to map the MDL in user mode.
In the other direction, I use MmUnmapLockedPages to unmap (It must
somehow already know that these are UserMode mapped pages) IoFreeMdl
to release the MDL, and FreeCommonBuffers to release the pages.
–
Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”
abuse@xo.com
xxxxx@ftc.gov
You are unlocking the pages, correct? Otherwise there will still be a
reference on the page, hence it won’t be freed.
Pete
Peter Scott
xxxxx@KernelDrivers.com
http://www.KernelDrivers.com
>-----Original Message-----
>From: xxxxx@lists.osr.com [mailto:bounce-ntdev-
>xxxxx@lists.osr.com] On Behalf Of Stephen Williams
>Sent: Wednesday, June 19, 2002 11:27 AM
>To: NT Developers Interest List
>Subject: [ntdev] Re: MmMapLockedPages… on XP vs. 2000
>
>> I’m using MmMapLockedPagesSpecifyCache and MmUnlockPages
>…
>> of the “frame” I’m creating. Larger frames seem to eventually lead
>> to the XP machine crashing, whereas the same software, with the same
>> settings on the same machine (dual boot) works fine under Win2000.
>
>
>xxxxx@osr.com said:
>> What’s the crash dump say?
>
>I’m running the kernel with debugger support enabled, and it stops
>in the call to MmMapLockedPagesSpecifyCache, specifically within its
>call to MmLockPageableImageSection.
>
>It’s acting as if the system is running out of something, but I don’t
>know what. I use AllocateCommonBuffers to allocate the pages of my
>frame, I use IoAllocateMdl to allocate the MDL that holds these for
>mapping, I use MmMapLockedPagesSpecifyCache to map the MDL in user
mode.
>
>In the other direction, I use MmUnmapLockedPages to unmap (It must
>somehow already know that these are UserMode mapped pages) IoFreeMdl
>to release the MDL, and FreeCommonBuffers to release the pages.
>
>–
>Steve Williams “The woods are lovely, dark and deep.
>steve at icarus.com But I have promises to keep,
>steve at picturel.com and lines to code before I sleep,
>http://www.picturel.com And lines to code before I sleep.”
>
>abuse@xo.com
>xxxxx@ftc.gov
>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@KernelDrivers.com
>To unsubscribe send a blank email to %%email.unsub%%
As far as I know MmMapLockedPagesSpecifyCache dont make any subsequent calls
to
MmLockPagableImageSection. Better please, get a stack trace from live , then
let the system bugcheck
and then give us a stack dump and the output of !analyze -v command issued
on the dump.
Regards , Dan
----- Original Message -----
From: “Stephen Williams”
To: “NT Developers Interest List”
Sent: Wednesday, June 19, 2002 8:27 PM
Subject: [ntdev] Re: MmMapLockedPages… on XP vs. 2000
> > I’m using MmMapLockedPagesSpecifyCache and MmUnlockPages
> …
> > of the “frame” I’m creating. Larger frames seem to eventually lead
> > to the XP machine crashing, whereas the same software, with the same
> > settings on the same machine (dual boot) works fine under Win2000.
>
>
> xxxxx@osr.com said:
> > What’s the crash dump say?
>
> I’m running the kernel with debugger support enabled, and it stops
> in the call to MmMapLockedPagesSpecifyCache, specifically within its
> call to MmLockPageableImageSection.
>
> It’s acting as if the system is running out of something, but I don’t
> know what. I use AllocateCommonBuffers to allocate the pages of my
> frame, I use IoAllocateMdl to allocate the MDL that holds these for
> mapping, I use MmMapLockedPagesSpecifyCache to map the MDL in user mode.
>
> In the other direction, I use MmUnmapLockedPages to unmap (It must
> somehow already know that these are UserMode mapped pages) IoFreeMdl
> to release the MDL, and FreeCommonBuffers to release the pages.
>
> –
> Steve Williams “The woods are lovely, dark and deep.
> steve at icarus.com But I have promises to keep,
> steve at picturel.com and lines to code before I sleep,
> http://www.picturel.com And lines to code before I sleep.”
>
> abuse@xo.com
> xxxxx@ftc.gov
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>
xxxxx@KernelDrivers.com said:
You are unlocking the pages, correct? Otherwise there will still be a
reference on the page, hence it won’t be freed.
Unmapping them, yes.
The pages are allocated via AllocateCommonBuffer so there is no need
to MmProbeAndLock these pages. I’m or’ing these flags into the MDL
that I build from these pages:
MDL_PAGES_LOCKED|MDL_SOURCE_IS_NONPAGED_POOL;
I do FreeCommonBuffer to release the pages, after I MmUnmapLockedPages
to unmap them.
Furthermore, I just found that when I replace MmMapLockedPagesSpecifyCache
with MmMapLockedPages, the problem no longer occurs. It’s running right
now. If I forgot to release something, then this simple change should not
stop the crashing, right?
I’m wondering if MmMapLockedPagesSpecifyCache is doing something that
MmMapLockedPages is not, and that MmUnmapLockedPages is not undoing.
Maybe?
–
Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”
abuse@xo.com
xxxxx@ftc.gov
MmMapLockedPages is just a wrapper ove MmMapLockedPagesSpecifyCache.
something like
NTKERNELAPI
PVOID
MmMapLockedPages (
IN PMDL MemoryDescriptorList,
IN KPROCESSOR_MODE AccessMode
)
{
return
MmMapLockedPagesSpecifyCache(Mdl,AccessMode,MmCached,NULL,TRUE,HighPagePrior
ity);
}
Please check if you use AllocateCommonBuffer to request cached memory and
then you try to map it as non cached. This can lead to problems.
----- Original Message -----
From: “Stephen Williams”
To: “NT Developers Interest List”
Sent: Wednesday, June 19, 2002 9:33 PM
Subject: [ntdev] Re: MmMapLockedPages… on XP vs. 2000
>
> xxxxx@KernelDrivers.com said:
> > You are unlocking the pages, correct? Otherwise there will still be a
> > reference on the page, hence it won’t be freed.
>
> Unmapping them, yes.
>
> The pages are allocated via AllocateCommonBuffer so there is no need
> to MmProbeAndLock these pages. I’m or’ing these flags into the MDL
> that I build from these pages:
>
> MDL_PAGES_LOCKED|MDL_SOURCE_IS_NONPAGED_POOL;
>
> I do FreeCommonBuffer to release the pages, after I MmUnmapLockedPages
> to unmap them.
>
> Furthermore, I just found that when I replace MmMapLockedPagesSpecifyCache
> with MmMapLockedPages, the problem no longer occurs. It’s running right
> now. If I forgot to release something, then this simple change should not
> stop the crashing, right?
>
> I’m wondering if MmMapLockedPagesSpecifyCache is doing something that
> MmMapLockedPages is not, and that MmUnmapLockedPages is not undoing.
> Maybe?
>
> –
> Steve Williams “The woods are lovely, dark and deep.
> steve at icarus.com But I have promises to keep,
> steve at picturel.com and lines to code before I sleep,
> http://www.picturel.com And lines to code before I sleep.”
>
> abuse@xo.com
> xxxxx@ftc.gov
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>
“Stephen Williams” wrote in message news:xxxxx@ntdev…
>
>
Steve… You ARE running this on a CHECKED version of the kernel and HAL,
right? Did I ask this before?
I’m asking, cuz there’s a LOT of cross-checking done by the MM in this
area… If you’re not repro’ing problems on the checked build, your not
properly validating your driver and (worse) you’re depriving yourself of
lots of good debugging information.
>
> I’m running the kernel with debugger support enabled, and it stops
> in the call to MmMapLockedPagesSpecifyCache, specifically within its
> call to MmLockPageableImageSection.
>
It “stops”??
Can you please give us the exact crash code, and a quick stack dump?
Peter
OSR
xxxxx@rdsor.ro said:
Please check if you use AllocateCommonBuffer to request cached memory
and then you try to map it as non cached. This can lead to problems.
That was an interesting idea, but I definitely pass FALSE to the
AllocateCommonBuffer function that allocates the pages:
page_vrt = xsp->dma->DmaOperations->AllocateCommonBuffer(xsp->dma,
PAGE_SIZE, &page_bus, FALSE);
(This is called for each page, the test at hand has 497 pages.)
And my call to MmMapLockedPagesSpecifyCache is:
mapinfo->base = MmMapLockedPagesSpecifyCache(xsp->frame_mdl[fidx],
UserMode, MmNonCached, 0, FALSE, NormalPagePriority);
Now since I’m being polite, I figured it would be OK if this function
failed, so I used NormalPagePriority and FALSE for the Must succeed
parameter. It should return a NULL if it can’t, right?
xxxxx@rdsor.ro said:
As far as I know MmMapLockedPagesSpecifyCache dont make any subsequent
calls to MmLockPagableImageSection.
The stack checks I’ve seen all have MmLockPagableImageSection on top,
called by MmMapLockedPagesSpecifyCache. It is hung in the former.
Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”
abuse@xo.com
xxxxx@ftc.gov
xxxxx@osr.com said:
Steve… You ARE running this on a CHECKED version of the kernel and
HAL, right? Did I ask this before?
Customer machine, so this is a little inconvenient.
What’s more inconvenient, when I try to *install* a checked XP,
the darned thing BSOD (check code 8E, I think) on its first boot
of the setup process. October 2001 Checked build from our MSDN
subscription.
Grrr…
xxxxx@osr.com said:
It “stops”??
Can you please give us the exact crash code, and a quick stack dump?
When the debugger is enabled, it kicks one into the debugger. The
items on the top of the stack are:
MmLockPageableImageSection
MmMapLockedPagesSpecifyCache
When the debugger is not enabled, it simply BSOD with crash code
0xc0000141. I’ve never seen that before.
–
Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”
abuse@xo.com
xxxxx@ftc.gov
0xC0000141 as a status would be STATUS_INVALID_ADDRESS. This error would
kind of tie into the call that is failing. It doesn’t show up as a possible
bug check code anywhere though. Can you break in WinDbg when the BSOD
occurs and get anything from !analyze -v ?
BTW, you can just run a checked version of the HAL and NTOSKRNL, which Peter
was trying to suggest, without installing the full checked build of the OS.
This should be relatively easy to do, even on your customer’s machine.
You will need to copy the checked versions of the hal and ntoskrnl to the
target system32 directory and add something like the following line to
boot.ini
multi(0)disk(0)rdisk(0)partition(1)\WINNT=“Debug Setup”
/KERNEL=NTOSKRNL.CHK /HAL=HAL.CHK
where NTOSKRNL.CHK and HAL.CHK are the files you copied over.
We need more info to be able to help you.
–
Bill McKenzie
“Stephen Williams” wrote in message news:xxxxx@ntdev…
>
>
> xxxxx@osr.com said:
> > Steve… You ARE running this on a CHECKED version of the kernel and
> > HAL, right? Did I ask this before?
>
> Customer machine, so this is a little inconvenient.
>
> What’s more inconvenient, when I try to install a checked XP,
> the darned thing BSOD (check code 8E, I think) on its first boot
> of the setup process. October 2001 Checked build from our MSDN
> subscription.
>
> Grrr…
>
> xxxxx@osr.com said:
> > It “stops”??
> > Can you please give us the exact crash code, and a quick stack dump?
>
> When the debugger is enabled, it kicks one into the debugger. The
> items on the top of the stack are:
>
> MmLockPageableImageSection
> MmMapLockedPagesSpecifyCache
>
>
> When the debugger is not enabled, it simply BSOD with crash code
> 0xc0000141. I’ve never seen that before.
> –
> Steve Williams “The woods are lovely, dark and deep.
> steve at icarus.com But I have promises to keep,
> steve at picturel.com and lines to code before I sleep,
> http://www.picturel.com And lines to code before I sleep.”
>
> abuse@xo.com
> xxxxx@ftc.gov
>
>
>
>
xxxxx@driver.attbbs.com said:
BTW, you can just run a checked version of the HAL and NTOSKRNL, which
Peter was trying to suggest, without installing the full checked build
of the OS. This should be relatively easy to do, even on your
customer’s machine.
I tried that as well, and the system hangs in the logo screen,
even with my hardware removed. So far as I can tell, the checked
build is non-functional on this system. When I attach WinDbg to
that, it’s hung in some random Kii… function.
Very inconvenient, I agree.
Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”
abuse@xo.com
xxxxx@ftc.gov
xxxxx@driver.attbbs.com said:
0xC0000141 as a status would be STATUS_INVALID_ADDRESS. This error
would kind of tie into the call that is failing.
Sorry, BCCode=1000008e. The 0xc0000141 is parameter 1 for that bug-check.
The irritating thing is that I have this problem completely surrounded
but it won’t surrender. I can call MmMapLockedPagesSpecifyCache with
caching set up MmCached and my test loop runs forever, but if I call
it with MmNonCached, it BSOD with the above code after some number of
iterations. Stack trace from a free build is here:
f3691bc0 805054db 8190b000 00001f10 00000000 nt!MmLockPagableImageSection+0x323
f3691bf4 f8930b2e 8190b000 00000001 00000000 nt!MmMapLockedPagesSpecifyCache+0x2c9
f3691c24 f89312fe 8179cbb0 81aac858 f3691c64 ise!dev_ioctl_mmap+0xbb [g:\picturel\ise\ise\source\util\sys-2000\ise_ioctl.c @ 686]
f3691c34 f892e47e 81aab030 8181b248 804eeed3 ise!dev_ioctl+0x7c [g:\picturel\ise\ise\source\util\sys-2000\ise_ioctl.c @ 811]
f3691c40 804eeed3 81aab030 8181b248 806b4578 ise!xxioctl+0x48 [g:\picturel\ise\ise\source\util\sys-2000\entry.c @ 125]
f3691c64 80566ddb 81aab030 8181b248 81970280 nt!IoBuildPartialMdl+0xe3
f3691d00 8055fe7c 000007d8 000007d4 00000000 nt!NtWriteFile+0x34db
f3691d34 80533474 000007d8 000007d4 00000000 nt!NtDeviceIoControlFile+0x28
f3691d64 00000000 00000000 00000000 00000000 nt!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb1c
This is consistent, always in the same place, but only after running
for a while. Also, if I resume from the debugger (w/ g command) it
continues on without error, for about the same number of iterations.
Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”
abuse@xo.com
xxxxx@ftc.gov