some unknown IRP

NTDEV
1

Recently, I use a usb storage device

it install the same binary filter driver for upper and lower of USBSTOR.sys.

Before it read and write data with BULK urb, always two IRP precede the read write IRP/URB pair:

The follwing is dump from IRPTRACE.

Can some one tell me what these two IRP the function?

And also, for the second IRP, because there exist upper and lower filter driver use the same binary, so does they have the same FDO device name?

I figure the seconde IRP is send by the upper filter to the lower filter, does it right for my guess?

First One is

General description

Major function
IRP_MJ_INTERNAL_DEVICE_CONTROL

Minor function
00h

Target Device
#FC9E6708 (UASFILT)

State
Completed

Status
STATUS_SUCCESS

Information
0h

Sent
2011-7-28 16:45:19:99

by
CLASSPNP.SYS!ClassCompleteRequest+3FA (BA108FDD)

process
System(4h)

thread
A34h

at IRQL
APC_LEVEL

Completion routine
CLASSPNP.SYS!ClassCompleteRequest+22E

Control Flags
SL_INVOKE_ON_CANCEL
SL_INVOKE_ON_SUCCESS
SL_INVOKE_ON_ERROR

Completed
2011-7-28 16:45:19:99

by
uasfilt.sys!+9255h (A71A2255)

process
irptrace.exe(CE4h)

thread
DCCh

at IRQL
DISPATCH_LEVEL

priority boost
0h

Input Parameters

IoControlCode
IOCTL_CDROM_SUB_Q_CHANNEL

Value
0h

Device type
0

File Access
FILE_ANY_ACCESS

Function
0h

Method
METHOD_BUFFERED

Buffer
In: 0h Out: 83A2945Ch

Output buffer length
83A2945Ch

Input buffer length
0h

SystemBuffer
0h

THE 2nd is:

General description

Major function
IRP_MJ_INTERNAL_DEVICE_CONTROL

Minor function
00h

Target Device
#FCA4B020 (UASFILT)

State
Completed

Status
STATUS_SUCCESS

Information
0h

Sent
2011-7-28 16:45:19:99

by
uasfilt.sys!+9456h (A71A2456)

process
System(4h)

thread
A34h

at IRQL
DISPATCH_LEVEL

Completion routine
uasfilt.sys!+91E4h

Control Flags
SL_INVOKE_ON_CANCEL
SL_INVOKE_ON_SUCCESS
SL_INVOKE_ON_ERROR

Completed
2011-7-28 16:45:19:99

by
uasfilt.sys!+4ED2h (A719DED2)

process
irptrace.exe(CE4h)

thread
DCCh

at IRQL
DISPATCH_LEVEL

priority boost
0h

Input Parameters

IoControlCode
IOCTL_0x222573

Value
222573h

Device type
FILE_DEVICE_UNKNOWN

File Access
FILE_ANY_ACCESS

Function
95Ch

Method
METHOD_NEITHER

Buffer
In: 0h Out: 83A2945Ch

Output buffer length
83A2945Ch

Input buffer length
0h

Type3InputBuffer
0h

SystemBuffer
0h

2

workingmailing wrote:

Recently, I use a usb storage device

it install the same binary filter driver for upper and lower of
USBSTOR.sys.

Before it read and write data with BULK urb, always two IRP precede
the read write IRP/URB pair:

The follwing is dump from IRPTRACE.

Can some one tell me what these two IRP the function?

No. The first one has an ioctl code of 0. It’s coming from the PnP
class driver, so it may be some magic PnP thing. Do you have driver
verifier on? This could be a verifier thing.

The second one has an ioctl code of 0x222573, which is not a standard
ioctl code. It’s some custom code.

And also, for the second IRP, because there exist upper and lower
filter driver use the same binary, so does they have the same FDO
device name?

They have the same file name. Is that what you mean?

I figure the seconde IRP is send by the upper filter to the lower
filter, does it right for my guess?

There’s no way for us to know. That would be quite a gamble, since it
assumes that the driver in the middle will pass along ioctls that it
doesn’t understand. That’s not the normal procedure.

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

3

Yes, I figure they have the same file name.
because in the IRPTRACE, i can distinguish who this the upper and who is the lower.

as we known, USBSTOR.SYS is a bus type driver, not a filter driver
So if the upper filter issue a IRP, it will completed by USBSTOR.SYS for this driver don’t support.
Therefore i think this irp should not pass throught the USBSTOR.SYS, but directly forward to lowerfilter.

4

driver verify not on.

5

The first one is send by classpnp.sys, it is a storage class driver, which do not create FDO,PDO.
what does IOCTL_CDROM_SUB_Q_CHANNEL use for?

6

workingmailing@163.com wrote:

Yes, I figure they have the same file name.
because in the IRPTRACE, i can distinguish who this the upper and who is the lower.

as we known, USBSTOR.SYS is a bus type driver, not a filter driver
So if the upper filter issue a IRP, it will completed by USBSTOR.SYS for this driver don’t support.
Therefore i think this irp should not pass throught the USBSTOR.SYS, but directly forward to lowerfilter.

Right, which suggests there’s something else going on here. Have you hooked up a debugger to trace the stack here?

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

7

hi, a good news.

I send a query interface IRP forward to usb stack in my driver.
It is successful, and the interface structure data original is zerod, filled by host driver with kernel sapce address.

but none of the function pointer could let me transfer the bulk stream urb.

on the other hand, if i use the interface function pointer, I can not see URB dump in BUSHOUND.

So, i think, BULK STREAM URB is send not by function pointer of the interface QI from.