usbsamp WdfRequestRetrieveOutputWdmMdl failure question

[gti4ever]

Hi there,

I am working on a new driver based on DDK usbsamp sample. I created a read
thread for reading the isochronous data from my USB device.

In my read thread, I have created a new request and memory object, then I
use WdfIoTargetFormatARequestForRead to format the request. After this, I
called the usbsamp PerformHighSpeedIsochTransfer() function to read the iso
data.

Everything seems to be fine until the WdfRequestRetrieveOutputWdmMdl() is
called. No matter what I do, it always return 0xc0000023
(STATUS_BUFFER_TOO_SMALL).

Following is the code that I used to create the new request:

WDF_OBJECT_ATTRIBUTES_INIT(&attributes);
WDF_OBJECT_ATTRIBUTES_SET_CONTEXT_TYPE(
&attributes,
REQUEST_CONTEXT
);
attributes.ParentObject = devExt->Device;

status = WdfRequestCreate(
&attributes,
WdfUsbTargetDeviceGetIoTarget(devExt->WdfUsbTargetDevice),
&newRequest);

if(!NT_SUCCESS(status)) {
UsbSamp_DbgPrint(1, ("WdfRequestreate failed to create a new request
%x!\n", status));
return;
}

WDF_OBJECT_ATTRIBUTES_INIT(&attributes);
attributes.ParentObject = newRequest;
status = WdfMemoryCreate(
&attributes,
NonPagedPool,
'TSET',
614400,
&memory,
NULL); // buffer pointer

if (!NT_SUCCESS(status)) {
UsbSamp_DbgPrint(1,("WdfMemoryCreate failed 0x%x\n", status));
return;
}

status = WdfIoTargetFormatRequestForRead(

WdfUsbTargetDeviceGetIoTarget(devExt->WdfUsbTargetDevice),
newRequest,
memory,
NULL, // Buffer offset
NULL); // OutputBufferOffset
if (!NT_SUCCESS(status)) {
UsbSamp_DbgPrint(1,("WdfIoTargetFormatRequestForRead failed 0x%x\n",
status));
return;
}

PerformHighSpeedIsochTransfer(devExt->Device,newRequest,614400,WdfRequestTypeRead);

Is the above code correct? What will be the cause of the 0xc0000023 error?

Thanks a lot.

G

[Doron Holan [MSFT]]

WdfRequestRetrieveOutputWdmMdl only works for requests presented to you via
a WDFQUEUE. it does not work with requests you create yourself (because
there is no current stack location which is formatted)

--

This posting is provided "AS IS" with no warranties, and confers no rights.

"gti4ever" <gti4...@discussions.microsoft.com> wrote in message
news:F09AD2C6-EC7C-4A3D...@microsoft.com...

[gti4ever]

Thanks Doron, that make sense.

My question now is: in this case, what should I do in order to read iso pipe
from a read thread? I am just trying to implement something like the
continuous reader for BULK and INT pipe.

Frank.

[Doron Holan [MSFT]]

format the request, send it down and set the WDFMEMORY you are using in the
read as the context for your io completion routine

d

--

This posting is provided "AS IS" with no warranties, and confers no rights.

"gti4ever" <gti4...@discussions.microsoft.com> wrote in message

news:E2B28013-C677-4F2A...@microsoft.com...

[gti4ever]

Hi Doron,

I have implemented the iso continuous reader by issueing multipe read
requests and resending the request inside the completion routine.

Now I have another question: In my completion routine, I copy all the data
acquired to a buffer in my device context. When the read request comes, it
will just read back the data in that buffer. What kind of synchronization
technique should I use to make sure I don't read the data from the buffer
when my completion routine is updating it?

I checked both waitlock and spinlock and found waitlock is only for
PASSIVE_LEVEL and spinlock is for DISPATCH_LEVEL or higher. Is there anything
else that I can use to sync between the IoRead and DPC (completion routine)?

Thanks.

G.

"Doron Holan [MSFT]" wrote:

> .
>

[Doron Holan [MSFT]]

use a spinlock to synchronize read/write access to the buffer in your device
context between the EvtIoRead routine and your read completion routine

d

--

This posting is provided "AS IS" with no warranties, and confers no rights.

"gti4ever" <gti4...@discussions.microsoft.com> wrote in message

news:8E2AEFBD-F92A-40DD...@microsoft.com...

[gti4ever]

Hi Doron,

The spinlock worked. However, now I am facing another issue. It seems like
my way of implementing the ISO continuous reader is not cencel-safe.

Since I am using driver created requests to read ISO stream, can I create a
manual queue and forward all the driver created requests to it and let
framework handles all the cancellation stuff?

Thanks.

G.

"Doron Holan [MSFT]" wrote:

> .
>

[Doron Holan [MSFT]]

if you created the request, only you can cancel them. the app will never
cancel request you created. if you want to cancel a request you sent down
the stack, call WdfRequestCancelSentRequest. you cannot put driver created
requests into a WDFQUEUE

d

--

This posting is provided "AS IS" with no warranties, and confers no rights.

"gti4ever" <gti4...@discussions.microsoft.com> wrote in message

news:FD680F4D-19AD-4843...@microsoft.com...

[gti4ever]

Sorry Doron, one last question.

I implemented the cancel function to cancel all the iso read requests and
everything seems to be ok and all the request objects got deleted at the end.

Now I found one critical issue. when I unplug my USB device when my iso
continuous reader is still reading, I can use D0Exit to cancel all the
pending read request and that seems to work ok and Windbg lm command shows
the driver got unloaded.

However, after this, if I plug back in my USB device and start the iso read
again, my driver crashes immediately. The minidump shows the driver crashed
either when my continuous reader trying to save the iso stream to the buffer
in device context or when the IoRead is trying to read the data from that
buffer.

I have only managed to reproduce this once or twice. According to Windbg,
all the buffer pointers seems to be reasonable, definitely not NULL. What
could cause this problem? Is it possible my driver is not unloaded correctly
and driver end up using some invalid/old context?

Thanks.

G.

"Doron Holan [MSFT]" wrote:

> .
>

[Doron Holan [MSFT]]

no idea what is going here unless you have stale pointers floating around in
your code and you are touching the old context from the now unplugged
device. do you have any global variables where you are storing WDF objects
or pointers?

--

This posting is provided "AS IS" with no warranties, and confers no rights.

"gti4ever" <gti4...@discussions.microsoft.com> wrote in message

news:B385710F-56E3-4DDA...@microsoft.com...