How to find the reason for status_invalid_para

NTDEV
1

Hi, all,

Nice to see you.

Recently, I write a USB driver, the enumerate part is ok, and get the pipe handle for bulk in and out.
While at first, I construct a URB and also allocate a IRP, then forward the irp(urb) to the bulk out pipe, in the completion routine, this irp return with the status == 0, it is a successfully irp.

But when I reuse the URB and the IRP, only the different lies in the URB
with different pipe, it is bulk in pipe now
and also the buffer(MDL), buffer length, and also flag (in, and short ok).

for the first URB, I use a none paged pool memory buffer, and its length, with flag is 0, and bulk out pipe.

for the second URB, I use pScsi_request_block->DataBuffer , databufferlength, flag in and short ok, and bulk in pipe, and always in the completion routine, the irp return with status = STATUS_INVALID_PARAMETER.

So I change the URB buffer parameter to NULL and with the MDL(2nd method)
and also I also allocate a buffer from none paged pool, and as the buffer parameter(3 method)

all of the three method for bulk in transfer is failed, with IRP status =STATUS_INVALID_PARAMETER.

Can any body tell me the reason:

  1. how to fix this bug?
  2. how to use the Windbg to figure out which parameter is invalid?

by the way
as for the SCSI_REQUEST_BLOCK i get from dispatch routine
and i stall this pointer for later use.
I have question
I found that the scsi_request_block->databuffer address = 0xba4f3960
does this address is a system address or a process specific address
because it is higher than 0x8000,0000, So i think it is a sysmte address, so i can use in arbitrary context, right?

2

workingmailing wrote:

Recently, I write a USB driver, the enumerate part is ok, and get the
pipe handle for bulk in and out.
While at first, I construct a URB and also allocate a IRP, then
forward the irp(urb) to the bulk out pipe, in the completion routine,
this irp return with the status == 0, it is a successfully irp.

But when I reuse the URB and the IRP, only the different lies in the URB
with different pipe, it is bulk in pipe now
and also the buffer(MDL), buffer length, and also flag (in, and short ok).

for the first URB, I use a none paged pool memory buffer, and its
length, with flag is 0, and bulk out pipe.

for the second URB, I use pScsi_request_block->DataBuffer ,
databufferlength, flag in and short ok, and bulk in pipe, and always
in the completion routine, the irp return with status =
STATUS_INVALID_PARAMETER.

So I change the URB buffer parameter to NULL and with the MDL(2nd method)
and also I also allocate a buffer from none paged pool, and as the
buffer parameter(3 method)

all of the three method for bulk in transfer is failed, with IRP
status =STATUS_INVALID_PARAMETER.

Can any body tell me the reason:

  1. how to fix this bug?
  2. how to use the Windbg to figure out which parameter is invalid?

I’m afraid your description is too vague to provide any details. You
would have to show us the source code before we could provide any
concrete advice.

I have question
I found that the scsi_request_block->databuffer address = 0xba4f3960
does this address is a system address or a process specific address
because it is higher than 0x8000,0000, So i think it is a sysmte
address, so i can use in arbitrary context, right?

In a normal 32-bit Windows system, yes

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

3

PURB CKUsbCtlBag::UsbPipe_BuildBulkRequest(PVOID pBuffer,PMDL pMDL, ULONG nBufferLength, BOOLEAN bIn, BOOLEAN bShortOk, PURB pUrb, USBD_PIPE_HANDLE PipeHandle)
{
PURB Urb=NULL;
USHORT UrbSize;
ULONG Flags;
UrbSize= sizeof(_URB_BULK_OR_INTERRUPT_TRANSFER);
if (pUrb == NULL)
{
Urb=(PURB) new (NON_PAGED_POOL) _URB_BULK_OR_INTERRUPT_TRANSFER;
}
else
{
Urb = pUrb;
}
if(Urb==NULL)
return Urb;
if (bIn)
{
Flags = USBD_TRANSFER_DIRECTION_IN;
if (bShortOk)
Flags |= USBD_SHORT_TRANSFER_OK;
}
else
{
Flags = 0;
}//build our urb for USBD
UsbBuildInterruptOrBulkTransferRequest(Urb,
UrbSize,
PipeHandle,
pBuffer,
pMDL,
nBufferLength,
Flags,
NULL);
Urb->UrbHeader.Status = 0;
//
return Urb;
}

NTSTATUS CKUsbCtlBag::UsbPipe_DispatchBulkIrp(PIO_COMPLETION_ROUTINE CompletionRoutine,PIRP_PENDING_CONTEXT pContext)
{
NTSTATUS ntStatus=STATUS_SUCCESS;
if(m_bIsDeviceRemoved)
{
return STATUS_DEVICE_NOT_CONNECTED;
}

//
PIRP pIrp= IoAllocateIrp(m_pTopDeviceObject->StackSize, FALSE);
if(pIrp == NULL)
{
DbgMsg((“@@@Warning:failed to alloc mem for irp!\n”));
return STATUS_INSUFFICIENT_RESOURCES;
}

pContext->pIrp = pIrp;
//
PIO_STACK_LOCATION pNextStack;
pNextStack = IoGetNextIrpStackLocation(pIrp);
//
// pass the URB to the USB driver stack
//
// Setup Irp
pNextStack->MajorFunction = IRP_MJ_INTERNAL_DEVICE_CONTROL;
pNextStack->Parameters.DeviceIoControl.IoControlCode = IOCTL_INTERNAL_USB_SUBMIT_URB;
pNextStack->Parameters.Others.Argument1 = pContext->pUrb;
ntStatus=USBD_SubmitIrpWithRoutine(pIrp,CompletionRoutine,pContext);
return ntStatus;
}

NTSTATUS CKUsbCtlBag::UsbPipe_ReuseBulkIrp(PIRP_PENDING_CONTEXT pContext)
{
// NTSTATUS ntStatus=STATUS_SUCCESS;
//UCHAR AllocationFlags;
// Reuse irp.
//AllocationFlags = pContext->pIrp->AllocationFlags;
//IoInitializeIrp(pContext->pIrp,
// IoSizeOfIrp(pContext->pIrp->StackCount),
// pContext->pIrp->StackCount);
//pContext->pIrp->AllocationFlags = AllocationFlags;
//pContext->pIrp->IoStatus.Status = STATUS_SUCCESS;

// Reuse irp.
IoReuseIrp(pContext->pIrp,STATUS_SUCCESS);

/*
//reuse urb
UsbPipe_BuildBulkRequest
(
pContext->pBuffer,
pContext->dwBufSize,
TRUE,
TRUE,
pContext->pUrb,
PipeHandle
);
*/
//
PIO_STACK_LOCATION nextStack;
nextStack = IoGetNextIrpStackLocation(pContext->pIrp);
nextStack->Parameters.Others.Argument1 = pContext->pUrb;
nextStack->Parameters.DeviceIoControl.IoControlCode =
IOCTL_INTERNAL_USB_SUBMIT_URB;
nextStack->MajorFunction = IRP_MJ_INTERNAL_DEVICE_CONTROL;
IoSetCompletionRoutine(pContext->pIrp,
UAS_DataCompletionRoutine,
pContext,
TRUE,
TRUE,
TRUE);
// Pass the IRP/URB to USBD
return(IoCallDriver(m_pTopDeviceObject,pContext->pIrp));
}

4

PURB CUASDevObject::AllocateUASCmdURB(PIRP_PENDING_CONTEXT pContext, USHORT stream_id)
{
PURB urb = NULL;
PDECODER_SCSI_REQUEST_BLOCK pDSrb = pContext->pDecodedSRB;
UCHAR addCdbLen = 0;
addCdbLen = pDSrb->CdbLength - 16;
if(addCdbLen < 0)
addCdbLen = 0;

ULONG siz = 0;
siz = IU_CMD_LEN + addCdbLen;
PCOMMAND_IU pCmdIU = (PCOMMAND_IU) new(NON_PAGED_POOL) BYTE[siz];
if(NULL == pCmdIU)
return NULL;

RtlZeroMemory(pCmdIU,siz);
pCmdIU->iu_id = IU_ID_COMMAND;
pCmdIU->tag = stream_id;
pCmdIU->prio_attr = UASP_TASK_SIMPLE;
pCmdIU->addCdbLen = addCdbLen;
pCmdIU->Lun[0] = 0;//fixed
RtlCopyMemory(pCmdIU->Cdb,pDSrb->CDB,pDSrb->CdbLength);

urb = m_pUsbCtrlBag->UsbPipe_BuildBulkRequest(pCmdIU,NULL, siz, FALSE, FALSE, NULL, m_pUsbCtrlBag->PipeHandle_Cmd);

return urb;
}

NTSTATUS UAS_CommandIUCompletionRoutine(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp,
IN PVOID Context
)
{
NTSTATUS ntStatus = Irp->IoStatus.Status;
UNREFERENCED_PARAMETER(DeviceObject);
PIRP_PENDING_CONTEXT pContext=(PIRP_PENDING_CONTEXT) Context;
DbgMsg((“Command IU completion routine\n”));

if(NT_SUCCESS(ntStatus)&&USBD_SUCCESS(pContext->pUrb->UrbHeader.Status))
{
DbgMsg((“Command One Irp succeed!\n”));

//Need data stage
if(pContext->pDecodedSRB->DataTransferLength&&pContext->pDecodedSRB->DataBuffer)
{

pContext->pUASDevObj->AllocateUASDataURB(pContext,(USHORT)pContext->pOrigIrp);
pContext->pUASDevObj->m_pUsbCtrlBag->UsbPipe_ReuseBulkIrp(pContext);

}
else//sense data stage
{

}

}
else//delete IRP
{
pContext->pUASDevObj->m_pUsbCtrlBag->UsbPipe_DeleteBulkIrp(pContext);
//return STATUS_CONTINUE_COMPLETION;
}

return STATUS_MORE_PROCESSING_REQUIRED;
}

NTSTATUS UAS_DataCompletionRoutine(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp,
IN PVOID Context
)
{
NTSTATUS ntStatus = Irp->IoStatus.Status;
UNREFERENCED_PARAMETER(DeviceObject);
PIRP_PENDING_CONTEXT pContext=(PIRP_PENDING_CONTEXT) Context;
DbgMsg((“Data transfer completion routine\n”));

if(NT_SUCCESS(ntStatus)&&USBD_SUCCESS(pContext->pUrb->UrbHeader.Status))
{
DbgMsg((“Data One Irp succeed!\n”));
DbgMsg((“Actual bulk data number %d \n”,pContext->pUrb->UrbBulkOrInterruptTransfer.TransferBufferLength));
}
else
{
pContext->pUASDevObj->m_pUsbCtrlBag->UsbPipe_DeleteBulkIrp(pContext);
//return STATUS_CONTINUE_COMPLETION;
}
return STATUS_MORE_PROCESSING_REQUIRED;
}

5

PURB CUASDevObject::AllocateUASDataURB(PIRP_PENDING_CONTEXT pContext, USHORT stream_id)
{
PURB urb = NULL;
PMDL pMdl = NULL;
UNREFERENCED_PARAMETER(stream_id);
PVOID pbuffer = pContext->pDecodedSRB->DataBuffer;
if(MmGetMdlVirtualAddress(pContext->pOrigIrp->MdlAddress) == pContext->pDecodedSRB->DataBuffer)
{
pMdl = pContext->pOrigIrp->MdlAddress;
pbuffer = NULL;
}
else
{
pMdl = IoAllocateMdl(pContext->pDecodedSRB->DataBuffer,pContext->pDecodedSRB->DataTransferLength,
0,0,0);
if(!pMdl)
pContext->pUASDevObj->m_pUsbCtrlBag->UsbPipe_DeleteBulkIrp(pContext);

IoBuildPartialMdl(pContext->pOrigIrp->MdlAddress,pMdl,
pContext->pDecodedSRB->DataBuffer,
pContext->pDecodedSRB->DataTransferLength);

pbuffer = NULL;
}

//data in
if(pContext->pDecodedSRB->SrbFlags&SRB_FLAGS_DATA_IN)
{
pContext->pUASDevObj->m_pUsbCtrlBag->UsbPipe_BuildBulkRequest(
pbuffer,//pContext->pDecodedSRB->DataBuffer,//buffer
pMdl,
pContext->pDecodedSRB->DataTransferLength,
TRUE,
TRUE,
pContext->pUrb,
pContext->pUASDevObj->m_pUsbCtrlBag->PipeHandle_DataIn
);
}
else if(pContext->pDecodedSRB->SrbFlags&SRB_FLAGS_DATA_OUT)
{
pContext->pUASDevObj->m_pUsbCtrlBag->UsbPipe_BuildBulkRequest(
pbuffer,//pContext->pDecodedSRB->DataBuffer,
pMdl,
pContext->pDecodedSRB->DataTransferLength,
FALSE,
FALSE,
pContext->pUrb,
pContext->pUASDevObj->m_pUsbCtrlBag->PipeHandle_DataOut
);
}
return urb = pContext->pUrb;

}

6

PURB pUrb = AllocateUASCmdURB( pPendingContext, USHORT(pPendingContext->pOrigIrp));
pPendingContext->pUrb = pUrb;
pPendingContext->pUASDevObj = this;
m_pUsbCtrlBag->UsbPipe_DispatchBulkIrp(UAS_CommandIUCompletionRoutine,pPendingContext);

while in the UAS_CommandIUCompletionRoutine, irp is ok
but in the UAS_DataCompletionRoutine , irp return wtih status_invalid_parameter

The wholse procedure is

build a command IU
build a URB
build a IRP
forward to lower level, this is for bulk out pipe, it is successful

then in the command IoCompletion routine UAS_CommandIUCompletionRoutine,
reuse the URB, reuse the IRP
now it is for bulk in pipe
forward to lower level,
in UAS_DataCompletionRoutine IRP failed with status_invalid_parameter

Question:

  1. how to fix this bug?
  2. how to use the Windbg to figure out which parameter is invalid?
7

hi, all

use the same method, for bulk out it is ok, but for bulk in it is no ok.

8

workingmailing@163.com wrote:

PURB pUrb = AllocateUASCmdURB( pPendingContext, USHORT(pPendingContext->pOrigIrp));
pPendingContext->pUrb = pUrb;
pPendingContext->pUASDevObj = this;
m_pUsbCtrlBag->UsbPipe_DispatchBulkIrp(UAS_CommandIUCompletionRoutine,pPendingContext);

while in the UAS_CommandIUCompletionRoutine, irp is ok
but in the UAS_DataCompletionRoutine , irp return wtih status_invalid_parameter

In UAS_CommandIUCompletionRoutine, you call AllocateUASDataURB and then
UsbPipe_ReuseBulkIrp. You didn’t show us AllocateUASDataURB, so we
don’t know what that does. UsbPipe_ReuseBulkIrp assumes that
pContext->pUrb is still set up. Do you reset any of the fields in
there? Does AllocateUASDataUrb actually allocate a new URB?

I was amused to see this:
Urb=(PURB) new (NON_PAGED_POOL) _URB_BULK_OR_INTERRUPT_TRANSFER;

Why NON_PAGED_POOL instead of NonPagedPool, which is the DDK symbol?
Did you define your own aliases?

I was also amused to see this:

pContext->pUASDevObj->m_pUsbCtrlBag->UsbPipe_ReuseBulkIrp(pContext);
You don’t often see three -> operators in one expression.

The wholse procedure is

build a command IU
build a URB
build a IRP
forward to lower level, this is for bulk out pipe, it is successful

then in the command IoCompletion routine UAS_CommandIUCompletionRoutine,
reuse the URB, reuse the IRP
now it is for bulk in pipe

Who does that last step? I don’t see it in the code you posted.

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

9

resend allocate uas data urb
this urb is also use the former URB for command IU urb

PURB CUASDevObject::AllocateUASDataURB(PIRP_PENDING_CONTEXT pContext, USHORT
stream_id)
{
PURB urb = NULL;
PMDL pMdl = NULL;
UNREFERENCED_PARAMETER(stream_id);
PVOID pbuffer = pContext->pDecodedSRB->DataBuffer;
if(MmGetMdlVirtualAddress(pContext->pOrigIrp->MdlAddress) ==
pContext->pDecodedSRB->DataBuffer)
{
pMdl = pContext->pOrigIrp->MdlAddress;
pbuffer = NULL;
}
else
{
pMdl =
IoAllocateMdl(pContext->pDecodedSRB->DataBuffer,pContext->pDecodedSRB->DataTransf
erLength,
0,0,0);
if(!pMdl)
pContext->pUASDevObj->m_pUsbCtrlBag->UsbPipe_DeleteBulkIrp(pContext);

IoBuildPartialMdl(pContext->pOrigIrp->MdlAddress,pMdl,
pContext->pDecodedSRB->DataBuffer,
pContext->pDecodedSRB->DataTransferLength);

pbuffer = NULL;
}

//data in
if(pContext->pDecodedSRB->SrbFlags&SRB_FLAGS_DATA_IN)
{
pContext->pUASDevObj->m_pUsbCtrlBag->UsbPipe_BuildBulkRequest(
pbuffer,//pContext->pDecodedSRB->DataBuffer,//buffer
pMdl,
pContext->pDecodedSRB->DataTransferLength,
TRUE,
TRUE,
pContext->pUrb,
pContext->pUASDevObj->m_pUsbCtrlBag->PipeHandle_DataIn
);
}
else if(pContext->pDecodedSRB->SrbFlags&SRB_FLAGS_DATA_OUT)
{
pContext->pUASDevObj->m_pUsbCtrlBag->UsbPipe_BuildBulkRequest(
pbuffer,//pContext->pDecodedSRB->DataBuffer,
pMdl,
pContext->pDecodedSRB->DataTransferLength,
FALSE,
FALSE,
pContext->pUrb,
pContext->pUASDevObj->m_pUsbCtrlBag->PipeHandle_DataOut
);
}
return urb = pContext->pUrb;

}

10

workingmailing@163.com wrote:

resend allocate uas data urb
this urb is also use the former URB for command IU urb

You are setting both a virtual address and an MDL. You should use one
or the other. Since you already have the virtual address, just skip the
MDL and pass NULL.

Except for the few nit-picky things I pointed out, I don’t see any
gaping problems. You need to use a debugger or debug prints to print
the contents of the URB and see if anything looks odd. Compare the pipe
handles. Make sure the buffer pointers are right.

This statement is silly:

return urb = pContext->pUrb;

There’s no point in storing the pointer in a local variable if you are
returning immediately.

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

11

Thank you Tim.

In fact, if MDL of the buffer is exist or could be created, I will set buffer pointer as NULL.
In my remember, compare to buffer, MDL will lock the page, and data transfer is more quick than buffer method, does it apply to this case?
This code was fecth from a USB Bulk only stroage device driver sample.

It is wired, for OUT bulk URB it is right for transfer,but not for in transfer, I have deeply debugging with WINDBG, and watch the value of BULK URB.

Maybe more deep researching will be done.

BTW, there are 4 pipe handle, two out two in, maybe the last step for me is change another in handle for a try.

12

workingmailing@163.com wrote:

In fact, if MDL of the buffer is exist or could be created, I will set buffer pointer as NULL.
In my remember, compare to buffer, MDL will lock the page, and data transfer is more quick than buffer method, does it apply to this case?

The performance difference is not worth worrying about

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

13

it is still haunting me the IN URB still could not success.

And I tried the other in pipe for this data in transfer, still failed.

14

Hi, Tim,

There are 4 pipe, two out: cmd and data out, two in data in and status.

Even though I tried on data in and status in, and also data out, they are all faild with the same “STATUS_INVALID_PARAMETER” and “USBD_INVALID_PARAMETER”.

But I found another wired case:
When call the following function, I change the data in pipe to cmd pipe
even though I set the parameter “bIN” and “short OK”, to “TRUE”
but bulk out URB happened instead of bulk in. and this bulk out urb,irp is successful.

but it is a unuseful successful, which transfer out 8 bytes from pbuffer, which originally want to receive 8 bytes from usb device and store the 8 bytes recevied bytes into pbuffer.

pContext->pUASDevObj->m_pUsbCtrlBag->UsbPipe_BuildBulkRequest(
pbuffer,//pContext->pDecodedSRB->DataBuffer,//buffer
pMdl,
pContext->pDecodedSRB->DataTransferLength,
TRUE,
TRUE,
pContext->pUrb,
pContext->pUASDevObj->m_pUsbCtrlBag->PipeHandle_DataIn
);

15

workingmailing@163.com wrote:

There are 4 pipe, two out: cmd and data out, two in data in and status.

Even though I tried on data in and status in, and also data out, they are all faild with the same “STATUS_INVALID_PARAMETER” and “USBD_INVALID_PARAMETER”.

But I found another wired case:
When call the following function, I change the data in pipe to cmd pipe
even though I set the parameter “bIN” and “short OK”, to “TRUE”
but bulk out URB happened instead of bulk in. and this bulk out urb,irp is successful.

It sounds to me like you are not using the pipe handles that you think
you are. How are you finding the pipe handles? Remember that Windows
returns the pipes to you in the order they occur in the descriptors.
That’s not always what you expect.

Can you show us the code where you parse the select_configuration
results and locate the pipe handles?

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

16

Maybe my descriptoion is not so good for you to understand.

  1. There are 4 pipe handle, cmd and data out bulk out pipe, and status data in bulk in pipe.
    What I want to do is
    using cmd bulk out pipe send out the URB( include the SCSI CDB, such as read capacity) to the device, then using data in bulk in pipe read back 8 bytes data for the “read capacity” CDB command.

while the cmd bulk out send successfully.
but it is failed to read back using the data in pipe.

then I change the data in pipe handle with othe pipe handle, status in and data out and also cmd out, for status in and data out, it is also faild with invalid parameter.
For cmd out pipe handle, even thought I set the URB flag IN and SHORT OK, the actual action is not data in, but data out.

So I install the Bushound, it seems that maybe the device do not implement UAS protocol correctlly.
UAS protocol need to send cmd out then read back by data in pipe.
But from bushound, I could see one cmd out and two control transfer after that, every time, it is like this, one cmd out and two control transfer, without data in.

Bus Hound 6.01 capture on Windows XP Service Pack 3 (x86). Complements of www.perisoft.net

Device - Device ID (followed by the endpoint for USB devices)
(11) Renesas Electronics USB 3.0 Host Controller
(32) UAS MassStorage Device
(33) USB 3.0 USB300 UAS [ROM=0100]
Address - FireWire async address or channel number
Length - Total transfer length
Phase - Phase Type
ATA ATA task file command RESET bus reset
CMD SCSI/ATAPI command SRB SCSI request block
CTL USB control transfer SSTS SCSI request block status
IN Data in transfer URB USB request block
OUT Data out transfer USTS USB status
Data - Hex dump of the data transferred
Descr - Description of the phase
Delta - Elapsed time from the previous phase to the current phase
Cmd… - Position in the captured data
Date - Date the phase occurred in year-month-day form
Time - Time the phase occurred in hour:minute:second.millisec form
Driver - Driver that submitted the command
uasfilt : UAS Filter Driver 1.0.00.0 built by: WinDDK
usbstor : USB Mass Storage Class Driver 5.1.2600.5512 (xpsp.080413-2108)
disk : PnP Disk Driver 5.1.2600.5512 (xpsp.080413-2108)

Device Address Length Phase Data Description Delta Cmd.Phase.Ofs(rep) Date Time Driver

32.1 32 OUT 01 00 00 1f 00 00 00 00 00 00 00 00 00 00 00 00 … 78us 8595.1.0 2011-07-25 10:08:11.516 uasfilt
2a 00 00 03 f7 5f 00 00 08 00 00 00 00 00 00 00 *…_… 8595.1.16
32.1 URB 48 00 09 00 00 00 00 00 c0 09 e2 82 10 00 00 00 BULK/INT XFER 1us 8595.2.0 2011-07-25 10:08:11.516
1c 6c 0a 83 00 00 00 00 20 00 00 00 20 ca 45 f9 8595.2.16
00 00 00 00 00 00 00 00 08 00 09 83 48 5e 6a fc 8595.2.32
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8595.2.48
00 00 00 00 00 00 00 00 8595.2.64
32.0 URB 60 00 00 80 00 00 00 00 c0 09 e2 82 10 00 00 00 181us 8596.1.0 2011-07-25 10:08:11.516 uasfilt
54 6c 0a 83 00 00 00 00 00 10 00 00 00 00 00 00 8596.1.16
b8 be 9d fd 00 00 00 00 78 75 a7 f9 30 6d 39 fb 8596.1.32
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8596.1.48
00 00 00 00 00 00 00 00 1f 00 00 00 00 00 00 00 8596.1.64
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8596.1.80
32.0 URB 60 00 00 80 00 00 00 00 c0 09 e2 82 10 00 00 00 10us 8597.1.0 2011-07-25 10:08:11.516 uasfilt
70 6c 0a 83 03 00 00 00 08 00 00 00 c0 89 48 f9 8597.1.16
00 00 00 00 00 00 00 00 00 65 39 fb 08 00 4a fc 8597.1.32
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8597.1.48
00 00 00 00 00 00 00 00 1f 00 00 00 00 00 00 00 8597.1.64

17

It seems that this case use the upper and lower filter method
and both using the same uasfilt.sys

send again:
Bus Hound 6.01 capture on Windows XP Service Pack 3 (x86). Complements of www.perisoft.net

Device - Device ID (followed by the endpoint for USB devices)
(11) Renesas Electronics USB 3.0 Host Controller
(32) UAS MassStorage Device
(33) USB 3.0 USB300 UAS [ROM=0100]
Address - FireWire async address or channel number
Length - Total transfer length
Phase - Phase Type
ATA ATA task file command RESET bus reset
CMD SCSI/ATAPI command SRB SCSI request block
CTL USB control transfer SSTS SCSI request block status
IN Data in transfer URB USB request block
OUT Data out transfer USTS USB status
Data - Hex dump of the data transferred
Descr - Description of the phase
Delta - Elapsed time from the previous phase to the current phase
Cmd… - Position in the captured data
Date - Date the phase occurred in year-month-day form
Time - Time the phase occurred in hour:minute:second.millisec form
Driver - Driver that submitted the command
uasfilt : UAS Filter Driver 1.0.00.0 built by: WinDDK
usbstor : USB Mass Storage Class Driver 5.1.2600.5512 (xpsp.080413-2108)
disk : PnP Disk Driver 5.1.2600.5512 (xpsp.080413-2108)

Device Address Length Phase Data Description Delta Cmd.Phase.Ofs(rep) Date Time Driver

32.1 32 OUT 01 00 00 1f 00 00 00 00 00 00 00 00 00 00 00 00 … 78us 8595.1.0 2011-07-25 10:08:11.516 uasfilt
2a 00 00 03 f7 5f 00 00 08 00 00 00 00 00 00 00 *…_… 8595.1.16
32.1 URB 48 00 09 00 00 00 00 00 c0 09 e2 82 10 00 00 00 BULK/INT XFER 1us 8595.2.0 2011-07-25 10:08:11.516
1c 6c 0a 83 00 00 00 00 20 00 00 00 20 ca 45 f9 8595.2.16
00 00 00 00 00 00 00 00 08 00 09 83 48 5e 6a fc 8595.2.32
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8595.2.48
00 00 00 00 00 00 00 00 8595.2.64
32.0 URB 60 00 00 80 00 00 00 00 c0 09 e2 82 10 00 00 00 181us 8596.1.0 2011-07-25 10:08:11.516 uasfilt
54 6c 0a 83 00 00 00 00 00 10 00 00 00 00 00 00 8596.1.16
b8 be 9d fd 00 00 00 00 78 75 a7 f9 30 6d 39 fb 8596.1.32
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8596.1.48
00 00 00 00 00 00 00 00 1f 00 00 00 00 00 00 00 8596.1.64
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8596.1.80
32.0 URB 60 00 00 80 00 00 00 00 c0 09 e2 82 10 00 00 00 10us 8597.1.0 2011-07-25 10:08:11.516 uasfilt
70 6c 0a 83 03 00 00 00 08 00 00 00 c0 89 48 f9 8597.1.16
00 00 00 00 00 00 00 00 00 65 39 fb 08 00 4a fc 8597.1.32
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8597.1.48
00 00 00 00 00 00 00 00 1f 00 00 00 00 00 00 00 8597.1.64

18

I was wonder this URB(32.0) is a vendor request?
But where is the data in ?
Is the bushound do some thing wrong, and could not catch the 32.1 in data?

19

length 48, it is a bulk URB
length 60, it seems it is a ISO urb, but why EP0 could use iso urb

20

workingmailing@163.com wrote:

length 48, it is a bulk URB
length 60, it seems it is a ISO urb, but why EP0 could use iso urb

Where on earth did you get the idea that it was an ISO URB? That’s just
silly.

Control endpoint requests can have up to 64 bytes of data.

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