I’m working on an disk driver experiment. Basically it is a proof-of-concept
for hardware and won’t be an actual software product. What I’m trying to do
is to filter the raw PDOs created for disk devices. What I want to do is to
combine several PDOs into a single PDO and then distribute I/O requests
between the grouped devices. I’m targeting USB devices in particular, but
this isn’t necessarily a requirement.
I’ve created a lower filter on disk.sys and can see the PDOs for all the
disks in the system in my AddDevice function. I create a FiDO and attach it
at this point like any other filter would. What I can’t figure out is how do
I prevent disk.sys from seeing the PDO and attaching the file system drivers
to it.
I’ve looked through the archives here, and can’t seem to find the solution.
Perhaps I need a bus driver instead of a filter? Am I at the right place in
the stack? I’ve also seen some references to using
SetupDiSetDeviceRegistryProperty with SPDRP_SERVICE but this also seems to
have problems. Any suggestions on where to look to find a solution would be
greatly appreciated.
Thanks!
You need a bus filter driver. For example, microsoft’s mpio scsi filter
driver does this for scsi/storport adapter enumerated disk pdos.
Mark Roddy
On Mon, Dec 8, 2008 at 6:47 PM, Chapman Mays wrote:
> I’m working on an disk driver experiment. Basically it is a
> proof-of-concept for hardware and won’t be an actual software product. What
> I’m trying to do is to filter the raw PDOs created for disk devices. What I
> want to do is to combine several PDOs into a single PDO and then distribute
> I/O requests between the grouped devices. I’m targeting USB devices in
> particular, but this isn’t necessarily a requirement.
>
>
>
> I’ve created a lower filter on disk.sys and can see the PDOs for all the
> disks in the system in my AddDevice function. I create a FiDO and attach it
> at this point like any other filter would. What I can’t figure out is how do
> I prevent disk.sys from seeing the PDO and attaching the file system drivers
> to it.
>
>
>
> I’ve looked through the archives here, and can’t seem to find the solution.
> Perhaps I need a bus driver instead of a filter? Am I at the right place in
> the stack? I’ve also seen some references to using
> SetupDiSetDeviceRegistryProperty with SPDRP_SERVICE but this also seems to
> have problems. Any suggestions on where to look to find a solution would be
> greatly appreciated.
>
>
>
> Thanks!
>
>
>
> —
> 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
>
Quoting Mark Roddy :
> You need a bus filter driver. For example, microsoft’s mpio scsi filter
> driver does this for scsi/storport adapter enumerated disk pdos.
> Mark Roddy
>
>
I think of a PDO as an ordinary device object that has been notified to the PnP system with a response to
IRP_MJ_PNP, IRP_MN_QUERY_DEVICE_RELATIONS, BusRelations. Now as Mark says you need a bus filter which intercepts
this call removes the potential PDOs from the returned list and your new device object as the only PDO. Don’t
forget to do the Object reference/dereferencing for the never were PDOs.
-------------------------------------------------
Visit Pipex Business: The homepage for UK Small Businesses
Go to http://www.pipex.co.uk/business-services
> Quoting Mark Roddy :
>
> > You need a bus filter driver. For example, microsoft’s mpio scsi
filter
> > driver does this for scsi/storport adapter enumerated disk pdos.
> > Mark Roddy
> >
> >
>
> I think of a PDO as an ordinary device object that has been notified
to
> the PnP system with a response to
> IRP_MJ_PNP, IRP_MN_QUERY_DEVICE_RELATIONS, BusRelations. Now as Mark
says
> you need a bus filter which intercepts
> this call removes the potential PDOs from the returned list and your
new
> device object as the only PDO. Don’t
> forget to do the Object reference/dereferencing for the never were
PDOs.
>
You might already know this but it bit me when I first tried this - the
first time your filter see’s the
IRP_MN_QUERY_DEVICE_RELATIONS(BusRelations) IRP, the PDO’s aren’t valid
for a call to IoGetDeviceProperty - as per the
IRP_MN_QUERY_DEVICE_RELATIONS docs:
“Warning A device object cannot be passed to any routine that takes a
PDO as an argument until the PnP manager creates a devnode for that
object. (If the driver does pass a device object, the system will bug
check with Bug Check 0xCA: PNP_DETECTED_FATAL_ERROR.) The PnP manager
creates the devnode in response to the IRP_MN_QUERY_DEVICE_RELATIONS
request. The driver can safely assume that the PDO’s devnode has been
created when it receives an IRP_MN_QUERY_RESOURCE_REQUIREMENTS request.”
James
Yes, and there is more to it than that. The underlying bus driver, if it is ever going to unload, needs to see more pnp irps since it thinks it successfully reported to pnp and that is a huge state change that you must now emulate
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Tuesday, December 09, 2008 1:51 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Filtering Disk PDOs
Quoting Mark Roddy :
>
> > You need a bus filter driver. For example, microsoft’s mpio scsi
filter
> > driver does this for scsi/storport adapter enumerated disk pdos.
> > Mark Roddy
> >
> >
>
> I think of a PDO as an ordinary device object that has been notified
to
> the PnP system with a response to
> IRP_MJ_PNP, IRP_MN_QUERY_DEVICE_RELATIONS, BusRelations. Now as Mark
says
> you need a bus filter which intercepts
> this call removes the potential PDOs from the returned list and your
new
> device object as the only PDO. Don’t
> forget to do the Object reference/dereferencing for the never were
PDOs.
>
You might already know this but it bit me when I first tried this - the
first time your filter see’s the
IRP_MN_QUERY_DEVICE_RELATIONS(BusRelations) IRP, the PDO’s aren’t valid
for a call to IoGetDeviceProperty - as per the
IRP_MN_QUERY_DEVICE_RELATIONS docs:
“Warning A device object cannot be passed to any routine that takes a
PDO as an argument until the PnP manager creates a devnode for that
object. (If the driver does pass a device object, the system will bug
check with Bug Check 0xCA: PNP_DETECTED_FATAL_ERROR.) The PnP manager
creates the devnode in response to the IRP_MN_QUERY_DEVICE_RELATIONS
request. The driver can safely assume that the PDO’s devnode has been
created when it receives an IRP_MN_QUERY_RESOURCE_REQUIREMENTS request.”
James
—
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
There are better ways to hide PDOs. Translating the pnp ids is far less
invasive.
Mark Roddy
On Tue, Dec 9, 2008 at 9:08 AM, Doron Holan wrote:
> Yes, and there is more to it than that. The underlying bus driver, if it is
> ever going to unload, needs to see more pnp irps since it thinks it
> successfully reported to pnp and that is a huge state change that you must
> now emulate
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of James Harper
> Sent: Tuesday, December 09, 2008 1:51 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Filtering Disk PDOs
>
> > Quoting Mark Roddy :
> >
> > > You need a bus filter driver. For example, microsoft’s mpio scsi
> filter
> > > driver does this for scsi/storport adapter enumerated disk pdos.
> > > Mark Roddy
> > >
> > >
> >
> > I think of a PDO as an ordinary device object that has been notified
> to
> > the PnP system with a response to
> > IRP_MJ_PNP, IRP_MN_QUERY_DEVICE_RELATIONS, BusRelations. Now as Mark
> says
> > you need a bus filter which intercepts
> > this call removes the potential PDOs from the returned list and your
> new
> > device object as the only PDO. Don’t
> > forget to do the Object reference/dereferencing for the never were
> PDOs.
> >
>
> You might already know this but it bit me when I first tried this - the
> first time your filter see’s the
> IRP_MN_QUERY_DEVICE_RELATIONS(BusRelations) IRP, the PDO’s aren’t valid
> for a call to IoGetDeviceProperty - as per the
> IRP_MN_QUERY_DEVICE_RELATIONS docs:
>
> “Warning A device object cannot be passed to any routine that takes a
> PDO as an argument until the PnP manager creates a devnode for that
> object. (If the driver does pass a device object, the system will bug
> check with Bug Check 0xCA: PNP_DETECTED_FATAL_ERROR.) The PnP manager
> creates the devnode in response to the IRP_MN_QUERY_DEVICE_RELATIONS
> request. The driver can safely assume that the PDO’s devnode has been
> created when it receives an IRP_MN_QUERY_RESOURCE_REQUIREMENTS request.”
>
> James
>
> —
> 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
>
Thanks for all the information. This looks like a little more work than I
bargained for. Back to the drawing board…
-Chapman
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Tuesday, December 09, 2008 9:11 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Filtering Disk PDOs
There are better ways to hide PDOs. Translating the pnp ids is far less
invasive.
Mark Roddy
On Tue, Dec 9, 2008 at 9:08 AM, Doron Holan
wrote:
Yes, and there is more to it than that. The underlying bus driver, if it is
ever going to unload, needs to see more pnp irps since it thinks it
successfully reported to pnp and that is a huge state change that you must
now emulate
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Tuesday, December 09, 2008 1:51 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Filtering Disk PDOs
> Quoting Mark Roddy :
>
> > You need a bus filter driver. For example, microsoft’s mpio scsi
filter
> > driver does this for scsi/storport adapter enumerated disk pdos.
> > Mark Roddy
> >
> >
>
> I think of a PDO as an ordinary device object that has been notified
to
> the PnP system with a response to
> IRP_MJ_PNP, IRP_MN_QUERY_DEVICE_RELATIONS, BusRelations. Now as Mark
says
> you need a bus filter which intercepts
> this call removes the potential PDOs from the returned list and your
new
> device object as the only PDO. Don’t
> forget to do the Object reference/dereferencing for the never were
PDOs.
>
You might already know this but it bit me when I first tried this - the
first time your filter see’s the
IRP_MN_QUERY_DEVICE_RELATIONS(BusRelations) IRP, the PDO’s aren’t valid
for a call to IoGetDeviceProperty - as per the
IRP_MN_QUERY_DEVICE_RELATIONS docs:
“Warning A device object cannot be passed to any routine that takes a
PDO as an argument until the PnP manager creates a devnode for that
object. (If the driver does pass a device object, the system will bug
check with Bug Check 0xCA: PNP_DETECTED_FATAL_ERROR.) The PnP manager
creates the devnode in response to the IRP_MN_QUERY_DEVICE_RELATIONS
request. The driver can safely assume that the PDO’s devnode has been
created when it receives an IRP_MN_QUERY_RESOURCE_REQUIREMENTS request.”
James
—
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
>
Yes, and there is more to it than that. The underlying bus driver, if
it
is ever going to unload, needs to see more pnp irps since it thinks it
successfully reported to pnp and that is a huge state change that you
must
now emulate
When I implemented this, I simply removed the pdo from the list every
time I saw it in there. It worked under every platform I tried it on,
but I was clearly not doing it the ‘right way’ and as such a future
service pack or hotfix could easily break it.
It’s funny how in some cases Windows seems to take all sorts of abuse of
protocol with good humour, and in other cases it BSoD’s instantly the
moment you do something wrong!
James