Hi,
I want to access the buffer from a request I receive in a read dispatch
routine. Till now I only used WinDbg to display debug messages.
I’ve set a breakpoint in that dispatch routine and got some information
using the !wdfkd.wdfrequest and !IRP commands, but I don’t know how I
can access the buffer with my information. I’m looking for a 16 byte
ascii string coming from my serial device, but I’m a bit confused,
because I receive this information with 3 requests. Any idears what I
have to do?
Thank you in advance,
Hannes
Hannes Finck wrote:
I want to access the buffer from a request I receive in a read
dispatch routine. Till now I only used WinDbg to display debug messages.
I’ve set a breakpoint in that dispatch routine and got some information
using the !wdfkd.wdfrequest and !IRP commands, but I don’t know how I
can access the buffer with my information. I’m looking for a 16 byte
ascii string coming from my serial device, but I’m a bit confused,
because I receive this information with 3 requests. Any idears what I
have to do?
I’m not sure I understand the question. If you want to see the buffer
as returned from the device, then you need to look into the buffer after
the device is finished with it. That might be in your completion
routine, depending on whether you are doing the I/O yourself or asking
another driver to do it.
The !wdfrequest command should show you the output buffer; then you can
use something like !wdfmemory to find the address of the actual buffer.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
It depends on what mode you are using. If you are using buffered mode, the
buffer is available via the AssociatedIrp.SystemBuffer field of the IRP. If
you are using direct mode, it is encoded in the MDL, and you would typically
use MmGetSystemAddressForMdlSafe to get a kernel address for the buffer.
If you have a serial device, there is rarely a coupling between what is in
the buffer and what you expect to get as far as the byte count; it is a
stream-oriented device. If you are accessing the hardware directly, a
typical UART has a 16-deep FIFO, which may or may not be full. I’m not sure
what you mean by “three requests”.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hannes Finck
Sent: Friday, January 16, 2009 11:19 AM
To: Kernel Debugging Interest List
Subject: [windbg] Accessing Buffer of Request
Hi,
I want to access the buffer from a request I receive in a read dispatch
routine. Till now I only used WinDbg to display debug messages.
I’ve set a breakpoint in that dispatch routine and got some information
using the !wdfkd.wdfrequest and !IRP commands, but I don’t know how I can
access the buffer with my information. I’m looking for a 16 byte ascii
string coming from my serial device, but I’m a bit confused, because I
receive this information with 3 requests. Any idears what I have to do?
Thank you in advance,
Hannes
You are currently subscribed to windbg as: xxxxx@flounder.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.
Joe, kmdf takes care of getting the right input buffer for you from either location. You just ask the wdfrequest for an input or output buffer
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: Joseph M. Newcomer
Sent: Friday, January 16, 2009 8:15 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Accessing Buffer of Request
It depends on what mode you are using. If you are using buffered mode, the
buffer is available via the AssociatedIrp.SystemBuffer field of the IRP. If
you are using direct mode, it is encoded in the MDL, and you would typically
use MmGetSystemAddressForMdlSafe to get a kernel address for the buffer.
If you have a serial device, there is rarely a coupling between what is in
the buffer and what you expect to get as far as the byte count; it is a
stream-oriented device. If you are accessing the hardware directly, a
typical UART has a 16-deep FIFO, which may or may not be full. I’m not sure
what you mean by “three requests”.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hannes Finck
Sent: Friday, January 16, 2009 11:19 AM
To: Kernel Debugging Interest List
Subject: [windbg] Accessing Buffer of Request
Hi,
I want to access the buffer from a request I receive in a read dispatch
routine. Till now I only used WinDbg to display debug messages.
I’ve set a breakpoint in that dispatch routine and got some information
using the !wdfkd.wdfrequest and !IRP commands, but I don’t know how I can
access the buffer with my information. I’m looking for a 16 byte ascii
string coming from my serial device, but I’m a bit confused, because I
receive this information with 3 requests. Any idears what I have to do?
Thank you in advance,
Hannes
—
You are currently subscribed to windbg as: xxxxx@flounder.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.
—
You are currently subscribed to windbg as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Thanks. Still doesn’t clear up the issue of the ‘three requests’. That
sounds like one of the common misunderstandings of hardware I hit in almost
every class, such as as soon as the device interrupts, all the data is
present (the device generates one interrupt per byte, no onboard FIFO). It
also sounds analogous to a common question in the MFC NG, of the form “my
device sends a packet of N bytes on the serial port, but I get fewer than N
bytes on a ReadFile and have to do several ReadFiles to get all the bytes.
What’s wrong with ReadFile?”
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Saturday, January 17, 2009 3:06 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Accessing Buffer of Request
Joe, kmdf takes care of getting the right input buffer for you from either
location. You just ask the wdfrequest for an input or output buffer
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: Joseph M. Newcomer
Sent: Friday, January 16, 2009 8:15 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Accessing Buffer of Request
It depends on what mode you are using. If you are using buffered mode, the
buffer is available via the AssociatedIrp.SystemBuffer field of the IRP. If
you are using direct mode, it is encoded in the MDL, and you would typically
use MmGetSystemAddressForMdlSafe to get a kernel address for the buffer.
If you have a serial device, there is rarely a coupling between what is in
the buffer and what you expect to get as far as the byte count; it is a
stream-oriented device. If you are accessing the hardware directly, a
typical UART has a 16-deep FIFO, which may or may not be full. I’m not sure
what you mean by “three requests”.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hannes Finck
Sent: Friday, January 16, 2009 11:19 AM
To: Kernel Debugging Interest List
Subject: [windbg] Accessing Buffer of Request
Hi,
I want to access the buffer from a request I receive in a read dispatch
routine. Till now I only used WinDbg to display debug messages.
I’ve set a breakpoint in that dispatch routine and got some information
using the !wdfkd.wdfrequest and !IRP commands, but I don’t know how I can
access the buffer with my information. I’m looking for a 16 byte ascii
string coming from my serial device, but I’m a bit confused, because I
receive this information with 3 requests. Any idears what I have to do?
Thank you in advance,
Hannes
—
You are currently subscribed to windbg as: xxxxx@flounder.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.
—
You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.
I looked at the communication using IRP tracker and there i noticed that
my string from the serial device (16 byte) was splittet into three
IRP’s. My general question is how I get the serial out of my request. I
don’t know how I have to interprete the request’s buffer in my read
dispatch routine.
Regards
Hannes
Hannes Finck wrote:
I looked at the communication using IRP tracker and there i noticed
that my string from the serial device (16 byte) was splittet into
three IRP’s. My general question is how I get the serial out of my
request. I don’t know how I have to interprete the request’s buffer in
my read dispatch routine.
You need to remember how serial ports work. Serial ports do not
transmit in packets. They transmit bytes. There’s no way to know when
a transmission is finished, so the driver forwards data based on a
timeout. If your device sent 5 bytes, and then there was a timeout, the
driver would complete the IRP to return those 5 bytes. The device might
then send 6 more bytes before another timeout, causing another completion.
There’s nothing you can do about that. If you know you need 16 bytes,
then you have to accumulate the IRP returns in your own buffer
somewhere, until you get the number of bytes you need.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Actually, a serial port such as is used in COM1 only transmit bits and are
measured in bits per second (bps). A byte is built up by an agreed upon
format that is applied externally by the serial port controller such as
defining the start/stop bits. Bits are sheparded into a shift register by
using MARK/SPACE with or with out a clock tick. With a clock tick, makes it
synchronous, and without a clock tick makes it asynchronous. The start/stop
bits in async systems allow the “byte” to be formed and moved from the shift
register to an input register, or vice-verse for the transmit side.
Synchronous systems use the clock tick to determine a “byte” and once “n”
bits have been “clocked”, you have a byte.
Hmmm … rather simplistic, but my exeperience is that “serial ports” really
only deal with bits, or binary transitions such as HI/LO or MARK/SPACE and
“bytes” are defined by some externally applied definition.
But, you are correct on the use of timeouts. All of the serial com sytems I
have written use a 3 second character time out. The timeout causes
“something” to happen that is defined by an overriding protocol. If an IRP
is pending, then it will be completed, data copied to the IRP from a driver
defined holding buffer, and status set. If there is no IRP then ALL received
data MUST be moved from the data and any FIFO registers, copied into a
holding buffer and in/out indices in that holding buffer updated. If the OP
does not get the data length and or start stop bytes they are expecting then
they have a classic timeout and the overlying protocol should dictate what
to do like sending a NAK or ENQ.
–
The personal opinion of
Gary G. Little
“Tim Roberts” wrote in message news:xxxxx@windbg…
> Hannes Finck wrote:
>> I looked at the communication using IRP tracker and there i noticed
>> that my string from the serial device (16 byte) was splittet into
>> three IRP’s. My general question is how I get the serial out of my
>> request. I don’t know how I have to interprete the request’s buffer in
>> my read dispatch routine.
>
> You need to remember how serial ports work. Serial ports do not
> transmit in packets. They transmit bytes. There’s no way to know when
> a transmission is finished, so the driver forwards data based on a
> timeout. If your device sent 5 bytes, and then there was a timeout, the
> driver would complete the IRP to return those 5 bytes. The device might
> then send 6 more bytes before another timeout, causing another completion.
>
> There’s nothing you can do about that. If you know you need 16 bytes,
> then you have to accumulate the IRP returns in your own buffer
> somewhere, until you get the number of bytes you need.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
I think I need to simplify it a bit. Let’s say I get one char ‘a’ from
my device. I receive it as a request in my read dispatch routine and
want to read out the char. What do I have to do or how I have to
interprete the outputbuffer of the request.
Regars
Hannes
Gary G. Little schrieb:
Actually, a serial port such as is used in COM1 only transmit bits and
are measured in bits per second (bps). A byte is built up by an agreed
upon format that is applied externally by the serial port controller
such as defining the start/stop bits. Bits are sheparded into a shift
register by using MARK/SPACE with or with out a clock tick. With a clock
tick, makes it synchronous, and without a clock tick makes it
asynchronous. The start/stop bits in async systems allow the “byte” to
be formed and moved from the shift register to an input register, or
vice-verse for the transmit side. Synchronous systems use the clock tick
to determine a “byte” and once “n” bits have been “clocked”, you have a
byte.
Hmmm … rather simplistic, but my exeperience is that “serial ports”
really only deal with bits, or binary transitions such as HI/LO or
MARK/SPACE and “bytes” are defined by some externally applied definition.
But, you are correct on the use of timeouts. All of the serial com
sytems I have written use a 3 second character time out. The timeout
causes “something” to happen that is defined by an overriding protocol.
If an IRP is pending, then it will be completed, data copied to the IRP
from a driver defined holding buffer, and status set. If there is no IRP
then ALL received data MUST be moved from the data and any FIFO
registers, copied into a holding buffer and in/out indices in that
holding buffer updated. If the OP does not get the data length and or
start stop bytes they are expecting then they have a classic timeout and
the overlying protocol should dictate what to do like sending a NAK or ENQ.