Interesting. Encapsulate yor code into __try __except statemts, and youll
catch this exception. MmMapLockedPagesSpecifyCache relay internaly on a
call to MiMapLockedPagesInUserSpace for performing a user space mapping.
Internaly this call resorts to a call to ExRaiseStatus() to process some
errors. Tracing this call into the
debugger I seen that neither MmMapLockedPagesSpecifyCache , nor
MiMapLockedPagesInUserSpace have a SEH frame to catch this situation, so
its callers responsability to create one, before calling this function. Now,
this particular status, STATUS_INVALID_ADDRESS is raised as a result to a
call to a function called MiMustFrameBeCached, so I still think
you are facing a cache collision.
The DDK (at least not mine)does not statuates that this particual API can
raise an exception. Checking the code in XP no service pack I was not able
to find any __try __except constructions in debugger in
MiMapLockedPagesInUserSpace. Checking the same function in 2k and Nt 40 I
found that they do corectly provide a SEH frame for catching this exception.
This leads me to the conclusion that DDK documentation is essentially
correct, and this is a implementation bug of the call in
XP. I would like somone to check and confirm this.
Best regards, Dan
----- Original Message -----
From: “Stephen Williams”
To: “NT Developers Interest List”
Sent: Thursday, June 20, 2002 8:33 PM
Subject: [ntdev] Re: MmMapLockedPages… on XP vs. 2000
>
> 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
>
>
>
> —
> 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…
>
>
> 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…
>
Don’t install the checked build – Just put the checked Kernel and HAL on
the system. It’ll take you less than 5 minutes. Then you can choose to
boot the checked or the free versions of the O/S at startup time (with one
installation of the OS).
In the off chance you’ve not done this before, see:
http://www.osr.com/ntinsider/2001/checking/checked.htm (or the XP DDK docs,
which look “remarkably similar” to this article 
If the system bsods then, WITH the debugger connected, you’ve got a bug in
your driver. The checked build of Windows DOES “work”… it doesn’t BSOD
for no reason…
>
> 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.
>
Yeah, that’s weird. That’s not a crash code, as you implied. I have some
trouble believing that MmMapLockedPagesxxx calls MmLockPageableImageSection,
too… Perhaps the you can post the actual stack dump?
Sorry not to be able to be more helpful. I’m not trying to give you “fetch
a rock” exercises here. But you are indeed seeing some strange behaviors…
Peter
OSR
> 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.
xxxxx@osr.com said:
Don’t install the checked build – Just put the checked Kernel and HAL
on the system.
Tried that, too. The checked kernel does not run on this machine,
hanging the early in the system setup. I managed to connect WinDbg
to that, but since got distracted by other threads. I really would
have loved to get a You’ve-done-this-stupid-thing type of BSOD,
but alas it is not to be:-(
And Dan Partelly has been able to make some sense of the Free build
stack trace I posted earlier.
–
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@rdsor.ro said:
Encapsulate yor code into __try __except statemts, and youll catch
this exception.
And what should I do with said exception? Just fail the whole operation?
xxxxx@rdsor.ro said:
STATUS_INVALID_ADDRESS is raised as a result to a call to a function
called MiMustFrameBeCached, so I still think you are facing a cache
collision.
Is this something that would be affected by the MmCached vs. MmNonCached
parameter?
–
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@rdsor.ro said:
> STATUS_INVALID_ADDRESS is raised as a result to a call to a function
> called MiMustFrameBeCached, so I still think you are facing a cache
> collision.
Is this something that would be affected by the MmCached vs. MmNonCached
parameter?
Absolutely! (NICE work, Dan Partelly… VERY nice analysis).
Remember that one of the changes from Win2K to XP/.NET was a fix whereby
memory mappings must be consistent with regard to cache type. In other
words, if the memory is mapped one place non-cached, all other mappings of
those pages must also be non-cached.
I think Mr. Partelly has hit upon your solution,
Peter
OSR
> I’m using MmMapLockedPagesSpecifyCache and MmUnlockPages
to map and unmap an MDL in UserMode address space. This
generally works under XP and 2000.
In XP, you cannot map the same physical pages with different caching
attributes. MM checks this.
Max
xxxxx@rdsor.ro said:
Interesting. Encapsulate yor code into __try __except statemts, and
youll catch this exception. MmMapLockedPagesSpecifyCache relay
internaly on a call to MiMapLockedPagesInUserSpace for performing a
user space mapping. Internaly this call resorts to a call to
ExRaiseStatus() to process some errors.
OK, so I wrapped a __try around my call to MmMapLockedPagesSpecifyCache
and gave an __except action that logged the catch and failed the
operation. And sure enough, the exception is tripping. Furthermore,
when I catch the exception, complete my driver operation with my own
failure status and let the application try again, it works normally.
Every once in a while, it fails again, but generally it is working
properly. So now I need to know what I should *really* do. I can
either retry immediately in the driver, or I can fail the map and
let the application come back later. Or I can panic the whole mess
under the theory that the kernel is now FUBAR and perhaps due for
a prophylactic reboot.
(I’m mildly concerned that a checked kernel won’t boot on this
machine.)