I have a METHOD_OUT_DIRECT IOCTL that is used to retrieve an image 1024x1280
in size. When the driver receives the IOCLT, I am using
WdfUsbTargetPipeReadSynchronously to transfer the image into a MDL but I get
the error 0xc0000004, STATUS_INFO_LENGTH_MISMATCH.
I’m assuming the error is because I’m doing something wrong with
initializing the MDL. But maybe I’m wrong and I shouldn’t be using the
WdfUsbTargetPipeReadSynchronously call. My question is, can an
appropriately initialized large MDL be filled in with data using
WdfUsbTargetPipeReadSynchronously where the multiple URBs required to get
the entire image and fill in the MDL will be taken care of or do I really
need to do an asynchronous call and take care of the offsets and such myself
for every URB being sent to retrieve the image? Which would be faster
assuming I can use the WdfUsbTargetPipeReadSynchronously call for this?
Dave
STATUS_INFO_LENGTH_MISMATCH is returned by KMDF when a Size field in a
structure is not set properly. The KMDF log should tell you what went
wrong. Set a bp right after the failed call and read
http://blogs.msdn.com/doronh/archive/2006/07/31/684531.aspx on how to
view the log.
As for your design questions, if this request is not instaneous, it is
better to asynchronously send the request and process the results in the
completion routine so that the calling thread is freed to do more work.
If you use the WDFMEMORY returned from
WdfRequestRetrieveInputMemory/WdfRequestRetrieveOutputMemory and specify
an offset using a WDFMEMORY_OFFSET, KMDF will send the request using the
MDL provided in the WDFMEMORY at the specified offset. You can send the
read down in one shot if the device is going to transfer it to the host
in one xfer.
d
– I can spell, I just can’t type.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Voeller
Sent: Monday, August 07, 2006 2:11 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] WdfUsbTargetPipeReadSynchronously and
STATUS_INFO_LENGTH_MISMATCH
I have a METHOD_OUT_DIRECT IOCTL that is used to retrieve an image
1024x1280 in size. When the driver receives the IOCLT, I am using
WdfUsbTargetPipeReadSynchronously to transfer the image into a MDL but I
get the error 0xc0000004, STATUS_INFO_LENGTH_MISMATCH.
I’m assuming the error is because I’m doing something wrong with
initializing the MDL. But maybe I’m wrong and I shouldn’t be using the
WdfUsbTargetPipeReadSynchronously call. My question is, can an
appropriately initialized large MDL be filled in with data using
WdfUsbTargetPipeReadSynchronously where the multiple URBs required to
get the entire image and fill in the MDL will be taken care of or do I
really need to do an asynchronous call and take care of the offsets and
such myself for every URB being sent to retrieve the image? Which would
be faster assuming I can use the WdfUsbTargetPipeReadSynchronously call
for this?
Dave
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
From the blog it looks like I need to have WPP tracing. When I started my
KMDF driver I had WPP tracing working. I have been working in the
traditional trace output to the debugger for quite awhile and now that I
have to go back to WPP tracing I’m finding out that something is broke
again. The KMDF log sounds promising so I will keep pursuing it.
As for the design, the image is ready to be retrieved and is being done as
fast the the USB 2.0 will perform so the synchronous method still sounds
like the best approach to me. Thanks for the input.
“Doron Holan” wrote in message
news:xxxxx@ntdev…
STATUS_INFO_LENGTH_MISMATCH is returned by KMDF when a Size field in a
structure is not set properly. The KMDF log should tell you what went
wrong. Set a bp right after the failed call and read
http://blogs.msdn.com/doronh/archive/2006/07/31/684531.aspx on how to
view the log.
As for your design questions, if this request is not instaneous, it is
better to asynchronously send the request and process the results in the
completion routine so that the calling thread is freed to do more work.
If you use the WDFMEMORY returned from
WdfRequestRetrieveInputMemory/WdfRequestRetrieveOutputMemory and specify
an offset using a WDFMEMORY_OFFSET, KMDF will send the request using the
MDL provided in the WDFMEMORY at the specified offset. You can send the
read down in one shot if the device is going to transfer it to the host
in one xfer.
d
– I can spell, I just can’t type.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Voeller
Sent: Monday, August 07, 2006 2:11 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] WdfUsbTargetPipeReadSynchronously and
STATUS_INFO_LENGTH_MISMATCH
I have a METHOD_OUT_DIRECT IOCTL that is used to retrieve an image
1024x1280 in size. When the driver receives the IOCLT, I am using
WdfUsbTargetPipeReadSynchronously to transfer the image into a MDL but I
get the error 0xc0000004, STATUS_INFO_LENGTH_MISMATCH.
I’m assuming the error is because I’m doing something wrong with
initializing the MDL. But maybe I’m wrong and I shouldn’t be using the
WdfUsbTargetPipeReadSynchronously call. My question is, can an
appropriately initialized large MDL be filled in with data using
WdfUsbTargetPipeReadSynchronously where the multiple URBs required to
get the entire image and fill in the MDL will be taken care of or do I
really need to do an asynchronous call and take care of the offsets and
such myself for every URB being sent to retrieve the image? Which would
be faster assuming I can use the WdfUsbTargetPipeReadSynchronously call
for this?
Dave
—
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
yes, to view the loggin in real time, you need WPP…*but* it is not required. you can just break in after the error and run !wdfkd.wdflogdump and the log is printed to the debugger.
d