Dear Peter,
Thank you for your reply.
You told me the fact actually. I analysed the debug info from my filter. It looked like this:
NTICE: Load32 START=ED2D8000 SIZE=5320 KPEB=8189D860 MOD=USBSTOR
NTICE: Load32 START=BAF69000 SIZE=2EC0 KPEB=8189D860 MOD=FILTER
'FILTER> DriverEntry
'FILTER> VA_AddDevice: drvObj=810D1890h, pdo=FF060270h
'FILTER> created filterDevObj 811A5AD0h attached to FED88950h.
FILTER> VA_Dispatch: majorFunc=1B, minorFunc=18
'FILTER> To Dispatch!!!
'FILTER> VA_Dispatch: majorFunc=1B, minorFunc=B
'FILTER> To Dispatch!!!
'FILTER> VA_Dispatch: majorFunc=1B, minorFunc=D
'FILTER> To Dispatch!!!
'FILTER> VA_Dispatch: majorFunc=1B, minorFunc=0
'FILTER> To Dispatch!!!
'FILTER> START_DEVICE
'FILTER> VA_Dispatch: majorFunc=1B, minorFunc=9
'FILTER> To Dispatch!!!
'FILTER> VA_Dispatch: majorFunc=1B, minorFunc=14
'FILTER> To Dispatch!!!
'FILTER> VA_Dispatch: majorFunc=1B, minorFunc=7
'FILTER> To Dispatch!!!
'FILTER> QUERY_DEVICE_RELATIONS
'FILTER> *****************************************
'FILTER> QueryRelation Completion Routine
'FILTER> Irp Major Function Code: 1B
'FILTER> Irp Minor Function Code: 7
'FILTER> Type: 0
'FILTER> *****************************************
'FILTER> VA_Dispatch: majorFunc=27, minorFunc=7
'FILTER> To Dispatch!!!
'FILTER> QUERY_DEVICE_RELATIONS
'FILTER> *****************************************
'FILTER> QueryRelation Completion Routine
'FILTER> Irp Major Function Code: 1B
'FILTER> Irp Minor Function Code: 7
'FILTER>Type: 0
'FILTER> *****************************************
The object I’m filtering is a FDO. After this FDO handles IRP_MN_QUERY_DEVICE_RELATIONS, it does expose a child PDO, which I don’t filter.
According to dump info from WDMSniffer, there is a member of irp named Object[0] in which the child PDO object is held, after the sencond IRP_MN_QUERY_DEVICE_RELATIONS was handle by lower object. But I don’t kown how to get this value via IO_STACK_LOCATION structure.
And I don’t know how to filter the child PDO either.
Can I create another Fido in my filter driver and attach it to the child PDO in the sencond Query Relations Completion Routine?
----- Original Message -----
From: “Peter Wieland”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, May 19, 2004 1:53 AM
Subject: RE: [ntdev] Why does my filter driver not work as expected?
> offhand my guess would be that the USBSTOR driver exposes child PDOs for the LUNs on a storage device, and that you’re filtering the FDO rather than the PDOs. You can use !devnode in the kernel debugger to dump the devnode for the USB device you’ve attached to and see if it has any children.
>
> -p
>
> ________________________________
>
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mike
> Sent: Tuesday, May 18, 2004 12:14 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Why does my filter driver not work as expected?
>
>
> Please give me a hand.
>
> ----- Original Message -----
> To: Windows System Software Devs Interest List mailto:xxxxx
> Sent: Monday, May 17, 2004 3:43 PM
> Subject: [ntdev] Why does my filter driver not work as expected?
>
> Hi all,
> I built the filter driver sample for usb, and added it to USBSTOR device object. It does nothing but dumping all type of IRP walking through it. Then I used Regedt32 watching Registry to ensure it added UpperFilter entry fo USB device.
> But when I observed the debug info dumped from filter, I found all the IRP were only type of IRP_MJ_PNP.
> Then, I used WDMSniffer provided by DriverStudio to observe what types of IRP the USBStor device needs to handle on earth. The Results showed that there are many types of IRP it needs to handle besides type of PNP. I watched Registry again, and found WDMSniffer added one filter driver named nmsniff just like what I did.
>
> I was confused by it.
>
> Did I select incorrect Device Object to be attached?
>
> Any advise or help will be appreciated.
> Thanks in advance.
>
> Mike</mailto:xxxxx>