memory overwrite in driver

NTDEV
1

I am having an issue with a buffer that I am passing from my application
down to my driver getting overwritten by some code in the driver or kernel.
It is happening in some code that I don’t have source for. I am using KMDF
in WDK RTM 6000. I am not sure if I am having some type of paging issue or
what. I don’t get a protection voilation. Does
WdfRequestRetrieveInputBuffer do something to make sure the buffer is not
paged out and available in my driver? I am new to KMDF and not sure if
there is something I need to do to make sure the buffer is not paged out and
available when I need it. I set a write breakpoint in WinDbg and tracked it
to the code at the end of this message.

I am allocating the buffer like this in my test application:

file_buffer = (VOICE_BUFFER_STRUCT *)malloc(buffer_length);

I am passing the buffer like this:

if (!DeviceIoControl(DriverHandle,
(DWORD)IOCTL_APOLLO_PLAY_BUFFER,
file_buffer, // Ptr to InBuffer
buffer_length, // Length of InBuffer
NULL, // Ptr to OutBuffer
0, // Length of OutBuffer
&index, // BytesReturned
0) ) // Ptr to Overlapped structure
{

And getting the buffer like this:

case IOCTL_APOLLO_PLAY_BUFFER:
status = WdfRequestRetrieveInputBuffer(Request,
2, (PVOID*)&IOBuffer, &IOBufferLength);

if (NT_SUCCESS(status))
{
}

The third word in the buffer structure is being overwritten by the following
code in an area I don’t have source for (the last instruction is doing it):

80549856 8b0dc8f45580 mov ecx,dword ptr [nt!MmPfnDatabase (8055f4c8)]
8054985c 8d0440 lea eax,[eax+eax*2]
8054985f 8d04c1 lea eax,[ecx+eax*8]
80549862 85c0 test eax,eax
80549864 740a je nt!MiFreePoolPages+0x415 (80549870)
80549866 f6400c04 test byte ptr [eax+0Ch],4
8054986a 0f84cf010000 je nt!MiFreePoolPages+0x38b (80549a3f)
80549870 8b4d08 mov ecx,dword ptr [ebp+8]
80549873 8d41ff lea eax,[ecx-1]
80549876 83f804 cmp eax,4
80549879 894e08 mov dword ptr [esi+8],ecx

Any ideas?

Thanks,
Greg

2

Greg Coleson wrote:

I am having an issue with a buffer that I am passing from my application
down to my driver getting overwritten by some code in the driver or kernel.
It is happening in some code that I don’t have source for. I am using KMDF
in WDK RTM 6000. I am not sure if I am having some type of paging issue or
what. I don’t get a protection voilation. Does
WdfRequestRetrieveInputBuffer do something to make sure the buffer is not
paged out and available in my driver? I am new to KMDF and not sure if
there is something I need to do to make sure the buffer is not paged out and
available when I need it.

What is the hex value of the ioctl code? Remember that the buffer
access mechanism depends on the bottom two bits of the ioctl code.

Are you saying the data is bad before it gets to your driver?

I set a write breakpoint in WinDbg and tracked it
to the code at the end of this message.

Did you set this write breakpoint on the KERNEL address or the USER
address? The user address will be reused as soon as a thread in another
process gets scheduled.

And getting the buffer like this:

case IOCTL_APOLLO_PLAY_BUFFER:
status = WdfRequestRetrieveInputBuffer(Request,
2, (PVOID*)&IOBuffer, &IOBufferLength);

if (NT_SUCCESS(status))
{
}

The third word in the buffer structure is being overwritten by the following
code in an area I don’t have source for (the last instruction is doing it):

There’s nothing really wrong with the code you posted, but we’d have to
know a little more about it. What was the original buffer length? Does
that match the IOBufferLength you got?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

The control code is:

#define IOCTL_APOLLO_PLAY_BUFFER CTL_CODE(FILE_DEVICE_WDFDIO,
2059, METHOD_OUT_DIRECT, FILE_ANY_ACCESS)

The memory is correct when it gets to the driver. When I try to use the
memory shortly after I pass it to my driver it is changed.

I am assuming that I am setting it at the kernel address. I am using the
address stored in the pointer IOBuffer. I am viewing the value from the
local window in WinDbg after I set a breakpoint in my driver.

The buffer length passed and the buffer length received in the driver match.

I have breakpoint set at every entrance to my code after the buffer is
passed and I exit the routine that accepts the IOCTL.

I set a breakpoint on my interrupt handler. As soon as I enter my handler I
can see the memory is atlered. None of my code has been executed between
the time I saw my memory having the correct value and the time I see it with
an altered value.

Ideas?

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Greg Coleson wrote:
>> I am having an issue with a buffer that I am passing from my application
>> down to my driver getting overwritten by some code in the driver or
>> kernel.
>> It is happening in some code that I don’t have source for. I am using
>> KMDF
>> in WDK RTM 6000. I am not sure if I am having some type of paging issue
>> or
>> what. I don’t get a protection voilation. Does
>> WdfRequestRetrieveInputBuffer do something to make sure the buffer is not
>> paged out and available in my driver? I am new to KMDF and not sure if
>> there is something I need to do to make sure the buffer is not paged out
>> and
>> available when I need it.
>
> What is the hex value of the ioctl code? Remember that the buffer
> access mechanism depends on the bottom two bits of the ioctl code.
>
> Are you saying the data is bad before it gets to your driver?
>
>> I set a write breakpoint in WinDbg and tracked it
>> to the code at the end of this message.
>>
>
> Did you set this write breakpoint on the KERNEL address or the USER
> address? The user address will be reused as soon as a thread in another
> process gets scheduled.
>
>> And getting the buffer like this:
>>
>> case IOCTL_APOLLO_PLAY_BUFFER:
>> status = WdfRequestRetrieveInputBuffer(Request,
>> 2, (PVOID*)&IOBuffer, &IOBufferLength);
>>
>> if (NT_SUCCESS(status))
>> {
>> }
>>
>> The third word in the buffer structure is being overwritten by the
>> following
>> code in an area I don’t have source for (the last instruction is doing
>> it):
>>
>
> There’s nothing really wrong with the code you posted, but we’d have to
> know a little more about it. What was the original buffer length? Does
> that match the IOBufferLength you got?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

4

Does you application touch the buffer after making the DeviceIoControl
call? Does it wait for the I/O to complete before freeing the buffer?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Greg Coleson
Sent: Monday, March 26, 2007 12:14 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] memory overwrite in driver

The control code is:

#define IOCTL_APOLLO_PLAY_BUFFER
CTL_CODE(FILE_DEVICE_WDFDIO,
2059, METHOD_OUT_DIRECT, FILE_ANY_ACCESS)

The memory is correct when it gets to the driver. When I try to use the

memory shortly after I pass it to my driver it is changed.

I am assuming that I am setting it at the kernel address. I am using
the
address stored in the pointer IOBuffer. I am viewing the value from the

local window in WinDbg after I set a breakpoint in my driver.

The buffer length passed and the buffer length received in the driver
match.

I have breakpoint set at every entrance to my code after the buffer is
passed and I exit the routine that accepts the IOCTL.

I set a breakpoint on my interrupt handler. As soon as I enter my
handler I
can see the memory is atlered. None of my code has been executed
between
the time I saw my memory having the correct value and the time I see it
with
an altered value.

Ideas?

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Greg Coleson wrote:
>> I am having an issue with a buffer that I am passing from my
application
>> down to my driver getting overwritten by some code in the driver or
>> kernel.
>> It is happening in some code that I don’t have source for. I am
using
>> KMDF
>> in WDK RTM 6000. I am not sure if I am having some type of paging
issue
>> or
>> what. I don’t get a protection voilation. Does
>> WdfRequestRetrieveInputBuffer do something to make sure the buffer is
not
>> paged out and available in my driver? I am new to KMDF and not sure
if
>> there is something I need to do to make sure the buffer is not paged
out
>> and
>> available when I need it.
>
> What is the hex value of the ioctl code? Remember that the buffer
> access mechanism depends on the bottom two bits of the ioctl code.
>
> Are you saying the data is bad before it gets to your driver?
>
>> I set a write breakpoint in WinDbg and tracked it
>> to the code at the end of this message.
>>
>
> Did you set this write breakpoint on the KERNEL address or the USER
> address? The user address will be reused as soon as a thread in
another
> process gets scheduled.
>
>> And getting the buffer like this:
>>
>> case IOCTL_APOLLO_PLAY_BUFFER:
>> status = WdfRequestRetrieveInputBuffer(Request,
>> 2, (PVOID*)&IOBuffer, &IOBufferLength);
>>
>> if (NT_SUCCESS(status))
>> {
>> }
>>
>> The third word in the buffer structure is being overwritten by the
>> following
>> code in an area I don’t have source for (the last instruction is
doing
>> it):
>>
>
> There’s nothing really wrong with the code you posted, but we’d have
to
> know a little more about it. What was the original buffer length?
Does
> that match the IOBufferLength you got?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

Greg Coleson wrote:

The control code is:

#define IOCTL_APOLLO_PLAY_BUFFER CTL_CODE(FILE_DEVICE_WDFDIO,
2059, METHOD_OUT_DIRECT, FILE_ANY_ACCESS)

Interesting that you chose METHOD_OUT_DIRECT. Since you’re not using
the output buffer, METHOD_BUFFERED, METHOD_IN_DIRECT, and
METHOD_OUT_DIRECT are all exactly identical. The address you’re given
contains a COPY of the user’s input buffer, not a remapping of the input
buffer. That copy lives only until the IRP is completed, and then the
copy buffer is freed.

The memory is correct when it gets to the driver. When I try to use the
memory shortly after I pass it to my driver it is changed.

I am assuming that I am setting it at the kernel address. I am using the
address stored in the pointer IOBuffer.

Yes, that’s a kernel address.

I am viewing the value from the
local window in WinDbg after I set a breakpoint in my driver.

The “locals” window is not always reliable. Do you see the same value
if you use the “dd” command in the WinDbg command area?

I have breakpoint set at every entrance to my code after the buffer is
passed and I exit the routine that accepts the IOCTL.

I set a breakpoint on my interrupt handler. As soon as I enter my handler I
can see the memory is atlered. None of my code has been executed between
the time I saw my memory having the correct value and the time I see it with
an altered value.

“Interrupt handler?” Do you mean ioctl handler, or do you really mean
an interrupt handler? The address you’re given expires as soon as the
IRP is completed. Are you queueing this IRP, and not completing it
until the interrupt finishes?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

6

My application does not touch the buffer after it sends it down to the
driver.

Maybe this is the issue. The driver completes the IO after it receives the
buffer. The application knows to free the buffer when the driver sends a
buffer empty message to the application. The buffer emply message is not
coming back to the application until the driver is finished with the buffer
(I checked to be sure).

Is the buffer pointer in the kernal space only valid when the IO is not
completed? The documentation does not indicate either way for Direct IO

I use other buffers in my driver with overlapped IO that don’t seem to have
this issue.

Ideas?

“Doron Holan” wrote in message
news:xxxxx@ntdev…
Does you application touch the buffer after making the DeviceIoControl
call? Does it wait for the I/O to complete before freeing the buffer?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Greg Coleson
Sent: Monday, March 26, 2007 12:14 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] memory overwrite in driver

The control code is:

#define IOCTL_APOLLO_PLAY_BUFFER
CTL_CODE(FILE_DEVICE_WDFDIO,
2059, METHOD_OUT_DIRECT, FILE_ANY_ACCESS)

The memory is correct when it gets to the driver. When I try to use the

memory shortly after I pass it to my driver it is changed.

I am assuming that I am setting it at the kernel address. I am using
the
address stored in the pointer IOBuffer. I am viewing the value from the

local window in WinDbg after I set a breakpoint in my driver.

The buffer length passed and the buffer length received in the driver
match.

I have breakpoint set at every entrance to my code after the buffer is
passed and I exit the routine that accepts the IOCTL.

I set a breakpoint on my interrupt handler. As soon as I enter my
handler I
can see the memory is atlered. None of my code has been executed
between
the time I saw my memory having the correct value and the time I see it
with
an altered value.

Ideas?

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Greg Coleson wrote:
>> I am having an issue with a buffer that I am passing from my
application
>> down to my driver getting overwritten by some code in the driver or
>> kernel.
>> It is happening in some code that I don’t have source for. I am
using
>> KMDF
>> in WDK RTM 6000. I am not sure if I am having some type of paging
issue
>> or
>> what. I don’t get a protection voilation. Does
>> WdfRequestRetrieveInputBuffer do something to make sure the buffer is
not
>> paged out and available in my driver? I am new to KMDF and not sure
if
>> there is something I need to do to make sure the buffer is not paged
out
>> and
>> available when I need it.
>
> What is the hex value of the ioctl code? Remember that the buffer
> access mechanism depends on the bottom two bits of the ioctl code.
>
> Are you saying the data is bad before it gets to your driver?
>
>> I set a write breakpoint in WinDbg and tracked it
>> to the code at the end of this message.
>>
>
> Did you set this write breakpoint on the KERNEL address or the USER
> address? The user address will be reused as soon as a thread in
another
> process gets scheduled.
>
>> And getting the buffer like this:
>>
>> case IOCTL_APOLLO_PLAY_BUFFER:
>> status = WdfRequestRetrieveInputBuffer(Request,
>> 2, (PVOID*)&IOBuffer, &IOBufferLength);
>>
>> if (NT_SUCCESS(status))
>> {
>> }
>>
>> The third word in the buffer structure is being overwritten by the
>> following
>> code in an area I don’t have source for (the last instruction is
doing
>> it):
>>
>
> There’s nothing really wrong with the code you posted, but we’d have
to
> know a little more about it. What was the original buffer length?
Does
> that match the IOBufferLength you got?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

7

Greg,

an IRP that you receive in one of your dispatch routines is valid until you
complete it. If you pend the IRP (i.e. you delay the completion to some
later time), the IRP is still yours. As soon as you complete the IRP, you
lose ownership of it and its associated “kernel pointer”. The fact that you
were able to access the memory associated with an IRP after having completed
it was luck.

Have a nice day
GV

----- Original Message -----
From: “Greg Coleson”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Monday, March 26, 2007 1:34 PM
Subject: Re:[ntdev] memory overwrite in driver

> My application does not touch the buffer after it sends it down to the
> driver.
>
> Maybe this is the issue. The driver completes the IO after it receives
> the buffer. The application knows to free the buffer when the driver
> sends a buffer empty message to the application. The buffer emply message
> is not coming back to the application until the driver is finished with
> the buffer (I checked to be sure).
>
> Is the buffer pointer in the kernal space only valid when the IO is not
> completed? The documentation does not indicate either way for Direct IO
>
> I use other buffers in my driver with overlapped IO that don’t seem to
> have this issue.
>
> Ideas?
>
> “Doron Holan” wrote in message
> news:xxxxx@ntdev…
> Does you application touch the buffer after making the DeviceIoControl
> call? Does it wait for the I/O to complete before freeing the buffer?
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Greg Coleson
> Sent: Monday, March 26, 2007 12:14 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] memory overwrite in driver
>
> The control code is:
>
> #define IOCTL_APOLLO_PLAY_BUFFER
> CTL_CODE(FILE_DEVICE_WDFDIO,
> 2059, METHOD_OUT_DIRECT, FILE_ANY_ACCESS)
>
> The memory is correct when it gets to the driver. When I try to use the
>
> memory shortly after I pass it to my driver it is changed.
>
> I am assuming that I am setting it at the kernel address. I am using
> the
> address stored in the pointer IOBuffer. I am viewing the value from the
>
> local window in WinDbg after I set a breakpoint in my driver.
>
> The buffer length passed and the buffer length received in the driver
> match.
>
> I have breakpoint set at every entrance to my code after the buffer is
> passed and I exit the routine that accepts the IOCTL.
>
> I set a breakpoint on my interrupt handler. As soon as I enter my
> handler I
> can see the memory is atlered. None of my code has been executed
> between
> the time I saw my memory having the correct value and the time I see it
> with
> an altered value.
>
> Ideas?
>
> “Tim Roberts” wrote in message news:xxxxx@ntdev…
>> Greg Coleson wrote:
>>> I am having an issue with a buffer that I am passing from my
> application
>>> down to my driver getting overwritten by some code in the driver or
>>> kernel.
>>> It is happening in some code that I don’t have source for. I am
> using
>>> KMDF
>>> in WDK RTM 6000. I am not sure if I am having some type of paging
> issue
>>> or
>>> what. I don’t get a protection voilation. Does
>>> WdfRequestRetrieveInputBuffer do something to make sure the buffer is
> not
>>> paged out and available in my driver? I am new to KMDF and not sure
> if
>>> there is something I need to do to make sure the buffer is not paged
> out
>>> and
>>> available when I need it.
>>
>> What is the hex value of the ioctl code? Remember that the buffer
>> access mechanism depends on the bottom two bits of the ioctl code.
>>
>> Are you saying the data is bad before it gets to your driver?
>>
>>> I set a write breakpoint in WinDbg and tracked it
>>> to the code at the end of this message.
>>>
>>
>> Did you set this write breakpoint on the KERNEL address or the USER
>> address? The user address will be reused as soon as a thread in
> another
>> process gets scheduled.
>>
>>> And getting the buffer like this:
>>>
>>> case IOCTL_APOLLO_PLAY_BUFFER:
>>> status = WdfRequestRetrieveInputBuffer(Request,
>>> 2, (PVOID*)&IOBuffer, &IOBufferLength);
>>>
>>> if (NT_SUCCESS(status))
>>> {
>>> }
>>>
>>> The third word in the buffer structure is being overwritten by the
>>> following
>>> code in an area I don’t have source for (the last instruction is
> doing
>>> it):
>>>
>>
>> There’s nothing really wrong with the code you posted, but we’d have
> to
>> know a little more about it. What was the original buffer length?
> Does
>> that match the IOBufferLength you got?
>>
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

8

Greg Coleson wrote:

Maybe this is the issue. The driver completes the IO after it receives the
buffer. The application knows to free the buffer when the driver sends a
buffer empty message to the application. The buffer emply message is not
coming back to the application until the driver is finished with the buffer
(I checked to be sure).

Yes, that’s definitely a bug.

Is the buffer pointer in the kernal space only valid when the IO is not
completed? The documentation does not indicate either way for Direct IO

The input side of an IN_DIRECT our OUT_DIRECT ioctl does not use direct
I/O – it is buffered, exactly like METHOD_BUFFERED. Only the output
side of a direct ioctl gets mapped through an MDL. And yes, as soon as
you complete the IRP, those addresses all evaporate.

Even if you change to METHOD_IN_DIRECT and pass the buffer as the output
parameter (which is legal), I don’t believe there is any guarantee that
the MDL will be valid after the IRP completes. If you need the buffer
to survive, then you must mark the IRP as pending until you don’t need
it any more. That’s the ONLY way this will work.

I use other buffers in my driver with overlapped IO that don’t seem to have
this issue.

Luck, would be my guess.

Ideas?

Yes. Mark the IRP pending and hold it in a cancel-safe queue until you
don’t need it any more.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

9

Since this is a KMDF driver, a cancel safe queue is a WDFQUEUE.

d

10

Thanks,
That was the issue.
I don’t complete the request until after I finish with the buffer and it
works correctly now.

“Gianluca Varenni” wrote in message
news:xxxxx@ntdev…
> Greg,
>
> an IRP that you receive in one of your dispatch routines is valid until
> you complete it. If you pend the IRP (i.e. you delay the completion to
> some later time), the IRP is still yours. As soon as you complete the IRP,
> you lose ownership of it and its associated “kernel pointer”. The fact
> that you were able to access the memory associated with an IRP after
> having completed it was luck.
>
> Have a nice day
> GV
>
>
> ----- Original Message -----
> From: “Greg Coleson”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Monday, March 26, 2007 1:34 PM
> Subject: Re:[ntdev] memory overwrite in driver
>
>
>> My application does not touch the buffer after it sends it down to the
>> driver.
>>
>> Maybe this is the issue. The driver completes the IO after it receives
>> the buffer. The application knows to free the buffer when the driver
>> sends a buffer empty message to the application. The buffer emply
>> message is not coming back to the application until the driver is
>> finished with the buffer (I checked to be sure).
>>
>> Is the buffer pointer in the kernal space only valid when the IO is not
>> completed? The documentation does not indicate either way for Direct IO
>>
>> I use other buffers in my driver with overlapped IO that don’t seem to
>> have this issue.
>>
>> Ideas?
>>
>> “Doron Holan” wrote in message
>> news:xxxxx@ntdev…
>> Does you application touch the buffer after making the DeviceIoControl
>> call? Does it wait for the I/O to complete before freeing the buffer?
>>
>> d
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Greg Coleson
>> Sent: Monday, March 26, 2007 12:14 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re:[ntdev] memory overwrite in driver
>>
>> The control code is:
>>
>> #define IOCTL_APOLLO_PLAY_BUFFER
>> CTL_CODE(FILE_DEVICE_WDFDIO,
>> 2059, METHOD_OUT_DIRECT, FILE_ANY_ACCESS)
>>
>> The memory is correct when it gets to the driver. When I try to use the
>>
>> memory shortly after I pass it to my driver it is changed.
>>
>> I am assuming that I am setting it at the kernel address. I am using
>> the
>> address stored in the pointer IOBuffer. I am viewing the value from the
>>
>> local window in WinDbg after I set a breakpoint in my driver.
>>
>> The buffer length passed and the buffer length received in the driver
>> match.
>>
>> I have breakpoint set at every entrance to my code after the buffer is
>> passed and I exit the routine that accepts the IOCTL.
>>
>> I set a breakpoint on my interrupt handler. As soon as I enter my
>> handler I
>> can see the memory is atlered. None of my code has been executed
>> between
>> the time I saw my memory having the correct value and the time I see it
>> with
>> an altered value.
>>
>> Ideas?
>>
>> “Tim Roberts” wrote in message news:xxxxx@ntdev…
>>> Greg Coleson wrote:
>>>> I am having an issue with a buffer that I am passing from my
>> application
>>>> down to my driver getting overwritten by some code in the driver or
>>>> kernel.
>>>> It is happening in some code that I don’t have source for. I am
>> using
>>>> KMDF
>>>> in WDK RTM 6000. I am not sure if I am having some type of paging
>> issue
>>>> or
>>>> what. I don’t get a protection voilation. Does
>>>> WdfRequestRetrieveInputBuffer do something to make sure the buffer is
>> not
>>>> paged out and available in my driver? I am new to KMDF and not sure
>> if
>>>> there is something I need to do to make sure the buffer is not paged
>> out
>>>> and
>>>> available when I need it.
>>>
>>> What is the hex value of the ioctl code? Remember that the buffer
>>> access mechanism depends on the bottom two bits of the ioctl code.
>>>
>>> Are you saying the data is bad before it gets to your driver?
>>>
>>>> I set a write breakpoint in WinDbg and tracked it
>>>> to the code at the end of this message.
>>>>
>>>
>>> Did you set this write breakpoint on the KERNEL address or the USER
>>> address? The user address will be reused as soon as a thread in
>> another
>>> process gets scheduled.
>>>
>>>> And getting the buffer like this:
>>>>
>>>> case IOCTL_APOLLO_PLAY_BUFFER:
>>>> status = WdfRequestRetrieveInputBuffer(Request,
>>>> 2, (PVOID*)&IOBuffer, &IOBufferLength);
>>>>
>>>> if (NT_SUCCESS(status))
>>>> {
>>>> }
>>>>
>>>> The third word in the buffer structure is being overwritten by the
>>>> following
>>>> code in an area I don’t have source for (the last instruction is
>> doing
>>>> it):
>>>>
>>>
>>> There’s nothing really wrong with the code you posted, but we’d have
>> to
>>> know a little more about it. What was the original buffer length?
>> Does
>>> that match the IOBufferLength you got?
>>>
>>> –
>>> Tim Roberts, xxxxx@probo.com
>>> Providenza & Boekelheide, Inc.
>>>
>>>
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>