Installing PCI filter driver without reboot.

NTDEV
41

Doron is right (as usual).
A function driver must pass down any PnP IRP that it does not
understand. Otherwise it won’t work at all.

Assuming that iastor fails your QI, you cannot use IoGetDevicePointer
to open its PCI PDO, because you will get the top device which is iastor
again. So send QUERY_DEVICE_RELATIONS to iastor, then
try IoCallDriver directly to the PDO (this is the hackery).
– pa

On 15-Aug-2012 11:07, Anirudha Kumar wrote:

Hi Pavel,

Its a typo (sorry about that). The PDO \Device\NTPNP_PCI0009 must have
been created by the pci.sys driver, right??? So iaStor must be passing
it down to \Device\NTPNP_PCI0009 which will be handled by pci.sys. IRP
tracker shows the request has been handled by \Device\NTPNP_PCI0009
meaning pci.sys (Am i right???). So, pci.sys is rejecting the QI
request when handling it for PDO \Device\NTPNP_PCI0009. Is my
understanding correct???

Anirudha

On Wed, Aug 15, 2012 at 2:00 AM, Pavel A. wrote:
>> IoGetDevicePointer() opens the top device in the stack. In your case
>> (without a filter) it is the iastor0 device.
>> So the iastor driver either rejected QI or something sits between it and
>> pci.sys that device tree does not show?
>> ( iaStor0 is \Device\00000048 but the IRP log shows \Device\00000049. Is
>> this a typo?)
>>
>> – pa
>>
>> “Anirudha Kumar” <> wrote in message news:xxxxx@ntdev…
>>>
>>> I tried the Query Interface approach. Following is the result:
>>>
>>> Device stack from device tree utility looks like this:
>>>
>>> FDO - \Driver\PCI
>>> PDO - \Device\NTPNP_PCI0009
>>> [PCI\VEN_xxxx&DEV_xxxx&SUBSYS_xxxxxxxx&REV_xx] <------ AHCI Controller
>>> Device ID
>>> FDO - \Device\00000048
>>> FDO - \Device\Ide\iaStor0
>>>
>>> In my driver I’m sending calling IoGetDevicePointer with
>>> “NTPNP_PCI0009” as device name and sending IRP_MN_QUERY_INTERFACE to
>>> the device pointer received. Following is the IRP tracker log:
>>>
>>> Call 0x8891DE70-64 (UNKNOWN) \Device\Ide\iaStor0 PNP QUERY_INTERFACE
>>> Call 0x8891DE70-64 \Device\Ide\iaStor0 \Device\00000049 PNP
>>> QUERY_INTERFACE
>>> Call 0x8891DE70-64 \Device\00000049 \Device\NTPNP_PCI0009 PNP
>>> QUERY_INTERFACE
>>> Comp 0x8891DE70-64 \Device\NTPNP_PCI0009 PNP QUERY_INTERFACE
>>> NOT_SUPPORTED,
>>> Info = 0x0
>>>
>>> From my understanding, for the AHCI Controller devnode, the PDO
>>> “\Device\NTPNP_PCI0009” has been created by pci.sys (standard pci
>>> driver) during enumeration and FDO “\Device\Ide\iaStor0” has been
>>> created by the iaStor.sys (Intel storport driver). My IRP goes to this
>>> devnode and is completed by PDO created by pci.sys with
>>> STATUS_NOT_SUPPORTED. But when I install an upper filter driver in PCI
>>> devnode and send the same IRP to this filter driver, I observe the
>>> following:
>>>
>>> Device stack from device tree utility looks like this:
>>>
>>> FDO - \Driver\PCI
>>> FDO - \Device\MyPciFilter
>>>
>>> IRP tracker log looks like this:
>>>
>>> Call 0x88867A38-712 (UNKNOWN) \Device\PhyMemPCIFilter PNP
>>> QUERY_INTERFACE
>>> Call 0x88867A38-712 \Device\PhyMemPCIFilter (0x8B0F8A90)
>>> PCI PNP QUERY_INTERFACE
>>> Call 0x88867A38-712 (0x8B0F8A90)
>>> PCI \Device\0000003d PNP QUERY_INTERFACE
>>> Comp 0x88867A38-712 \Device\0000003d PNP QUERY_INTERFACE SUCCESS,
>>> Info = 0x0
>>> CompRoutine 0x88867A38-712 (0x8B0F8A90)
>>> PCI PNP QUERY_INTERFACE MORE_PROCESSING_REQUIRED
>>> Comp 0x88867A38-712 (0x8B0F8A90)
>>> PCI PNP QUERY_INTERFACE SUCCESS, Info = 0x0
>>>
>>>
>>> So, the same driver behaves one way when the request reaches a PDO
>>> created by it and differently when the same request reaches the FDO
>>> created by it? Is it because the PDO and the FDO belong to different
>>> devnode?
>>>
>>> @Doron
>>> Given the above configuration, will the approach suggested by you
>>> (QUERY_DEVICE_RELATIONS) work???
>>>
>>>
>>> Anirudha
>>>
>>>
>>>
>>> On Mon, Aug 13, 2012 at 11:44 PM, Doron Holan <> wrote:
>>>>
>>>>
>>>> You can’t fail QDR/TargetDeviceRelations, otherwise you couldn’t open a
>>>> handle IIRC
>>>>
>>>> d
>>>>
>>>> -----Original Message-----
>>>> From: Pavel A
>>>> Sent: Monday, August 13, 2012 10:27 AM
>>>> To: Windows System Software Devs Interest List
>>>> Subject: Re:[ntdev] Installing PCI filter driver without reboot.
>>>>
>>>> The driver will probably fail QDR, exactly like it failed QI…
>>>> --pa
>>>>
>>>> On 13-Aug-2012 18:40, Doron Holan wrote:
>>>>> Once you open the stack, send a query device relations / target device
>>>>> relation to get the pdo. Once you have the pdo, send the query
>>>>> interface directly to it, bypassing the fdo. You should only do this
>>>>> if the fdo does not fwd query interfaces down the stack (which is a
>>>>> wdm rule/driver verifier rule violation)
>>>>>
>>>>> d
>>>>>
>>>>> debt from my phone
>>>
>>>
>>
>> —
>> 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
>

42

But the IRP tracker log clearly says that the iaStor is passing it
down to the PDO and the PDO is failing the QI. Even if i get the
device object of PDO using QDR and and directly send QI to it, why
would it behave differently??? I did not get this…

On Wed, Aug 15, 2012 at 4:40 PM, Pavel A wrote:
> Doron is right (as usual).
> A function driver must pass down any PnP IRP that it does not understand.
> Otherwise it won’t work at all.
>
> Assuming that iastor fails your QI, you cannot use IoGetDevicePointer
> to open its PCI PDO, because you will get the top device which is iastor
> again. So send QUERY_DEVICE_RELATIONS to iastor, then
> try IoCallDriver directly to the PDO (this is the hackery).
> – pa
>
>
> On 15-Aug-2012 11:07, Anirudha Kumar wrote:
>>
>> Hi Pavel,
>>
>> Its a typo (sorry about that). The PDO \Device\NTPNP_PCI0009 must have
>> been created by the pci.sys driver, right??? So iaStor must be passing
>> it down to \Device\NTPNP_PCI0009 which will be handled by pci.sys. IRP
>> tracker shows the request has been handled by \Device\NTPNP_PCI0009
>> meaning pci.sys (Am i right???). So, pci.sys is rejecting the QI
>> request when handling it for PDO \Device\NTPNP_PCI0009. Is my
>> understanding correct???
>>
>> Anirudha
>>
>> On Wed, Aug 15, 2012 at 2:00 AM, Pavel A. wrote:
>>>
>>> IoGetDevicePointer() opens the top device in the stack. In your case
>>> (without a filter) it is the iastor0 device.
>>> So the iastor driver either rejected QI or something sits between it and
>>> pci.sys that device tree does not show?
>>> ( iaStor0 is \Device\00000048 but the IRP log shows \Device\00000049. Is
>>> this a typo?)
>>>
>>> – pa
>>>
>>> “Anirudha Kumar” <> wrote in message news:xxxxx@ntdev…
>>>>
>>>>
>>>> I tried the Query Interface approach. Following is the result:
>>>>
>>>> Device stack from device tree utility looks like this:
>>>>
>>>> FDO - \Driver\PCI
>>>> PDO - \Device\NTPNP_PCI0009
>>>> [PCI\VEN_xxxx&DEV_xxxx&SUBSYS_xxxxxxxx&REV_xx] <------ AHCI Controller
>>>> Device ID
>>>> FDO - \Device\00000048
>>>> FDO - \Device\Ide\iaStor0
>>>>
>>>> In my driver I’m sending calling IoGetDevicePointer with
>>>> “NTPNP_PCI0009” as device name and sending IRP_MN_QUERY_INTERFACE to
>>>> the device pointer received. Following is the IRP tracker log:
>>>>
>>>> Call 0x8891DE70-64 (UNKNOWN) \Device\Ide\iaStor0 PNP
>>>> QUERY_INTERFACE
>>>> Call 0x8891DE70-64 \Device\Ide\iaStor0 \Device\00000049 PNP
>>>> QUERY_INTERFACE
>>>> Call 0x8891DE70-64 \Device\00000049 \Device\NTPNP_PCI0009 PNP
>>>> QUERY_INTERFACE
>>>> Comp 0x8891DE70-64 \Device\NTPNP_PCI0009 PNP QUERY_INTERFACE
>>>> NOT_SUPPORTED,
>>>> Info = 0x0
>>>>
>>>> From my understanding, for the AHCI Controller devnode, the PDO
>>>> “\Device\NTPNP_PCI0009” has been created by pci.sys (standard pci
>>>> driver) during enumeration and FDO “\Device\Ide\iaStor0” has been
>>>> created by the iaStor.sys (Intel storport driver). My IRP goes to this
>>>> devnode and is completed by PDO created by pci.sys with
>>>> STATUS_NOT_SUPPORTED. But when I install an upper filter driver in PCI
>>>> devnode and send the same IRP to this filter driver, I observe the
>>>> following:
>>>>
>>>> Device stack from device tree utility looks like this:
>>>>
>>>> FDO - \Driver\PCI
>>>> FDO - \Device\MyPciFilter
>>>>
>>>> IRP tracker log looks like this:
>>>>
>>>> Call 0x88867A38-712 (UNKNOWN) \Device\PhyMemPCIFilter PNP
>>>> QUERY_INTERFACE
>>>> Call 0x88867A38-712 \Device\PhyMemPCIFilter (0x8B0F8A90)
>>>> PCI PNP QUERY_INTERFACE
>>>> Call 0x88867A38-712 (0x8B0F8A90)
>>>> PCI \Device\0000003d PNP QUERY_INTERFACE
>>>> Comp 0x88867A38-712 \Device\0000003d PNP QUERY_INTERFACE SUCCESS,
>>>> Info = 0x0
>>>> CompRoutine 0x88867A38-712 (0x8B0F8A90)
>>>> PCI PNP QUERY_INTERFACE MORE_PROCESSING_REQUIRED
>>>> Comp 0x88867A38-712 (0x8B0F8A90)
>>>> PCI PNP QUERY_INTERFACE SUCCESS, Info = 0x0
>>>>
>>>>
>>>> So, the same driver behaves one way when the request reaches a PDO
>>>> created by it and differently when the same request reaches the FDO
>>>> created by it? Is it because the PDO and the FDO belong to different
>>>> devnode?
>>>>
>>>> @Doron
>>>> Given the above configuration, will the approach suggested by you
>>>> (QUERY_DEVICE_RELATIONS) work???
>>>>
>>>>
>>>> Anirudha
>>>>
>>>>
>>>>
>>>> On Mon, Aug 13, 2012 at 11:44 PM, Doron Holan <> wrote:
>>>>>
>>>>>
>>>>>
>>>>> You can’t fail QDR/TargetDeviceRelations, otherwise you couldn’t open a
>>>>> handle IIRC
>>>>>
>>>>> d
>>>>>
>>>>> -----Original Message-----
>>>>> From: Pavel A
>>>>> Sent: Monday, August 13, 2012 10:27 AM
>>>>> To: Windows System Software Devs Interest List
>>>>> Subject: Re:[ntdev] Installing PCI filter driver without reboot.
>>>>>
>>>>> The driver will probably fail QDR, exactly like it failed QI…
>>>>> --pa
>>>>>
>>>>> On 13-Aug-2012 18:40, Doron Holan wrote:
>>>>>>
>>>>>> Once you open the stack, send a query device relations / target device
>>>>>> relation to get the pdo. Once you have the pdo, send the query
>>>>>> interface directly to it, bypassing the fdo. You should only do this
>>>>>> if the fdo does not fwd query interfaces down the stack (which is a
>>>>>> wdm rule/driver verifier rule violation)
>>>>>>
>>>>>> d
>>>>>>
>>>>>> debt from my phone
>>>>
>>>>
>>>>
>>>
>>> —
>>> 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

43

“upthread”… new term for me. I like that one.

Peter
OSR

44

Perhaps you are not formatting the QI irp properly

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Anirudha Kumar
Sent: Wednesday, August 15, 2012 12:10 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Installing PCI filter driver without reboot.

But the IRP tracker log clearly says that the iaStor is passing it down to the PDO and the PDO is failing the QI. Even if i get the device object of PDO using QDR and and directly send QI to it, why would it behave differently??? I did not get this…

On Wed, Aug 15, 2012 at 4:40 PM, Pavel A wrote:
> Doron is right (as usual).
> A function driver must pass down any PnP IRP that it does not understand.
> Otherwise it won’t work at all.
>
> Assuming that iastor fails your QI, you cannot use IoGetDevicePointer
> to open its PCI PDO, because you will get the top device which is
> iastor again. So send QUERY_DEVICE_RELATIONS to iastor, then try
> IoCallDriver directly to the PDO (this is the hackery).
> – pa
>
>
> On 15-Aug-2012 11:07, Anirudha Kumar wrote:
>>
>> Hi Pavel,
>>
>> Its a typo (sorry about that). The PDO \Device\NTPNP_PCI0009 must
>> have been created by the pci.sys driver, right??? So iaStor must be
>> passing it down to \Device\NTPNP_PCI0009 which will be handled by
>> pci.sys. IRP tracker shows the request has been handled by
>> \Device\NTPNP_PCI0009 meaning pci.sys (Am i right???). So, pci.sys is
>> rejecting the QI request when handling it for PDO
>> \Device\NTPNP_PCI0009. Is my understanding correct???
>>
>> Anirudha
>>
>> On Wed, Aug 15, 2012 at 2:00 AM, Pavel A. wrote:
>>>
>>> IoGetDevicePointer() opens the top device in the stack. In your case
>>> (without a filter) it is the iastor0 device.
>>> So the iastor driver either rejected QI or something sits between it
>>> and pci.sys that device tree does not show?
>>> ( iaStor0 is \Device\00000048 but the IRP log shows
>>> \Device\00000049. Is this a typo?)
>>>
>>> – pa
>>>
>>> “Anirudha Kumar” <> wrote in message news:xxxxx@ntdev…
>>>>
>>>>
>>>> I tried the Query Interface approach. Following is the result:
>>>>
>>>> Device stack from device tree utility looks like this:
>>>>
>>>> FDO - \Driver\PCI
>>>> PDO - \Device\NTPNP_PCI0009
>>>> [PCI\VEN_xxxx&DEV_xxxx&SUBSYS_xxxxxxxx&REV_xx] <------ AHCI
>>>> Controller Device ID
>>>> FDO - \Device\00000048
>>>> FDO - \Device\Ide\iaStor0
>>>>
>>>> In my driver I’m sending calling IoGetDevicePointer with
>>>> “NTPNP_PCI0009” as device name and sending IRP_MN_QUERY_INTERFACE
>>>> to the device pointer received. Following is the IRP tracker log:
>>>>
>>>> Call 0x8891DE70-64 (UNKNOWN) \Device\Ide\iaStor0 PNP
>>>> QUERY_INTERFACE
>>>> Call 0x8891DE70-64 \Device\Ide\iaStor0 \Device\00000049 PNP
>>>> QUERY_INTERFACE
>>>> Call 0x8891DE70-64 \Device\00000049 \Device\NTPNP_PCI0009 PNP
>>>> QUERY_INTERFACE
>>>> Comp 0x8891DE70-64 \Device\NTPNP_PCI0009 PNP QUERY_INTERFACE
>>>> NOT_SUPPORTED,
>>>> Info = 0x0
>>>>
>>>> From my understanding, for the AHCI Controller devnode, the PDO
>>>> “\Device\NTPNP_PCI0009” has been created by pci.sys (standard pci
>>>> driver) during enumeration and FDO “\Device\Ide\iaStor0” has been
>>>> created by the iaStor.sys (Intel storport driver). My IRP goes to
>>>> this devnode and is completed by PDO created by pci.sys with
>>>> STATUS_NOT_SUPPORTED. But when I install an upper filter driver in
>>>> PCI devnode and send the same IRP to this filter driver, I observe
>>>> the
>>>> following:
>>>>
>>>> Device stack from device tree utility looks like this:
>>>>
>>>> FDO - \Driver\PCI
>>>> FDO - \Device\MyPciFilter
>>>>
>>>> IRP tracker log looks like this:
>>>>
>>>> Call 0x88867A38-712 (UNKNOWN) \Device\PhyMemPCIFilter PNP
>>>> QUERY_INTERFACE
>>>> Call 0x88867A38-712 \Device\PhyMemPCIFilter (0x8B0F8A90)
>>>> PCI PNP QUERY_INTERFACE
>>>> Call 0x88867A38-712 (0x8B0F8A90)
>>>> PCI \Device\0000003d PNP QUERY_INTERFACE
>>>> Comp 0x88867A38-712 \Device\0000003d PNP QUERY_INTERFACE SUCCESS,
>>>> Info = 0x0
>>>> CompRoutine 0x88867A38-712 (0x8B0F8A90) PCI PNP QUERY_INTERFACE
>>>> MORE_PROCESSING_REQUIRED
>>>> Comp 0x88867A38-712 (0x8B0F8A90)
>>>> PCI PNP QUERY_INTERFACE SUCCESS, Info = 0x0
>>>>
>>>>
>>>> So, the same driver behaves one way when the request reaches a PDO
>>>> created by it and differently when the same request reaches the FDO
>>>> created by it? Is it because the PDO and the FDO belong to
>>>> different devnode?
>>>>
>>>> @Doron
>>>> Given the above configuration, will the approach suggested by you
>>>> (QUERY_DEVICE_RELATIONS) work???
>>>>
>>>>
>>>> Anirudha
>>>>
>>>>
>>>>
>>>> On Mon, Aug 13, 2012 at 11:44 PM, Doron Holan <> wrote:
>>>>>
>>>>>
>>>>>
>>>>> You can’t fail QDR/TargetDeviceRelations, otherwise you couldn’t
>>>>> open a handle IIRC
>>>>>
>>>>> d
>>>>>
>>>>> -----Original Message-----
>>>>> From: Pavel A
>>>>> Sent: Monday, August 13, 2012 10:27 AM
>>>>> To: Windows System Software Devs Interest List
>>>>> Subject: Re:[ntdev] Installing PCI filter driver without reboot.
>>>>>
>>>>> The driver will probably fail QDR, exactly like it failed QI…
>>>>> --pa
>>>>>
>>>>> On 13-Aug-2012 18:40, Doron Holan wrote:
>>>>>>
>>>>>> Once you open the stack, send a query device relations / target
>>>>>> device relation to get the pdo. Once you have the pdo, send the
>>>>>> query interface directly to it, bypassing the fdo. You should
>>>>>> only do this if the fdo does not fwd query interfaces down the
>>>>>> stack (which is a wdm rule/driver verifier rule violation)
>>>>>>
>>>>>> d
>>>>>>
>>>>>> debt from my phone
>>>>
>>>>
>>>>
>>>
>>> —
>>> 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

—
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

45

This is the code snippet for sending QI:

busInterface=(PBUS_INTERFACE_STANDARD)ExAllocatePool(NonPagedPool,
sizeof(BUS_INTERFACE_STANDARD));
if (busInterface==NULL)
{
return STATUS_INSUFFICIENT_RESOURCES;
}

KeInitializeEvent(&event, NotificationEvent, FALSE);

irp=IoBuildSynchronousFsdRequest(IRP_MJ_PNP,
pcido,
NULL,
0,
NULL,
&event,
&ioStatus);

if (irp==NULL)
{
return STATUS_INSUFFICIENT_RESOURCES;
}

irpStack=IoGetNextIrpStackLocation(irp);
irpStack->MinorFunction=IRP_MN_QUERY_INTERFACE;
irpStack->Parameters.QueryInterface.InterfaceType=(LPGUID)&GUID_BUS_INTERFACE_STANDARD;
irpStack->Parameters.QueryInterface.Size=sizeof(BUS_INTERFACE_STANDARD);
irpStack->Parameters.QueryInterface.Version=BUS_INTERFACE_STANDARD_VERSION;
irpStack->Parameters.QueryInterface.Interface=(PINTERFACE)busInterface;
irpStack->Parameters.QueryInterface.InterfaceSpecificData=NULL;

//initialize the status to error in case the bus driver does not
//set it correctly.
irp->IoStatus.Status=STATUS_NOT_SUPPORTED ;

ntStatus=IoCallDriver(pcido, irp);

if (ntStatus==STATUS_PENDING)
{
KeWaitForSingleObject(&event, Executive, KernelMode, FALSE, NULL);

ntStatus=ioStatus.Status;
}

Is there anything wrong in this???

On Thu, Aug 16, 2012 at 1:52 AM, Doron Holan wrote:
> Perhaps you are not formatting the QI irp properly
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Anirudha Kumar
> Sent: Wednesday, August 15, 2012 12:10 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Installing PCI filter driver without reboot.
>
> But the IRP tracker log clearly says that the iaStor is passing it down to the PDO and the PDO is failing the QI. Even if i get the device object of PDO using QDR and and directly send QI to it, why would it behave differently??? I did not get this…
>
> On Wed, Aug 15, 2012 at 4:40 PM, Pavel A wrote:
>> Doron is right (as usual).
>> A function driver must pass down any PnP IRP that it does not understand.
>> Otherwise it won’t work at all.
>>
>> Assuming that iastor fails your QI, you cannot use IoGetDevicePointer
>> to open its PCI PDO, because you will get the top device which is
>> iastor again. So send QUERY_DEVICE_RELATIONS to iastor, then try
>> IoCallDriver directly to the PDO (this is the hackery).
>> – pa
>>
>>
>> On 15-Aug-2012 11:07, Anirudha Kumar wrote:
>>>
>>> Hi Pavel,
>>>
>>> Its a typo (sorry about that). The PDO \Device\NTPNP_PCI0009 must
>>> have been created by the pci.sys driver, right??? So iaStor must be
>>> passing it down to \Device\NTPNP_PCI0009 which will be handled by
>>> pci.sys. IRP tracker shows the request has been handled by
>>> \Device\NTPNP_PCI0009 meaning pci.sys (Am i right???). So, pci.sys is
>>> rejecting the QI request when handling it for PDO
>>> \Device\NTPNP_PCI0009. Is my understanding correct???
>>>
>>> Anirudha
>>>
>>> On Wed, Aug 15, 2012 at 2:00 AM, Pavel A. wrote:
>>>>
>>>> IoGetDevicePointer() opens the top device in the stack. In your case
>>>> (without a filter) it is the iastor0 device.
>>>> So the iastor driver either rejected QI or something sits between it
>>>> and pci.sys that device tree does not show?
>>>> ( iaStor0 is \Device\00000048 but the IRP log shows
>>>> \Device\00000049. Is this a typo?)
>>>>
>>>> – pa
>>>>
>>>> “Anirudha Kumar” <> wrote in message news:xxxxx@ntdev…
>>>>>
>>>>>
>>>>> I tried the Query Interface approach. Following is the result:
>>>>>
>>>>> Device stack from device tree utility looks like this:
>>>>>
>>>>> FDO - \Driver\PCI
>>>>> PDO - \Device\NTPNP_PCI0009
>>>>> [PCI\VEN_xxxx&DEV_xxxx&SUBSYS_xxxxxxxx&REV_xx] <------ AHCI
>>>>> Controller Device ID
>>>>> FDO - \Device\00000048
>>>>> FDO - \Device\Ide\iaStor0
>>>>>
>>>>> In my driver I’m sending calling IoGetDevicePointer with
>>>>> “NTPNP_PCI0009” as device name and sending IRP_MN_QUERY_INTERFACE
>>>>> to the device pointer received. Following is the IRP tracker log:
>>>>>
>>>>> Call 0x8891DE70-64 (UNKNOWN) \Device\Ide\iaStor0 PNP
>>>>> QUERY_INTERFACE
>>>>> Call 0x8891DE70-64 \Device\Ide\iaStor0 \Device\00000049 PNP
>>>>> QUERY_INTERFACE
>>>>> Call 0x8891DE70-64 \Device\00000049 \Device\NTPNP_PCI0009 PNP
>>>>> QUERY_INTERFACE
>>>>> Comp 0x8891DE70-64 \Device\NTPNP_PCI0009 PNP QUERY_INTERFACE
>>>>> NOT_SUPPORTED,
>>>>> Info = 0x0
>>>>>
>>>>> From my understanding, for the AHCI Controller devnode, the PDO
>>>>> “\Device\NTPNP_PCI0009” has been created by pci.sys (standard pci
>>>>> driver) during enumeration and FDO “\Device\Ide\iaStor0” has been
>>>>> created by the iaStor.sys (Intel storport driver). My IRP goes to
>>>>> this devnode and is completed by PDO created by pci.sys with
>>>>> STATUS_NOT_SUPPORTED. But when I install an upper filter driver in
>>>>> PCI devnode and send the same IRP to this filter driver, I observe
>>>>> the
>>>>> following:
>>>>>
>>>>> Device stack from device tree utility looks like this:
>>>>>
>>>>> FDO - \Driver\PCI
>>>>> FDO - \Device\MyPciFilter
>>>>>
>>>>> IRP tracker log looks like this:
>>>>>
>>>>> Call 0x88867A38-712 (UNKNOWN) \Device\PhyMemPCIFilter PNP
>>>>> QUERY_INTERFACE
>>>>> Call 0x88867A38-712 \Device\PhyMemPCIFilter (0x8B0F8A90)
>>>>> PCI PNP QUERY_INTERFACE
>>>>> Call 0x88867A38-712 (0x8B0F8A90)
>>>>> PCI \Device\0000003d PNP QUERY_INTERFACE
>>>>> Comp 0x88867A38-712 \Device\0000003d PNP QUERY_INTERFACE SUCCESS,
>>>>> Info = 0x0
>>>>> CompRoutine 0x88867A38-712 (0x8B0F8A90) PCI PNP QUERY_INTERFACE
>>>>> MORE_PROCESSING_REQUIRED
>>>>> Comp 0x88867A38-712 (0x8B0F8A90)
>>>>> PCI PNP QUERY_INTERFACE SUCCESS, Info = 0x0
>>>>>
>>>>>
>>>>> So, the same driver behaves one way when the request reaches a PDO
>>>>> created by it and differently when the same request reaches the FDO
>>>>> created by it? Is it because the PDO and the FDO belong to
>>>>> different devnode?
>>>>>
>>>>> @Doron
>>>>> Given the above configuration, will the approach suggested by you
>>>>> (QUERY_DEVICE_RELATIONS) work???
>>>>>
>>>>>
>>>>> Anirudha
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Aug 13, 2012 at 11:44 PM, Doron Holan <> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> You can’t fail QDR/TargetDeviceRelations, otherwise you couldn’t
>>>>>> open a handle IIRC
>>>>>>
>>>>>> d
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Pavel A
>>>>>> Sent: Monday, August 13, 2012 10:27 AM
>>>>>> To: Windows System Software Devs Interest List
>>>>>> Subject: Re:[ntdev] Installing PCI filter driver without reboot.
>>>>>>
>>>>>> The driver will probably fail QDR, exactly like it failed QI…
>>>>>> --pa
>>>>>>
>>>>>> On 13-Aug-2012 18:40, Doron Holan wrote:
>>>>>>>
>>>>>>> Once you open the stack, send a query device relations / target
>>>>>>> device relation to get the pdo. Once you have the pdo, send the
>>>>>>> query interface directly to it, bypassing the fdo. You should
>>>>>>> only do this if the fdo does not fwd query interfaces down the
>>>>>>> stack (which is a wdm rule/driver verifier rule violation)
>>>>>>>
>>>>>>> d
>>>>>>>
>>>>>>> debt from my phone
>>>>>
>>>>>
>>>>>
>>>>
>>>> —
>>>> 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
>
> —
> 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