1>I am seeing a lot of these on a machine.
*******************************************************************************
*
* A driver is mapping physical memory 00100000->001DBFFF
* that it does not own. This can cause internal CPU corruption.
* A checked build will stop in the kernel debugger
* so this problem can be fully debugged.
*
<2>This does cause a bpx but my question is how do I take it from there, in
other words, how do I nail the culprit driver. The stack is not synchronous
to the map operation.
thanks
banks
Sorry to be bugging on this one but does anybody know what in the nt kernel
triggers this. Is this splashed immediately after a map method. I cannot
trace any map/allocation operations in my driver at the time I see this.
banks
“bank kus” wrote in message news:xxxxx@ntdev…
> <1>I am seeing a lot of these on a machine.
>
> *******************************************************************************
> *
> * A driver is mapping physical memory 00100000->001DBFFF
> * that it does not own. This can cause internal CPU corruption.
> * A checked build will stop in the kernel debugger
> * so this problem can be fully debugged.
> *
>
>
> <2>This does cause a bpx but my question is how do I take it from there,
> in other words, how do I nail the culprit driver. The stack is not
> synchronous to the map operation.
>
> thanks
> banks
>
>
>
>
I have seen this after a call to one of the mapping functions (I think
it was ZwMapViewOfSetion) for memory that was allocated with
MmAllocatePagesForMdl. The region it complained about was memory that I
actually did allocate in my driver (I can’t tell you how many times I
checked what was in the MD to verify this), but the call could not find
the caching attributes it was looking for (presumably to make sure the
caching attributes already in existence didn’t conflict with those I
specified in the call). It therefore assumed that the memory didn’t
belong to me (or probably anyone else for that matter). I switched to
using MmMapLockedPagesSpecifyCache instead and all was well. I guess
that function was smarter about finding pages with no cache attributes
set yet. This is odd because the DDK docs specifically mention using
ZwMapViewOfSection with memory allocated by MmAllocatePagesForMdl as
valid.
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of bank kus
Sent: Thursday, February 23, 2006 3:01 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] driver mapping memory it does not own
Sorry to be bugging on this one but does anybody know what in the nt
kernel triggers this. Is this splashed immediately after a map method. I
cannot trace any map/allocation operations in my driver at the time I
see this.
banks
“bank kus” wrote in message news:xxxxx@ntdev…
> <1>I am seeing a lot of these on a machine.
>
> *************************************************************
>
> *
> * A driver is mapping physical memory 00100000->001DBFFF
> * that it does not own. This can cause internal CPU corruption.
> * A checked build will stop in the kernel debugger
> * so this problem can be fully debugged.
> *
>
>
> <2>This does cause a bpx but my question is how do I take it from
> there, in other words, how do I nail the culprit driver. The stack is
> not synchronous to the map operation.
>
> thanks
> banks
>
>
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: bbrown@mc.com To unsubscribe
send a blank email to xxxxx@lists.osr.com
So I did a bpx on nt!mmmapiospace before this message is displayed but
doesnt look like it appears after a mmmapiospace.
This is very elementary I guess but is there a way to search all existing
MDLs for a range of physical addresses.
banks
“Brown, Beverly” wrote in message news:xxxxx@ntdev…
I have seen this after a call to one of the mapping functions (I think
it was ZwMapViewOfSetion) for memory that was allocated with
MmAllocatePagesForMdl. The region it complained about was memory that I
actually did allocate in my driver (I can’t tell you how many times I
checked what was in the MD to verify this), but the call could not find
the caching attributes it was looking for (presumably to make sure the
caching attributes already in existence didn’t conflict with those I
specified in the call). It therefore assumed that the memory didn’t
belong to me (or probably anyone else for that matter). I switched to
using MmMapLockedPagesSpecifyCache instead and all was well. I guess
that function was smarter about finding pages with no cache attributes
set yet. This is odd because the DDK docs specifically mention using
ZwMapViewOfSection with memory allocated by MmAllocatePagesForMdl as
valid.
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of bank kus
Sent: Thursday, February 23, 2006 3:01 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] driver mapping memory it does not own
Sorry to be bugging on this one but does anybody know what in the nt
kernel triggers this. Is this splashed immediately after a map method. I
cannot trace any map/allocation operations in my driver at the time I
see this.
banks
“bank kus” wrote in message news:xxxxx@ntdev…
> <1>I am seeing a lot of these on a machine.
>
> *************************************************************
>
> *
> * A driver is mapping physical memory 00100000->001DBFFF
> * that it does not own. This can cause internal CPU corruption.
> * A checked build will stop in the kernel debugger
> * so this problem can be fully debugged.
> *
>
>
> <2>This does cause a bpx but my question is how do I take it from
> there, in other words, how do I nail the culprit driver. The stack is
> not synchronous to the map operation.
>
> thanks
> banks
>
>
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: bbrown@mc.com To unsubscribe
send a blank email to xxxxx@lists.osr.com
I did not see the problem with MmMapIoSpace. I saw it with
ZwMapViewOfSection and only when using addresses allocated with
MmAllocatedPagesForMdl.
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of bank kus
Sent: Thursday, February 23, 2006 4:38 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] driver mapping memory it does not own
So I did a bpx on nt!mmmapiospace before this message is displayed but
doesnt look like it appears after a mmmapiospace.
This is very elementary I guess but is there a way to search all
existing
MDLs for a range of physical addresses.
banks
“Brown, Beverly” wrote in message news:xxxxx@ntdev…
I have seen this after a call to one of the mapping functions (I think
it was ZwMapViewOfSetion) for memory that was allocated with
MmAllocatePagesForMdl. The region it complained about was memory that I
actually did allocate in my driver (I can’t tell you how many times I
checked what was in the MD to verify this), but the call could not find
the caching attributes it was looking for (presumably to make sure the
caching attributes already in existence didn’t conflict with those I
specified in the call). It therefore assumed that the memory didn’t
belong to me (or probably anyone else for that matter). I switched to
using MmMapLockedPagesSpecifyCache instead and all was well. I guess
that function was smarter about finding pages with no cache attributes
set yet. This is odd because the DDK docs specifically mention using
ZwMapViewOfSection with memory allocated by MmAllocatePagesForMdl as
valid.
Beverly
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of bank kus
Sent: Thursday, February 23, 2006 3:01 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] driver mapping memory it does not own
Sorry to be bugging on this one but does anybody know what in the nt
kernel triggers this. Is this splashed immediately after a map method. I
cannot trace any map/allocation operations in my driver at the time I
see this.
banks
“bank kus” wrote in message news:xxxxx@ntdev…
> <1>I am seeing a lot of these on a machine.
>
> *************************************************************
>
> *
> * A driver is mapping physical memory 00100000->001DBFFF
> * that it does not own. This can cause internal CPU corruption.
> * A checked build will stop in the kernel debugger
> * so this problem can be fully debugged.
> *
>
>
> <2>This does cause a bpx but my question is how do I take it from
> there, in other words, how do I nail the culprit driver. The stack is
> not synchronous to the map operation.
>
> thanks
> banks
>
>
>
>
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: bbrown@mc.com To unsubscribe
send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: bbrown@mc.com
To unsubscribe send a blank email to xxxxx@lists.osr.com