camera usb driver based on bulkusb,but cancel the irp,why

Hi

I have built a bulk usb driver based on BulkUsb. I am developing it
for a bulk communication with my camera device.

I have Implemented that driver for 2014208 bytes size.my driver usually run well,but sometime when ReadWriteCompletion routines call,I find NT_SUCCESS(ntStatus)=FALSE,and it got cancelled status and a error code C0000120.

in this case,the driver return tranfer size is zero.

I have not define and canceling routine yet.

will is it the problem of my driver or may be something from device side? but it run well in linux system. my hardware team saying that the hardware is perfect.

please tell me what should be the solutions

Thanks

stone

NTSTATUS
BulkUsb_ReadWriteCompletion(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp,
IN PVOID Context
)
/*++

Routine Description:

This is the completion routine for reads/writes
If the irp completes with success, we check if we
need to recirculate this irp for another stage of
transfer. In this case return STATUS_MORE_PROCESSING_REQUIRED.
if the irp completes in error, free all memory allocs and
return the status.

Arguments:

DeviceObject - pointer to device object
Irp - I/O request packet
Context - context passed to the completion routine.

Return Value:

NT status value

–*/
{
ULONG stageLength;
NTSTATUS ntStatus;
PIO_STACK_LOCATION nextStack;
PBULKUSB_RW_CONTEXT rwContext;

//
// initialize variables
//
rwContext = (PBULKUSB_RW_CONTEXT) Context;
ntStatus = Irp->IoStatus.Status;

UNREFERENCED_PARAMETER(DeviceObject);

BulkUsb_DbgPrint(3, (“BulkUsb_ReadWriteCompletion - begins\n”));

//
// successfully performed a stageLength of transfer.
// check if we need to recirculate the irp.
//
if(NT_SUCCESS(ntStatus)) { //error NT_SUCCESS(ntStatus)=FALSE

if(rwContext) {

rwContext->Numxfer +=
rwContext->Urb->UrbBulkOrInterruptTransfer.TransferBufferLength;

if(rwContext->Length) {

//
// another stage transfer
//
BulkUsb_DbgPrint(3, (“Another stage transfer…\n”));

if(rwContext->Length > BULKUSB_MAX_TRANSFER_SIZE) {

stageLength = BULKUSB_MAX_TRANSFER_SIZE;
}
else {

stageLength = rwContext->Length;
}

IoBuildPartialMdl(Irp->MdlAddress,
rwContext->Mdl,
(PVOID) rwContext->VirtualAddress,
stageLength);

//
// reinitialize the urb
//
rwContext->Urb->UrbBulkOrInterruptTransfer.TransferBufferLength
= stageLength;
rwContext->VirtualAddress += stageLength;
rwContext->Length -= stageLength;

nextStack = IoGetNextIrpStackLocation(Irp);
nextStack->MajorFunction = IRP_MJ_INTERNAL_DEVICE_CONTROL;
nextStack->Parameters.Others.Argument1 = rwContext->Urb;
nextStack->Parameters.DeviceIoControl.IoControlCode =
IOCTL_INTERNAL_USB_SUBMIT_URB;

IoSetCompletionRoutine(Irp,
BulkUsb_ReadWriteCompletion,
rwContext,
TRUE,
TRUE,
TRUE);

IoCallDriver(rwContext->DeviceExtension->TopOfStackDeviceObject,
Irp);

return STATUS_MORE_PROCESSING_REQUIRED;
}
else {

//
// this is the last transfer
//

Irp->IoStatus.Information = rwContext->Numxfer;
}
}
}
else {

BulkUsb_DbgPrint(1, (“ReadWriteCompletion - failed with status = %X\n”, ntStatus)); //status =C0000120
}

if(rwContext) {

//
// dump rwContext
//
BulkUsb_DbgPrint(3, (“rwContext->Urb = %X\n”,
rwContext->Urb));
BulkUsb_DbgPrint(3, (“rwContext->Mdl = %X\n”,
rwContext->Mdl));
BulkUsb_DbgPrint(3, (“rwContext->Length = %d\n”,
rwContext->Length));
BulkUsb_DbgPrint(3, (“rwContext->Numxfer = %d\n”,
rwContext->Numxfer));
BulkUsb_DbgPrint(3, (“rwContext->VirtualAddress = %X\n”,
rwContext->VirtualAddress));
BulkUsb_DbgPrint(3, (“rwContext->DeviceExtension = %X\n”,
rwContext->DeviceExtension));

BulkUsb_DbgPrint(3, (“BulkUsb_ReadWriteCompletion::”));
BulkUsb_IoDecrement(rwContext->DeviceExtension);

ExFreePool(rwContext->Urb);
IoFreeMdl(rwContext->Mdl);
ExFreePool(rwContext);
}

BulkUsb_DbgPrint(3, (“BulkUsb_ReadWriteCompletion - ends\n”));

return ntStatus;
}

zhonghong200@163.com wrote:

I have built a bulk usb driver based on BulkUsb. I am developing it
for a bulk communication with my camera device.

Cameras should usually use isochronous pipes. If there is a retry, your
FIFOs will overflow.

I have Implemented that driver for 2014208 bytes size.my driver usually run well,but sometime when ReadWriteCompletion routines call,I find NT_SUCCESS(ntStatus)=FALSE,and it got cancelled status and a error code C0000120.

Well, this can’t happen for no reason. Someone has canceled the IRP.
What is happening at the time this happens? Have you killed the process
with Ctrl-C?

my hardware team saying that the hardware is perfect.

The hardware team usually says that. They are often wrong. I don’t
think that’s the case here, however.


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

Tim Roberts
thank you for you answer,may I ask you a question,if my application send a buffer to device hardware,the size is 2014208 bytes,but the maxinum data of the device hardware is less than 2014208,for example,is 1440254.at this time, my application program receive zero bytes dada,but in my opinion, the size must be 1440254.who can tell me why?
thank you very much indeed.

stone

@Tim: you say that “Cameras should usually use isochronous pipes. If there is a retry, your
FIFOs will overflow.”
I haven’t designed a USB camera yet, but what comes to my mind is, what happens if the iso pipe looses some data (and the host won’t retry) ?

Christoph

Hi ,
thank you for you answer,may I ask you another question,when I use driverstuio 3.2 and ddk to develop my driver,I found when I sumbiturb to windows lower driver,if timerout,I cannot get any data,and the receive size is zero byte,who can tell me why?
thank you very much indeed!

stone

Look, what you’re doing is a recipe for disaster. DriverStudio is
obsolete and unsupported product which was known to contain a lot of
bugs which were never fixed. BulkUsb is obsolete sample which was
removed from the WDK and which contained a lot of hard to debug and
solve bugs. Also, it is WDM driver which is unnecessarily complicated
for your purposes.

Why don’t you use up-to-date WDK and WDF driver, instead?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
zhonghong200@163.com
Sent: Saturday, August 14, 2010 3:25 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] camera usb driver based on bulkusb,but
cancel the irp,why

Hi ,
thank you for you answer,may I ask you another
question,when I use driverstuio 3.2 and ddk to develop my
driver,I found when I sumbiturb to windows lower driver,if
timerout,I cannot get any data,and the receive size is zero
byte,who can tell me why?
thank you very much indeed!

stone


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

+1

Good advice, and mind you that the bit about DriverStudio is coming from two
former avowed SoftICE people.

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Friday, August 13, 2010 9:59 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] camera usb driver based on bulkusb,but cancel the
irp,why

Look, what you’re doing is a recipe for disaster. DriverStudio is obsolete
and unsupported product which was known to contain a lot of bugs which were
never fixed. BulkUsb is obsolete sample which was removed from the WDK and
which contained a lot of hard to debug and solve bugs. Also, it is WDM
driver which is unnecessarily complicated for your purposes.

Why don’t you use up-to-date WDK and WDF driver, instead?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
zhonghong200@163.com
Sent: Saturday, August 14, 2010 3:25 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] camera usb driver based on bulkusb,but cancel the
irp,why

Hi ,
thank you for you answer,may I ask you another question,when I
use driverstuio 3.2 and ddk to develop my driver,I found when I
sumbiturb to windows lower driver,if timerout,I cannot get any
data,and the receive size is zero byte,who can tell me why?
thank you very much indeed!

stone


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


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

Start with the usbsamp sample in the 7.1 WDK.

d

dent from a phpne with no keynoard

-----Original Message-----
From: Michal Vodicka
Sent: August 13, 2010 7:00 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] camera usb driver based on bulkusb,but cancel the irp,why

Look, what you’re doing is a recipe for disaster. DriverStudio is
obsolete and unsupported product which was known to contain a lot of
bugs which were never fixed. BulkUsb is obsolete sample which was
removed from the WDK and which contained a lot of hard to debug and
solve bugs. Also, it is WDM driver which is unnecessarily complicated
for your purposes.

Why don’t you use up-to-date WDK and WDF driver, instead?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> zhonghong200@163.com
> Sent: Saturday, August 14, 2010 3:25 AM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] camera usb driver based on bulkusb,but
> cancel the irp,why
>
> Hi ,
> thank you for you answer,may I ask you another
> question,when I use driverstuio 3.2 and ddk to develop my
> driver,I found when I sumbiturb to windows lower driver,if
> timerout,I cannot get any data,and the receive size is zero
> byte,who can tell me why?
> thank you very much indeed!
>
> stone
>
> —
> 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
>


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 for you answer,may I ask you another question,when I use driverstuio 3.2

Forget this obsolete product and use KMDF instead.

It is known to have bugs, and not many people are using it and aware of these bugs. So, if you hit such a bug, then nearly nobody will help you, and you will lose much time discovering the cause of the bug.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

thank you for everybody reply,I find my appliction cancel the irp ,when is timeout ,I use CancelIo(handle) to cancel the irp.
I also have another question ,and I post a new thread,and look forward to hearing from you .
thanks

xxxxx@gmx.net wrote:

@Tim: you say that “Cameras should usually use isochronous pipes. If there is a retry, your
FIFOs will overflow.”
I haven’t designed a USB camera yet, but what comes to my mind is, what happens if the iso
pipe looses some data (and the host won’t retry) ?

In that case, the frame is dropped. That’s usually the best approach. With a live camera, the frame cannot be regenerated anyway – the data is gone for good. You’ll be getting a new frame by the time the next USB packet is requested. The same is true of audio data, which is why audio devices ALSO use isochronous pipes.

Note that, in real life, isochronous packets do not get dropped.

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

To the OP: The reason I asked this is because you didn’t specify whether your camera was something like a webcam or a still-image camera. For a webcam, it’s most likely OK to lose data here and then, see Tim’s post. Constant audio/video frame rate is more important.

For a still-image camera (ex: DSLRs), you want to have the USB retry on any corrupted data, that is, use bulk transfers.

Also, are you sure you can’t use WinUSB to do what you want to do ?
See here: http://www.microsoft.com/whdc/connect/usb/winusb_howto.mspx

Christoph