Archived from groups: microsoft.public.development.device.drivers,microsoft.public.windowsxp.device_driver.dev (More info?)
I developed a USB driver for smartcard reader and it was running fine on
WinXP. It works fine on Win2k too if my reader is connected through a
hispeed hub. However, if I connect the reader to the root hub directly, the
driver would fail to load. I snooped around with SoftICE into the driver
stack and discovered that it is in OpenHCI that my IRP, or URB, failed a
parameter validation. Turns out that it does not take a buffer with size
greater than 64 bytes (possibly because the max packet size of of my bulk
input pipe is 64 bytess) and rejected my URB with STATUS_INVALID_PARAMETER
(0xc000000D).
When a reader is connected through a hub, openhci is not involved. My driver
passes the URB to usbport.sys instead.
Anybody out there experienced the same problem? I can provide more details
if anybody is interested.
Winston
Archived from groups: microsoft.public.development.device.drivers,microsoft.public.windowsxp.device_driver.dev (More info?)
Can you post code where you initialize URB and IRP?
"WT" <wyt168@earthlink.net> wrote in message
news:Vgugd.5799$kM.5639@newsread3.news.pas.earthlink.net...
>I developed a USB driver for smartcard reader and it was running fine on
>WinXP. It works fine on Win2k too if my reader is connected through a
>hispeed hub. However, if I connect the reader to the root hub directly, the
>driver would fail to load. I snooped around with SoftICE into the driver
>stack and discovered that it is in OpenHCI that my IRP, or URB, failed a
>parameter validation. Turns out that it does not take a buffer with size
>greater than 64 bytes (possibly because the max packet size of of my bulk
>input pipe is 64 bytess) and rejected my URB with STATUS_INVALID_PARAMETER
>(0xc000000D).
> When a reader is connected through a hub, openhci is not involved. My
> driver passes the URB to usbport.sys instead.
> Anybody out there experienced the same problem? I can provide more details
> if anybody is interested.
> Winston
>
Archived from groups: microsoft.public.development.device.drivers,microsoft.public.windowsxp.device_driver.dev (More info?)
The code to init IRP and URB are given below. I am wondering if OpenHCI will
handle data buffers bigger than the max packet size on the pipes. It appears
that it also does not like the buffer (512 bytes) I pass to the interrupt
pipe (with max packet size of 8 bytes). The usbport.sys, which my driver
calls on XP, handles bigger buffers just fine.
Now MS document on UsbBuildInterruptOrBulkTransferRequest does not put size
limit on the data buffer used. However, I am also highly suspicious that
this bug happens under special circustance--a bug like this would have been
spotted long time ago.
// routine to init and send URB
// Note: the call to read the response failed with
STATUS_INVALID_PARAMETER--the input buffer size (
// pReply->BufferSize is 0x120 (while my max packet size for the input pipe
is 64 bytes).
NTSTATUS
PcscSendSmartcardCommand(
PSMARTCARD_EXTENSION SmartcardExtension)
{
NTSTATUS status = STATUS_SUCCESS;
// We will wait for 1 min before the reader returns
LARGE_INTEGER timeOut;
// 1 min = 60 sec, in units of 100 nano sec
timeOut.QuadPart = -60 * 1000 * 1000 * 10;
// Send URB to USBD
NTSTATUS status = IoCallDriver(pdx->LowerDeviceObject, Irp);
if (status == STATUS_PENDING) {
status = KeWaitForSingleObject(
&event, Executive, KernelMode, FALSE, &timeOut);
if (status == STATUS_TIMEOUT) {
SmartcardDebug(DEBUG_INFO,
("%s!SendAwaitUrb: cmd time out, cancelling IRP\n", DRIVERNAME));
// We timed out, need to cancel the IRP
IoCancelIrp(Irp);
// Now wait for our completion routine to signal us
KeWaitForSingleObject(
&event, Executive, KernelMode, FALSE, NULL);
}
else {
// Since our completion routine returned STATUS_MORE_PROCESSING_NEEDED
that
// prevents USBD to finish the IRP, we need to do it here
IoCompleteRequest(Irp, IO_NO_INCREMENT);
}
}
else {
iostatus.Status = status;
}
status = iostatus.Status;
if (status != STATUS_SUCCESS)
SmartcardDebug(DEBUG_INFO,
("%s!SendAwaitUrb: err 0x%x\n", DRIVERNAME, status));
return status;
} // SendAwaitUrb
I traced the driver stack and found that the parameter validation happens in
openhci.sys. Here a dump from SoftICE:
:u openhci_queuetransfer l200
_OpenHCI_QueueTransfer
0008:EB6C3B3C PUSH EBP
0008:EB6C3B3D MOV EBP,ESP
0008:EB6C3B3F PUSH ECX
0008:EB6C3B40 PUSH ECX
0008:EB6C3B41 MOV EAX,[EBP+08]
0008:EB6C3B44 PUSH EBX
0008:EB6C3B45 PUSH ESI
0008:EB6C3B46 PUSH EDI
0008:EB6C3B47 MOV EDI,[EBP+0C] ; edi = IRP
0008:EB6C3B4A MOV EAX,[EAX+28]
0008:EB6C3B4D MOV DWORD PTR [EBP-04],00000103
0008:EB6C3B54 MOV [EBP-08],EAX
0008:EB6C3B57 MOV ECX,[EDI+60] ; ecx = IO_stack
0008:EB6C3B5A MOV ESI,[ECX+04] ; esi = URB
0008:EB6C3B5D MOV EBX,[ESI+28] ; HCA area, opapue to driver
"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:u0bmWZivEHA.3320@TK2MSFTNGP14.phx.gbl...
> Can you post code where you initialize URB and IRP?
>
> "WT" <wyt168@earthlink.net> wrote in message
> news:Vgugd.5799$kM.5639@newsread3.news.pas.earthlink.net...
>>I developed a USB driver for smartcard reader and it was running fine on
>>WinXP. It works fine on Win2k too if my reader is connected through a
>>hispeed hub. However, if I connect the reader to the root hub directly,
>>the driver would fail to load. I snooped around with SoftICE into the
>>driver stack and discovered that it is in OpenHCI that my IRP, or URB,
>>failed a parameter validation. Turns out that it does not take a buffer
>>with size greater than 64 bytes (possibly because the max packet size of
>>of my bulk input pipe is 64 bytess) and rejected my URB with
>>STATUS_INVALID_PARAMETER (0xc000000D).
>> When a reader is connected through a hub, openhci is not involved. My
>> driver passes the URB to usbport.sys instead.
>> Anybody out there experienced the same problem? I can provide more
>> details if anybody is interested.
>> Winston
>>
>
>
You are about to answer a thread that has been inactive for more than 6 months. If you still wish to proceed, please ensure that your posting is original and does not duplicate or overlap any prior responses to this thread.