General Buffer and Offset Question

If this is a FAQ, my apoligies, but I’ve read most of the FAQ and a lot of sites.

Also, I’ve asked yet again to see if my management will order me books from amazon.com:

http://www.amazon.com/Microsoft-Windows-Internals-Fourth-Pro-Developer/dp/0735619174/ref=pd_bxgy_b_text_b/104-1556979-1615156

http://www.amazon.com/Programming-Microsoft-Windows-Driver-Second/dp/0735618038/sr=8-2/qid=1163002516/ref=pd_bbs_2/104-1556979-1615156?ie=UTF8&s=books

They seem to be the only two out there. I know OSR is reprinting the other book.

In a read or write dispatch:
PIO_STACK_LOCATION irpSp = IoGetCurrentIrpStackLocation( Irp );
bufferLength = irpSp->Parameters.Write.Length;

This is the buffer length for:
A. All I/O methods?
B. Only METHOD_NEITHER?
C. Only METHOD_DIRECT?
D. Only METHOD_BUFFERED?

Explanation on why I’m befuddled:
http://www.osronline.com/ddkx/kmarch/k113_7fhu.htm
states:
The driver’s I/O stack location in the IRP indicates how many bytes to transfer at Parameters.Read.Length.

Which seems to indicate it’s method independent. However,
http://www.codeproject.com/system/WDM_Driver_development.asp
shows this:
BufLen = MmGetMdlByteCount(Irp->MdlAddress);
Offset = MmGetMdlByteOffset(Irp->MdlAddress);

What’s the difference?? Do I have two sources of lengths and offsets in the Mdl case where both are the same? (like Parameters.[Read or Write].ByteOffset versus MmGetMdlByteOffset?

Thanks.

Use the information in the irp stack location for where the read/write is
and how long it is.

The Mdl information ‘may’ reflect the length of the read/write but this
information is really telling you how long the buffer is that the Mdl
describes, which will be equal to or greater than the length of the actual
IO operation.

I would suggest you just ignore these API’s for now.

Pete

Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Wednesday, November 08, 2006 9:21 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] General Buffer and Offset Question

If this is a FAQ, my apoligies, but I’ve read most of the FAQ and a lot of
sites.

Also, I’ve asked yet again to see if my management will order me books from
amazon.com:

http://www.amazon.com/Microsoft-Windows-Internals-Fourth-Pro-Developer/dp/07
35619174/ref=pd_bxgy_b_text_b/104-1556979-1615156

http://www.amazon.com/Programming-Microsoft-Windows-Driver-Second/dp/0735618
038/sr=8-2/qid=1163002516/ref=pd_bbs_2/104-1556979-1615156?ie=UTF8&s=books

They seem to be the only two out there. I know OSR is reprinting the other
book.

In a read or write dispatch:
PIO_STACK_LOCATION irpSp = IoGetCurrentIrpStackLocation( Irp );
bufferLength = irpSp->Parameters.Write.Length;

This is the buffer length for:
A. All I/O methods?
B. Only METHOD_NEITHER?
C. Only METHOD_DIRECT?
D. Only METHOD_BUFFERED?

Explanation on why I’m befuddled:
http://www.osronline.com/ddkx/kmarch/k113_7fhu.htm
states:
The driver’s I/O stack location in the IRP indicates how many bytes to
transfer at Parameters.Read.Length.

Which seems to indicate it’s method independent. However,
http://www.codeproject.com/system/WDM_Driver_development.asp
shows this:
BufLen = MmGetMdlByteCount(Irp->MdlAddress);
Offset = MmGetMdlByteOffset(Irp->MdlAddress);

What’s the difference?? Do I have two sources of lengths and offsets in the
Mdl case where both are the same? (like Parameters.[Read or
Write].ByteOffset versus MmGetMdlByteOffset?

Thanks.


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Thanks Peter.

To follow up on this:

ULONG bufferLength = 0;
LARGE_INTEGER bufferOffset;
PVOID pData = NULL;

bufferLength = irpSp->Parameters.Write.Length;
bufferOffset = irpSp->Parameters.Write.ByteOffset;

(assuming write dispatch operation)
pData = MmGetSystemAddressForMdlSafe(Irp->MdlAddress, HighPagePriority);

If my bufferOffset is non-zero, it’s a structure such that it’s
Now, I have a Mdl:

first off, the example at codeproject.com uses the Quadpart only.

LONGLONG bufferOffset = 0;
bufferOffset = irpSp->Parameters.Write.ByteOffset.Quadpart;

Then, they use this as the offset.
Should I do the same?

Second, I just want to make sure I have this offset use correct. Let’s say again with the Mdl in use, is my actual character buffer then:

(char*)(pData) + bufferOffset ??

Thanks

First, don’t use HighPagePriority, use NormalPagePriority.

Next, the offset in the irp stack is the file offset into the file, it has
nothing to do with the offset into the buffer passed to you.

Therefore if Offset->QuadPart = 0x1000, this means that the buffer which is
sent to you is for the data in the file at offset 0x1000.

So, don’t do the pData + Offset.

Pete

Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Wednesday, November 08, 2006 10:07 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] General Buffer and Offset Question

Thanks Peter.

To follow up on this:

ULONG bufferLength = 0;
LARGE_INTEGER bufferOffset;
PVOID pData = NULL;

bufferLength = irpSp->Parameters.Write.Length;
bufferOffset = irpSp->Parameters.Write.ByteOffset;

(assuming write dispatch operation)
pData = MmGetSystemAddressForMdlSafe(Irp->MdlAddress, HighPagePriority);

If my bufferOffset is non-zero, it’s a structure such that it’s
Now, I have a Mdl:

first off, the example at codeproject.com uses the Quadpart only.

LONGLONG bufferOffset = 0;
bufferOffset = irpSp->Parameters.Write.ByteOffset.Quadpart;

Then, they use this as the offset.
Should I do the same?

Second, I just want to make sure I have this offset use correct. Let’s say
again with the Mdl in use, is my actual character buffer then:

(char*)(pData) + bufferOffset ??

Thanks


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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

> Microsoft-Windows-Internals-Fourth-Pro-Developer
Must-have, here’s 2 cents of advice: buy a version that’s much
more expensive (comes as part of w2k3s rk book set) but has a CD with
PDF version, as an e-book.

The diff is > 2c though: about $40 vs about $120, but
it pays, each and every penny.

You may also want to check out books on OSR site (I would
recommend all of them, Viscarola et al goes well in parallel
with Oney.)

----- Original Message -----
From:
To: “Windows File Systems Devs Interest List”
Sent: Wednesday, November 08, 2006 12:21 PM
Subject: [ntfsd] General Buffer and Offset Question

If this is a FAQ, my apoligies, but I’ve read most of the FAQ and a lot of
sites.

Also, I’ve asked yet again to see if my management will order me books from
amazon.com:

http://www.amazon.com/Microsoft-Windows-Internals-Fourth-Pro-Developer/dp/0735619174/ref=pd_bxgy_b_text_b/104-1556979-1615156

http://www.amazon.com/Programming-Microsoft-Windows-Driver-Second/dp/0735618038/sr=8-2/qid=1163002516/ref=pd_bbs_2/104-1556979-1615156?ie=UTF8&s=books

They seem to be the only two out there. I know OSR is reprinting the other
book.

In a read or write dispatch:
PIO_STACK_LOCATION irpSp = IoGetCurrentIrpStackLocation( Irp );
bufferLength = irpSp->Parameters.Write.Length;

This is the buffer length for:
A. All I/O methods?
B. Only METHOD_NEITHER?
C. Only METHOD_DIRECT?
D. Only METHOD_BUFFERED?

Explanation on why I’m befuddled:
http://www.osronline.com/ddkx/kmarch/k113_7fhu.htm
states:
The driver’s I/O stack location in the IRP indicates how many bytes to
transfer at Parameters.Read.Length.

Which seems to indicate it’s method independent. However,
http://www.codeproject.com/system/WDM_Driver_development.asp
shows this:
BufLen = MmGetMdlByteCount(Irp->MdlAddress);
Offset = MmGetMdlByteOffset(Irp->MdlAddress);

What’s the difference?? Do I have two sources of lengths and offsets in the
Mdl case where both are the same? (like Parameters.[Read or
Write].ByteOffset versus MmGetMdlByteOffset?

Thanks.


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Yeah, it blue-screened nicely when I tried it. Good thing I’m using VMWare and testing/debugging in a VM.

I’m guessin then, that in terms of what I’m interested in, this BytesOffset value is meaningless?

Ok. Here’s the crux of my issue. I’m trying to “look” at the buffers. Now, I have no idea whether or not this is something I should or should not do. Apparently, I’m doing a lot of things I should never be doing.

Remember, I’ve not done any of the context stuff yet. I’m still trying to get a handle on what is in the pipe durnig my reads and writes.

Here’s the code:

if ( (Irp->MdlAddress != NULL) )
{
pData = MmGetSystemAddressForMdlSafe(Irp->MdlAddress, NormalPagePriority);
RRF_LOG_PRINT(RRDEBUG_DISPLAY_READ_DISPATCH, (“Dispatch Read size of Mdl buffer contains %d bytes with offset %ld\n”, bufferLength, bufferOffset));
RRF_LOG_PRINT(RRDEBUG_DISPLAY_READ_DISPATCH, (“Dispatch Read MDL buffer contains ANSI :\n %s\n”, ( (char*)pData ) ));
}

Note to Tony; See, I *did* take a suggestion and changed the priority back to Normal.

You can see I’m trying to dump the buffer into the debugger.

This seems to work okay until I get to the “hosts” file. It dumps out part of the file and then blue screens.

I’m thinking I likely don’t have a clue what I’m dumping to begin with and whether or not its safe to do so. Hence, I started this thread.

Regardless, I’m not any further along than I was, even though I understand what I am doing better now, thank you again.

So… here’s the dilly-o: Is this problem with the larger-text files because … why? I have no idea. It could be I’m doing something that should never, ever be done because… I have no idea.

Thanks again.

If you want to ‘look’ at the data itself I suggest copying the first 10 or
20 bytes of pData into a separate buffer, NULL terminate the buffer and then
push it into the DbgPrint statement. At least you won’t be touching,
potentially, bytes beyond the end of the buffer which could be invalid.

Pete

Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Wednesday, November 08, 2006 10:52 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] General Buffer and Offset Question

Yeah, it blue-screened nicely when I tried it. Good thing I’m using VMWare
and testing/debugging in a VM.

I’m guessin then, that in terms of what I’m interested in, this BytesOffset
value is meaningless?

Ok. Here’s the crux of my issue. I’m trying to “look” at the buffers.
Now, I have no idea whether or not this is something I should or should not
do. Apparently, I’m doing a lot of things I should never be doing.

Remember, I’ve not done any of the context stuff yet. I’m still trying to
get a handle on what is in the pipe durnig my reads and writes.

Here’s the code:

if ( (Irp->MdlAddress !=
NULL) )
{
pData =
MmGetSystemAddressForMdlSafe(Irp->MdlAddress, NormalPagePriority);

RRF_LOG_PRINT(RRDEBUG_DISPLAY_READ_DISPATCH, (“Dispatch Read size of Mdl
buffer contains %d bytes with offset %ld\n”, bufferLength, bufferOffset));

RRF_LOG_PRINT(RRDEBUG_DISPLAY_READ_DISPATCH, (“Dispatch Read MDL buffer
contains ANSI :\n %s\n”, ( (char*)pData ) ));
}

Note to Tony; See, I *did* take a suggestion and changed the priority back
to Normal.

You can see I’m trying to dump the buffer into the debugger.

This seems to work okay until I get to the “hosts” file. It dumps out part
of the file and then blue screens.

I’m thinking I likely don’t have a clue what I’m dumping to begin with and
whether or not its safe to do so. Hence, I started this thread.

Regardless, I’m not any further along than I was, even though I understand
what I am doing better now, thank you again.

So… here’s the dilly-o: Is this problem with the larger-text files
because … why? I have no idea. It could be I’m doing something that
should never, ever be done because… I have no idea.

Thanks again.


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

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