is it the bug of wdk and wdm?

my application pragram set the buffer equal to the driver’s MAX_TRANSFER_SIZE,and

i modify the wdk’s usbsamp driver to my camera device.it is run well usually,but

when the request timeout,I can not receive any datas,the transfer size is zero.

is it the bug of wdk ,when my request timeout,it can not return the actual read

size?

for example, when my application buffer size is 65536,and the driver

MAX_TRANSFER_SIZE is also 65536 ,I mean I send the io request to the driver ,and the

driver don’t split the size and build the urb and send to the device. my question is

,when the io request timeout ,is it return any dadas?

at the same time ,I reduce the size of the device,such as ,let the device’s max

transfer size less than MAX_TRANSFER_SIZE,and at this time, every time the io

request timeout,and can not get any actual size but zero bytes.

so my confuse when the URB request is timeout ,why the transfer size is zero,
and in my opinion,when timeout,it may be receive some datas ,and the receive
data is less than the transfer size.

in my driver,it set the urbFlags |= USBD_SHORT_TRANSFER_OK;

is there anybody can tell me why ,and give me some advice?

and my camera transfer size is 2014208,
when it go well? the log is :
7122.797 Default UsbSamp: EvtDeviceFileCreate - begins
7122.797 Default UsbSamp: EvtDeviceFileCreate - ends
7122.797 Default UsbSamp: Entered UsbSamp_DispatchDevCtrl
7122.797 Default UsbSamp: Exit UsbSamp_DispatchDevCtrl
7122.797 Default UsbSamp: EvtDeviceFileCreate - begins
7122.797 Default UsbSamp: EvtDeviceFileCreate - ends
7122.797 Default UsbSamp: EvtDeviceFileCreate - begins
7122.797 Default UsbSamp: UsbSamp_PipeWithName - begins
7122.797 Default UsbSamp: Filename = \PIPE01 nameLength = 7
7122.797 Default UsbSamp: UsbSamp_PipeWithName - ends
7122.797 Default UsbSamp: EvtDeviceFileCreate - ends
7122.797 Default UsbSamp: UsbSamp_DispatchReadWrite - begins
7122.797 Default UsbSamp: Read operation
7122.797 Default UsbSamp: UsbSamp_DispatchReadWrite - ends
7122.875 Default UsbSamp: rwContext->UrbMemory = 77730D10
7122.875 Default UsbSamp: rwContext->Mdl = 88474008
7122.875 Default UsbSamp: rwContext->Length = 0
7122.875 Default UsbSamp: rwContext->Numxfer = 2014208
7122.875 Default UsbSamp: rwContext->VirtualAddress = 0146BC40
7122.875 Default UsbSamp: Read request completed with status 0x0

and when it timeout the log is :
7122.125 Default UsbSamp: EvtDeviceFileCreate - begins
7122.125 Default UsbSamp: EvtDeviceFileCreate - ends
7122.141 Default UsbSamp: Entered UsbSamp_DispatchDevCtrl
7122.141 Default UsbSamp: Exit UsbSamp_DispatchDevCtrl
7122.156 Default UsbSamp: EvtDeviceFileCreate - begins
7122.156 Default UsbSamp: EvtDeviceFileCreate - ends
7122.156 Default UsbSamp: EvtDeviceFileCreate - begins
7122.156 Default UsbSamp: UsbSamp_PipeWithName - begins
7122.156 Default UsbSamp: Filename = \PIPE01 nameLength = 7
7122.156 Default UsbSamp: UsbSamp_PipeWithName - ends
7122.156 Default UsbSamp: EvtDeviceFileCreate - ends
7122.156 Default UsbSamp: UsbSamp_DispatchReadWrite - begins
7122.156 Default UsbSamp: Read operation
7122.156 Default UsbSamp: UsbSamp_DispatchReadWrite - ends
7122.375 Default UsbSamp: status not success,and reset pipe
7122.375 Default UsbSamp: the transfer size is 0
7122.375 Default UsbSamp: rwContext->UrbMemory = 77730D10
7122.375 Default UsbSamp: rwContext->Mdl = 885B5008
7122.375 Default UsbSamp: rwContext->Length = 0
7122.375 Default UsbSamp: rwContext->Numxfer = 0
7122.375 Default UsbSamp: rwContext->VirtualAddress = 0146BC40
7122.375 Default UsbSamp: Read request completed with status 0xc00000b5
7122.375 Default UsbSamp: ReadWriteWorkItem called
7122.375 Default UsbSamp: ResetPipe - success

and another question, if the device send dada size less than the MAX_TRANSFER_SIZE of driver,

at this time ,is it the driver can not receive any dada? thank you?

> Re: is it the bug of wdk and wdm?
The DDK/WDK code is the base of hundreds, if not thousands of drivers.
Of course it will contain some bugs (hence UMDF and KMDF were designed),
but it is *much, much* more likely that something you did was wrong.

Tip1: Get an external USB analyzer and inspect the USB bus packages.

You want to know if the timeout behavior is caused by your code (in the
driver or in the device), or e.g. by some USB chip internal working, and
an external trace is the best way to find out.

Tip2: Use a second driver based on a different technology:

Before I updated/restructured our WDM driver, I made a “clean” UMDF
driver implementation. This did not take much time but proved extremely
helpful as a reference later. We need WDM for legacy support. If this is
not an issue for you, you are *way* better off with UMDF or KMDF anyway.

zhonghong200@163.com wrote:

and another question, if the device send dada size less than the MAX_TRANSFER_SIZE of driver,

at this time ,is it the driver can not receive any dada? thank you?

MAX_TRANSFER_SIZE is just a detail of the way usbsamp is implemented.
The device doesn’t know anything about it.

When you do a read from a bulk pipe, the device is never told how much
data you expect. It is simply given a signal that says “GO”. The
device starts transmitting. As long as it keeps sending full packets of
512 bytes, those packets will keep being added to the end of the current
transfer (until it fills up). If the device ever sends a packet that is
less than 512 bytes, that short packet will be added to the end of the
current transfer, and the transfer is considered to have been completed
normally. It will be returned to you with whatever data was sent.


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

thank you Hagen Patzke and Tim Roberts.

I am confused because my device run well in linux system, and it can return dada less than the MAX_TRANSFER_SIZE .and in windows system,I reduce the return size ,and let it less than the application buffer,at this time , the application can not receive any dada from the device. and in this time ,if i also reduce the application program buffer,and let it less than the device’s ability of the return size ,at this time ,the device can return dada?

and in the camera device,It return size is integral multiple of 512 bytes,so every packet is 512 bytes ,and the device not sends a packet that is less than 512 bytes. is it the reason that my device can not receive any data? thank you ?

In wdm or wdk 's usb driver,is it judge the transmission end based on the last tranfers packet less than 512 bytes?

thank you ,all my friends, and you are helpful and enthusiastic,thank you very much indeed.

hong zhong wrote:

In wdm or wdk 's usb driver,is it judge the transmission
end based on the last tranfers packet less than 512 bytes?

Yes, or the number of bytes that you originally requested has been returned to you. For example, say you send down a read URB for 2048 bytes. The URB will be handed completed back to you (with some partial or complete amount of data stored in it) if:

  1. The device sends 2048 bytes in the form of four 512 byte packets

  2. The device ever sends a packet less than 512 bytes (including zero), i.e. 512, 512, 3 == 1027 bytes received, or 512, 512, 512, 0 == 1536 bytes received.

Chris Aseltine ,thank you !

I am modify the wdk’s usbsamp driver for my camera device ,and the application buffer is 2014208 bytes. I change usbsamp’s MAX_TRANSFER_SIZE to 2014208,and usually run well,but some time IO request timeout ,and at this time ,it can not receive any datas.

I change MAX_TRANSFER_SIZE to 512,or 2048, It timeout every time ,but it can return some data which less than 2014208. I am confused why MAX_TRANSFER_SIZE influence the results?

and when MAX_TRANSFER_SIZE is smaller,it every time timeout ,is it stand for call Complete routine need much time. so I modify MAX_TRANSFER_SIZE to 2014208,at this time ,only call complete routine one time. but when it timeout ,will receive no dada.

it is very important to me when timeout ,it return dadas ,because i will according to the return size judge the next steps what run ,if the size is equal to the application buffer,i will receive another frame image,but if the size is not enough ,i will try to receive the image again. and zero ,i will do another works.

another question,I find in usbsamp ,when the status is not success,why the driver call QueuePassiveLevelCallback(WdfIoTargetGetDevice(Target), pipe) to reset the pipe,in my opinion,it will return with WdfRequestCompleteWithInformation(Request,status,dwreadsize)?

if (!NT_SUCCESS(status)){
//
// Queue a workitem to reset the pipe because the completion could be
// running at DISPATCH_LEVEL.
//
QueuePassiveLevelCallback(WdfIoTargetGetDevice(Target), pipe);
goto End;
}

i am confused ,and wish some body help me ,and thank you very much indeed.

I modify usbsamp ,and debug the program,when the io request timeout ,i want to receive the return dada size ,but it is zero. at this time , i want receive the dada size ,and according to next what to do?

if (!NT_SUCCESS(status)){
//
// Queue a workitem to reset the pipe because the completion could be
// running at DISPATCH_LEVEL.
//
UsbSamp_DbgPrint(1, (“status not success,and reset pipe\n”));
urb = (PURB) WdfMemoryGetBuffer(rwContext->UrbMemory, NULL);
bytesReadWritten = urb->UrbBulkOrInterruptTransfer.TransferBufferLength;
rwContext->Numxfer += bytesReadWritten;
UsbSamp_DbgPrint(1, (“the transfer size is %d\n”, rwContext->Numxfer));

QueuePassiveLevelCallback(WdfIoTargetGetDevice(Target), pipe);
goto End;
}

Send down a read of 512 bytes (short transfer OK as well). Do you get any data back?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of zhonghong200@163.com
Sent: Monday, August 23, 2010 11:28 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] is it the bug of wdk and wdm?

I modify usbsamp ,and debug the program,when the io request timeout ,i want to receive the return dada size ,but it is zero. at this time , i want receive the dada size ,and according to next what to do?

if (!NT_SUCCESS(status)){
//
// Queue a workitem to reset the pipe because the completion could be
// running at DISPATCH_LEVEL.
//
UsbSamp_DbgPrint(1, (“status not success,and reset pipe\n”));
urb = (PURB) WdfMemoryGetBuffer(rwContext->UrbMemory, NULL);
bytesReadWritten = urb->UrbBulkOrInterruptTransfer.TransferBufferLength;
rwContext->Numxfer += bytesReadWritten;
UsbSamp_DbgPrint(1, (“the transfer size is %d\n”, rwContext->Numxfer));

QueuePassiveLevelCallback(WdfIoTargetGetDevice(Target), pipe);
goto End;
}


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

thank you ,Doron Holan ,yes ,according to you method ,it is get dada back ,but the data is less than the appliction program buffer.

thank you ,every body,I am wait ,wait for you .

I would suggest you use a continuous reader on the endpoint and gather the data independently of the application and store it in a buffer. When the app requests data, you move it out of the buffer

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of zhonghong200@163.com
Sent: Tuesday, August 24, 2010 12:30 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] is it the bug of wdk and wdm?

thank you ,Doron Holan ,yes ,according to you method ,it is get dada back ,but the data is less than the appliction program buffer.

thank you ,every body,I am wait ,wait for you .


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

thank you Doron Holan ,continuous reader is not fit my camera.because the communication prototype .

who can help me ?

What are you asking about (there’s no history in your post)?

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of zhonghong200@163.com
Sent: Tuesday, August 24, 2010 8:56 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] is it the bug of wdk and wdm?

who can help me ?


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

to mm

my question :
(1)i modify the wdk’s usbsamp driver to my camera device.it is run well usually,but when the request timeout,I can not receive any datas,the transfer size is zero.is it the bug of wdk ,when my request timeout,it can not return the actual read size?

(2) I am modify the wdk’s usbsamp driver for my camera device ,and the
application buffer is 2014208 bytes. I change usbsamp’s MAX_TRANSFER_SIZE to
2014208,and usually run well,but some time IO request timeout ,and at this time
,it can not receive any datas. I change MAX_TRANSFER_SIZE to 512,or 2048, It timeout every time ,but it can return some data which less than 2014208. I am confused why MAX_TRANSFER_SIZE influence the results?

(3)I find in usbsamp ,when the status is not success,why the
driver call QueuePassiveLevelCallback(WdfIoTargetGetDevice(Target), pipe) to
reset the pipe,in my opinion,it will return with
WdfRequestCompleteWithInformation(Request,status,dwreadsize)?

if (!NT_SUCCESS(status)){
//
// Queue a workitem to reset the pipe because the completion could be
// running at DISPATCH_LEVEL.
//
QueuePassiveLevelCallback(WdfIoTargetGetDevice(Target), pipe);
goto End;
}

how to use continuous reade ,thank you .

Please look at the documentation on MSDN for all functions that operate on a WDFUSBPIPE. It will be clear which function you should call. After that, search for a sample in tue WDK that makes that API call.

d

dent from a phpne with no keynoard

-----Original Message-----
From: zhonghong200@163.com
Sent: August 25, 2010 6:14 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] is it the bug of wdk and wdm?

how to use continuous reade ,thank you .


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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

thank you

when my application buffer is not multiple of 512 bytes ,then error as :
Usts 12 00 00 c0 babble detected