system bus extender

NTDEV
1

If I want to write a driver attaching itself below disk.sys , do I
have to write a system bus extender type of a driver that extends
atapi.sys ?

thanks in advance for your help.

  • Developer
2

You write a filter driver, just like if you wanted to attach into any
other PNP device stack.

-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Developer
Sent: Thursday, August 04, 2005 2:41 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] system bus extender

If I want to write a driver attaching itself below disk.sys , do I
have to write a system bus extender type of a driver that extends
atapi.sys ?

thanks in advance for your help.

  • Developer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
''
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

No, write the LowerFilter for Disk class devices.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Developer”
To: “Windows System Software Devs Interest List”
Sent: Thursday, August 04, 2005 1:41 PM
Subject: [ntdev] system bus extender

If I want to write a driver attaching itself below disk.sys , do I
have to write a system bus extender type of a driver that extends
atapi.sys ?

thanks in advance for your help.
–

- Developer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

what would be the advantages of writing a lower filter driver rather
than a system bus extener in my case?

On 8/5/05, Maxim S. Shatskih wrote:
> No, write the LowerFilter for Disk class devices.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Developer”
> To: “Windows System Software Devs Interest List”
> Sent: Thursday, August 04, 2005 1:41 PM
> Subject: [ntdev] system bus extender
>
>
> If I want to write a driver attaching itself below disk.sys , do I
> have to write a system bus extender type of a driver that extends
> atapi.sys ?
>
> thanks in advance for your help.
> –
>
> - Developer
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

–

- Developer

5

beg your pardon just read peter’s mail where he wrote

“But they are not called system bus extenders. They’re called filter
drivers. They work like any other PNP filter driver.”

so I rephrase my question, if I need to write a driver that attaches
itself below disk.sys and above atapi.sys or scsi.sys, which is a
better option, writing an upper filter driver for atapi.sys or
scsi.sys or writing a lower filter for disk.sys.

On 8/5/05, Developer wrote:
> what would be the advantages of writing a lower filter driver rather
> than a system bus extener in my case?
>
>
>
>
>
> On 8/5/05, Maxim S. Shatskih wrote:
> > No, write the LowerFilter for Disk class devices.
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> > ----- Original Message -----
> > From: “Developer”
> > To: “Windows System Software Devs Interest List”
> > Sent: Thursday, August 04, 2005 1:41 PM
> > Subject: [ntdev] system bus extender
> >
> >
> > If I want to write a driver attaching itself below disk.sys , do I
> > have to write a system bus extender type of a driver that extends
> > atapi.sys ?
> >
> > thanks in advance for your help.
> > –
> >
> > - Developer
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> –
>
> - Developer
>

–

- Developer

6

What are you filtering? ATAPI devices? SCSI devices? ATAPI ports? SCSI
ports? Maybe disk drives? The answer to those questions leads to a simple
logical conclusion of where and what you filter. Try N,N,N,N,Y. What are
you going to do with USB or 1394 or iSCSI, or FC drives? They all connect
to only one driver if they are supporting a hard drive.

“Developer” wrote in message news:xxxxx@ntdev…
beg your pardon just read peter’s mail where he wrote

“But they are not called system bus extenders. They’re called filter
drivers. They work like any other PNP filter driver.”

so I rephrase my question, if I need to write a driver that attaches
itself below disk.sys and above atapi.sys or scsi.sys, which is a
better option, writing an upper filter driver for atapi.sys or
scsi.sys or writing a lower filter for disk.sys.

On 8/5/05, Developer wrote:
> what would be the advantages of writing a lower filter driver rather
> than a system bus extener in my case?
>
>
>
>
>
> On 8/5/05, Maxim S. Shatskih wrote:
> > No, write the LowerFilter for Disk class devices.
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> > ----- Original Message -----
> > From: “Developer”
> > To: “Windows System Software Devs Interest List”
> > Sent: Thursday, August 04, 2005 1:41 PM
> > Subject: [ntdev] system bus extender
> >
> >
> > If I want to write a driver attaching itself below disk.sys , do I
> > have to write a system bus extender type of a driver that extends
> > atapi.sys ?
> >
> > thanks in advance for your help.
> > –
> >
> > - Developer
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag argument:
> > ‘’
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> –
>
> - Developer
>

–

- Developer

7

david,

I am trying to write a filter for a sector level disk driver. If you
have had the time and patience to have read a few other posts of mine,
in other threads, you would know that the probelm I am facing is with
IOCTL calls to the disk.sys driver. I was attaching my driver above
disk.sys and intercepting all calls to READ nad WRITE and encrypting
them secor wise. All was going fine till I found out that IOCTL
handling would be impossible, and since I did encrypt all sectors of a
partition, I was confusing disk.sys!!!

Learned ppl suggested that I attach my driver below disk.sys. Hence
all these questions.

Any suggestions now.

thanks.

developer

On 8/5/05, David J. Craig wrote:
> What are you filtering? ATAPI devices? SCSI devices? ATAPI ports? SCSI
> ports? Maybe disk drives? The answer to those questions leads to a simple
> logical conclusion of where and what you filter. Try N,N,N,N,Y. What are
> you going to do with USB or 1394 or iSCSI, or FC drives? They all connect
> to only one driver if they are supporting a hard drive.
>
> “Developer” wrote in message news:xxxxx@ntdev…
> beg your pardon just read peter’s mail where he wrote
>
> “But they are not called system bus extenders. They’re called filter
> drivers. They work like any other PNP filter driver.”
>
> so I rephrase my question, if I need to write a driver that attaches
> itself below disk.sys and above atapi.sys or scsi.sys, which is a
> better option, writing an upper filter driver for atapi.sys or
> scsi.sys or writing a lower filter for disk.sys.
>
>
>
>
> On 8/5/05, Developer wrote:
> > what would be the advantages of writing a lower filter driver rather
> > than a system bus extener in my case?
> >
> >
> >
> >
> >
> > On 8/5/05, Maxim S. Shatskih wrote:
> > > No, write the LowerFilter for Disk class devices.
> > >
> > > Maxim Shatskih, Windows DDK MVP
> > > StorageCraft Corporation
> > > xxxxx@storagecraft.com
> > > http://www.storagecraft.com
> > >
> > > ----- Original Message -----
> > > From: “Developer”
> > > To: “Windows System Software Devs Interest List”
> > > Sent: Thursday, August 04, 2005 1:41 PM
> > > Subject: [ntdev] system bus extender
> > >
> > >
> > > If I want to write a driver attaching itself below disk.sys , do I
> > > have to write a system bus extender type of a driver that extends
> > > atapi.sys ?
> > >
> > > thanks in advance for your help.
> > > –
> > >
> > > - Developer
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: unknown lmsubst tag argument:
> > > ‘’
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> >
> > –
> >
> > - Developer
> >
>
>
> –
>
> - Developer
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

–

- Developer

8

While your thread is fresh in your mind, it ain’t fresh in ours, and some of
our minds aren’t very fresh either, so you have to have patience with us.

If you filter at the hba (scsi or ide) level you will have to write a bus
filter driver, which is undocumented, but you will be filtering at the
lowest possible level for the storage stack. The compelling motivation for
bus filter drivers is devnode hiding/transforming. Doesn’t sound like what
you need.

If you filter at the fdo lower filter driver level you will filter all IRPs
(well all correctly forwarded IRPs) coming out of your target FDO - which as
you want to deal with the SRBs going from disk to scsi - sounds like where
you want to be.

If you filter at the fdo upper filter driver level you will filter all IRPs
coming into your FDO, which you have already done and already rejected as
inadequate.

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Developer
Sent: Friday, August 05, 2005 1:53 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] system bus extender

david,

I am trying to write a filter for a sector level disk driver.
If you have had the time and patience to have read a few
other posts of mine, in other threads, you would know that
the probelm I am facing is with IOCTL calls to the disk.sys
driver. I was attaching my driver above disk.sys and
intercepting all calls to READ nad WRITE and encrypting them
secor wise. All was going fine till I found out that IOCTL
handling would be impossible, and since I did encrypt all
sectors of a partition, I was confusing disk.sys!!!

Learned ppl suggested that I attach my driver below disk.sys.
Hence all these questions.

Any suggestions now.

thanks.

developer

On 8/5/05, David J. Craig wrote:
> > What are you filtering? ATAPI devices? SCSI devices?
> ATAPI ports?
> > SCSI ports? Maybe disk drives? The answer to those
> questions leads to
> > a simple logical conclusion of where and what you filter. Try
> > N,N,N,N,Y. What are you going to do with USB or 1394 or
> iSCSI, or FC
> > drives? They all connect to only one driver if they are
> supporting a hard drive.
> >
> > “Developer” wrote in message
> news:xxxxx@ntdev…
> > beg your pardon just read peter’s mail where he wrote
> >
> > “But they are not called system bus extenders. They’re
> called filter
> > drivers. They work like any other PNP filter driver.”
> >
> > so I rephrase my question, if I need to write a driver that
> attaches
> > itself below disk.sys and above atapi.sys or scsi.sys, which is a
> > better option, writing an upper filter driver for atapi.sys or
> > scsi.sys or writing a lower filter for disk.sys.
> >
> >
> >
> >
> > On 8/5/05, Developer wrote:
> > > what would be the advantages of writing a lower filter
> driver rather
> > > than a system bus extener in my case?
> > >
> > >
> > >
> > >
> > >
> > > On 8/5/05, Maxim S. Shatskih wrote:
> > > > No, write the LowerFilter for Disk class devices.
> > > >
> > > > Maxim Shatskih, Windows DDK MVP
> > > > StorageCraft Corporation
> > > > xxxxx@storagecraft.com
> > > > http://www.storagecraft.com
> > > >
> > > > ----- Original Message -----
> > > > From: “Developer”
> > > > To: “Windows System Software Devs Interest List”
> > > >
> > > > Sent: Thursday, August 04, 2005 1:41 PM
> > > > Subject: [ntdev] system bus extender
> > > >
> > > >
> > > > If I want to write a driver attaching itself below
> disk.sys , do I
> > > > have to write a system bus extender type of a driver
> that extends
> > > > atapi.sys ?
> > > >
> > > > thanks in advance for your help.
> > > > –
> > > >
> > > > - Developer
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: unknown
> lmsubst tag argument:
> > > > ‘’
> > > > To unsubscribe send a blank email to
> > > > xxxxx@lists.osr.com
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as:
> xxxxx@gmail.com To
> > > > unsubscribe send a blank email to
> xxxxx@lists.osr.com
> > > >
> > >
> > >
> > > –
> > >
> > > - Developer
> > >
> >
> >
> > –
> >
> > - Developer
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@gmail.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> –
>
> - Developer
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

9

Mark,

While your thread is fresh in your mind, it ain’t fresh in ours, and some of
our minds aren’t very fresh either, so you have to have patience with us.

Beg your pardon if my mail hurt you, what I had meant actually was
that perhaps not all of you would have had the time to go through all
the mails coming in the lists. Still, apologies, to everybody from
me.

If you filter at the hba (scsi or ide) level you will have to write a bus
filter driver, which is undocumented, but you will be filtering at the
lowest possible level for the storage stack. The compelling motivation for
bus filter drivers is devnode hiding/transforming. Doesn’t sound like what
you need.

True, even I ave the same feeling.

If you filter at the fdo lower filter driver level you will filter all IRPs
(well all correctly forwarded IRPs) coming out of your target FDO - which as
you want to deal with the SRBs going from disk to scsi - sounds like where
you want to be.

Yes, I has going through the code of disk.sys supplied with DDK, it
seems that IOCTL handling is done quite a lot by the driver. Now I
have two options, either I place my driver *above* disk.sys and
intercept the IOCTLs, manually simulate the desired operations,
reference is disk.sys and send them up, while disk.sys remains
oblivious of such calls, else I attach the driver as a lower filter
driver to disk.sys and intercept the calls disk.sys makes to the lower
driver and modify them. Option two does not look very good to me, as
Disk.sy might have routines to directly get information from the
devices (please correct me if I am wrong).

Many of you have however, pointed out that I should attach below
disk.sys as a lower filter. What I am unable to perceive, is how do I
send correct information for the SRBs when disk.sys *doesn’t* issue an
IRP always for them (referring to the sample code).

I again apologise as it is a very emilentary question, may be not
worth your time Still if some of you can help, it would be great.

  • Developer

If you filter at the fdo upper filter driver level you will filter all IRPs
coming into your FDO, which you have already done and already rejected as
inadequate.

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Developer
> Sent: Friday, August 05, 2005 1:53 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] system bus extender
>
> david,
>
> I am trying to write a filter for a sector level disk driver.
> If you have had the time and patience to have read a few
> other posts of mine, in other threads, you would know that
> the probelm I am facing is with IOCTL calls to the disk.sys
> driver. I was attaching my driver above disk.sys and
> intercepting all calls to READ nad WRITE and encrypting them
> secor wise. All was going fine till I found out that IOCTL
> handling would be impossible, and since I did encrypt all
> sectors of a partition, I was confusing disk.sys!!!
>
> Learned ppl suggested that I attach my driver below disk.sys.
> Hence all these questions.
>
> Any suggestions now.
>
> thanks.
>
> developer
>
> On 8/5/05, David J. Craig wrote:
> > > What are you filtering? ATAPI devices? SCSI devices?
> > ATAPI ports?
> > > SCSI ports? Maybe disk drives? The answer to those
> > questions leads to
> > > a simple logical conclusion of where and what you filter. Try
> > > N,N,N,N,Y. What are you going to do with USB or 1394 or
> > iSCSI, or FC
> > > drives? They all connect to only one driver if they are
> > supporting a hard drive.
> > >
> > > “Developer” wrote in message
> > news:xxxxx@ntdev…
> > > beg your pardon just read peter’s mail where he wrote
> > >
> > > “But they are not called system bus extenders. They’re
> > called filter
> > > drivers. They work like any other PNP filter driver.”
> > >
> > > so I rephrase my question, if I need to write a driver that
> > attaches
> > > itself below disk.sys and above atapi.sys or scsi.sys, which is a
> > > better option, writing an upper filter driver for atapi.sys or
> > > scsi.sys or writing a lower filter for disk.sys.
> > >
> > >
> > >
> > >
> > > On 8/5/05, Developer wrote:
> > > > what would be the advantages of writing a lower filter
> > driver rather
> > > > than a system bus extener in my case?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 8/5/05, Maxim S. Shatskih wrote:
> > > > > No, write the LowerFilter for Disk class devices.
> > > > >
> > > > > Maxim Shatskih, Windows DDK MVP
> > > > > StorageCraft Corporation
> > > > > xxxxx@storagecraft.com
> > > > > http://www.storagecraft.com
> > > > >
> > > > > ----- Original Message -----
> > > > > From: “Developer”
> > > > > To: “Windows System Software Devs Interest List”
> > > > >
> > > > > Sent: Thursday, August 04, 2005 1:41 PM
> > > > > Subject: [ntdev] system bus extender
> > > > >
> > > > >
> > > > > If I want to write a driver attaching itself below
> > disk.sys , do I
> > > > > have to write a system bus extender type of a driver
> > that extends
> > > > > atapi.sys ?
> > > > >
> > > > > thanks in advance for your help.
> > > > > –
> > > > >
> > > > > - Developer
> > > > >
> > > > > —
> > > > > Questions? First check the Kernel Driver FAQ at
> > > > > http://www.osronline.com/article.cfm?id=256
> > > > >
> > > > > You are currently subscribed to ntdev as: unknown
> > lmsubst tag argument:
> > > > > ‘’
> > > > > To unsubscribe send a blank email to
> > > > > xxxxx@lists.osr.com
> > > > >
> > > > >
> > > > > —
> > > > > Questions? First check the Kernel Driver FAQ at
> > > > > http://www.osronline.com/article.cfm?id=256
> > > > >
> > > > > You are currently subscribed to ntdev as:
> > xxxxx@gmail.com To
> > > > > unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> > > > >
> > > >
> > > >
> > > > –
> > > >
> > > > - Developer
> > > >
> > >
> > >
> > > –
> > >
> > > - Developer
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@gmail.com To
> > > unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> >
> > –
> >
> > - Developer
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag
> > argument: ‘’
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

–

- Developer

10

I don’t quite understand what you mean by the case “where disk.sys doesn’t
issue an IRP”. If there is no IRP there is no IO to filter, nor it seems is
anything actually being done to the state of the ‘real’ device. Perhaps you
could be more explicit about what problem you are trying to solve here.

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Developer
Sent: Friday, August 05, 2005 8:26 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] system bus extender

Mark,

> While your thread is fresh in your mind, it ain’t fresh in
ours, and
> some of our minds aren’t very fresh either, so you have to
have patience with us.

Beg your pardon if my mail hurt you, what I had meant
actually was that perhaps not all of you would have had the
time to go through all the mails coming in the lists. Still,
apologies, to everybody from me.

> If you filter at the hba (scsi or ide) level you will have
to write a
> bus filter driver, which is undocumented, but you will be
filtering at
> the lowest possible level for the storage stack. The compelling
> motivation for bus filter drivers is devnode hiding/transforming.
> Doesn’t sound like what you need.

True, even I ave the same feeling.

> If you filter at the fdo lower filter driver level you will
filter all
> IRPs (well all correctly forwarded IRPs) coming out of your
target FDO
> - which as you want to deal with the SRBs going from disk to scsi -
> sounds like where you want to be.

Yes, I has going through the code of disk.sys supplied with
DDK, it seems that IOCTL handling is done quite a lot by the
driver. Now I have two options, either I place my driver
*above* disk.sys and intercept the IOCTLs, manually simulate
the desired operations, reference is disk.sys and send them
up, while disk.sys remains oblivious of such calls, else I
attach the driver as a lower filter driver to disk.sys and
intercept the calls disk.sys makes to the lower driver and
modify them. Option two does not look very good to me, as
Disk.sy might have routines to directly get information from
the devices (please correct me if I am wrong).

Many of you have however, pointed out that I should attach
below disk.sys as a lower filter. What I am unable to
perceive, is how do I send correct information for the SRBs
when disk.sys *doesn’t* issue an IRP always for them
(referring to the sample code).

I again apologise as it is a very emilentary question, may be
not worth your time Still if some of you can help, it would be great.

  • Developer
    >
    > If you filter at the fdo upper filter driver level you will
    filter all
    > IRPs coming into your FDO, which you have already done and already
    > rejected as inadequate.
    >
    > =====================
    > Mark Roddy DDK MVP
    > Windows 2003/XP/2000 Consulting
    > Hollis Technology Solutions 603-321-1032 www.hollistech.com
    >
    > > -----Original Message-----
    > > From: xxxxx@lists.osr.com
    > > [mailto:xxxxx@lists.osr.com] On Behalf Of Developer
    > > Sent: Friday, August 05, 2005 1:53 AM
    > > To: Windows System Software Devs Interest List
    > > Subject: Re: [ntdev] system bus extender
    > >
    > > david,
    > >
    > > I am trying to write a filter for a sector level disk driver.
    > > If you have had the time and patience to have read a few
    other posts
    > > of mine, in other threads, you would know that the probelm I am
    > > facing is with IOCTL calls to the disk.sys driver. I was
    attaching
    > > my driver above disk.sys and intercepting all calls to READ nad
    > > WRITE and encrypting them secor wise. All was going fine till I
    > > found out that IOCTL handling would be impossible, and
    since I did
    > > encrypt all sectors of a partition, I was confusing disk.sys!!!
    > >
    > > Learned ppl suggested that I attach my driver below disk.sys.
    > > Hence all these questions.
    > >
    > > Any suggestions now.
    > >
    > > thanks.
    > >
    > > developer
    > >
    > > On 8/5/05, David J. Craig wrote:
    > > > > What are you filtering? ATAPI devices? SCSI devices?
    > > > ATAPI ports?
    > > > > SCSI ports? Maybe disk drives? The answer to those
    > > > questions leads to
    > > > > a simple logical conclusion of where and what you filter. Try
    > > > > N,N,N,N,Y. What are you going to do with USB or 1394 or
    > > > iSCSI, or FC
    > > > > drives? They all connect to only one driver if they are
    > > > supporting a hard drive.
    > > > >
    > > > > “Developer” wrote in message
    > > > news:xxxxx@ntdev…
    > > > > beg your pardon just read peter’s mail where he wrote
    > > > >
    > > > > “But they are not called system bus extenders. They’re
    > > > called filter
    > > > > drivers. They work like any other PNP filter driver.”
    > > > >
    > > > > so I rephrase my question, if I need to write a driver that
    > > > attaches
    > > > > itself below disk.sys and above atapi.sys or scsi.sys,
    > which is a
    > > > > better option, writing an upper filter driver for atapi.sys or
    > > > > scsi.sys or writing a lower filter for disk.sys.
    > > > >
    > > > >
    > > > >
    > > > >
    > > > > On 8/5/05, Developer wrote:
    > > > > > what would be the advantages of writing a lower filter
    > > > driver rather
    > > > > > than a system bus extener in my case?
    > > > > >
    > > > > >
    > > > > >
    > > > > >
    > > > > >
    > > > > > On 8/5/05, Maxim S. Shatskih wrote:
    > > > > > > No, write the LowerFilter for Disk class devices.
    > > > > > >
    > > > > > > Maxim Shatskih, Windows DDK MVP StorageCraft Corporation
    > > > > > > xxxxx@storagecraft.com http://www.storagecraft.com
    > > > > > >
    > > > > > > ----- Original Message -----
    > > > > > > From: “Developer”
    > > > > > > To: “Windows System Software Devs Interest List”
    > > > > > >
    > > > > > > Sent: Thursday, August 04, 2005 1:41 PM
    > > > > > > Subject: [ntdev] system bus extender
    > > > > > >
    > > > > > >
    > > > > > > If I want to write a driver attaching itself below
    > > > disk.sys , do I
    > > > > > > have to write a system bus extender type of a driver
    > > > that extends
    > > > > > > atapi.sys ?
    > > > > > >
    > > > > > > thanks in advance for your help.
    > > > > > > –
    > > > > > >
    > > > > > > - Developer
    > > > > > >
    > > > > > > —
    > > > > > > Questions? First check the Kernel Driver FAQ at
    > > > > > > http://www.osronline.com/article.cfm?id=256
    > > > > > >
    > > > > > > You are currently subscribed to ntdev as: unknown
    > > > lmsubst tag argument:
    > > > > > > ‘’
    > > > > > > To unsubscribe send a blank email to
    > > > > > > xxxxx@lists.osr.com
    > > > > > >
    > > > > > >
    > > > > > > —
    > > > > > > Questions? First check the Kernel Driver FAQ at
    > > > > > > http://www.osronline.com/article.cfm?id=256
    > > > > > >
    > > > > > > You are currently subscribed to ntdev as:
    > > > xxxxx@gmail.com To
    > > > > > > unsubscribe send a blank email to
    > > > xxxxx@lists.osr.com
    > > > > > >
    > > > > >
    > > > > >
    > > > > > –
    > > > > >
    > > > > > - Developer
    > > > > >
    > > > >
    > > > >
    > > > > –
    > > > >
    > > > > - Developer
    > > > >
    > > > >
    > > > >
    > > > > —
    > > > > Questions? First check the Kernel Driver FAQ at
    > > > > http://www.osronline.com/article.cfm?id=256
    > > > >
    > > > > You are currently subscribed to ntdev as:
    > xxxxx@gmail.com To
    > > > > unsubscribe send a blank email to
    > xxxxx@lists.osr.com
    > > > >
    > > >
    > > >
    > > > –
    > > >
    > > > - Developer
    > > >
    > > > —
    > > > Questions? First check the Kernel Driver FAQ at
    > > > http://www.osronline.com/article.cfm?id=256
    > > >
    > > > You are currently subscribed to ntdev as: unknown lmsubst tag
    > > > argument: ‘’
    > > > To unsubscribe send a blank email to
    > xxxxx@lists.osr.com
    > > >
    > >
    > >
    > >
    > > —
    > > Questions? First check the Kernel Driver FAQ at
    > > http://www.osronline.com/article.cfm?id=256
    > >
    > > You are currently subscribed to ntdev as: xxxxx@gmail.com To
    > > unsubscribe send a blank email to xxxxx@lists.osr.com
    > >
    >
    >
    > –
    >
    > - Developer
    >
    > —
    > Questions? First check the Kernel Driver FAQ at
    > http://www.osronline.com/article.cfm?id=256
    >
    > You are currently subscribed to ntdev as: unknown lmsubst tag
    > argument: ‘’
    > To unsubscribe send a blank email to xxxxx@lists.osr.com
    >
11

Disk only communicates to the lower driver through IRPs. You can filter
everything if you are below the disk driver.

This does NOT mean that you’re filtering “atapi.sys” or “scsi.sys”. You
don’t want to think about it in those terms. You’re filter is part of a
device stack loaded on a PDO that supports the mass-storage interface
(which consists of IRP_MJ_SCSI and a handful of I/O controls). That PDO
could be exposed by atapi.sys, usbmass.sys, aha154x.sys, or any other
storage bus driver.

Within that stack, you need to be someplace between the PDO (which
understand this mass-storage interface) and the class driver (which
converts read/write/ioctl requests into mass-storage interface type
requests). If there are other filters you may need to be concerned
about their order as well, but for the most part you’re just worried
about your order relative to disk.sys.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Developer
Sent: Friday, August 05, 2005 5:26 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] system bus extender

Mark,

While your thread is fresh in your mind, it ain’t fresh in ours, and
some of our minds aren’t very fresh either, so you have to have
patience with us.

Beg your pardon if my mail hurt you, what I had meant actually was that
perhaps not all of you would have had the time to go through all the
mails coming in the lists. Still, apologies, to everybody from me.

If you filter at the hba (scsi or ide) level you will have to write a
bus filter driver, which is undocumented, but you will be filtering at

the lowest possible level for the storage stack. The compelling
motivation for bus filter drivers is devnode hiding/transforming.
Doesn’t sound like what you need.

True, even I ave the same feeling.

If you filter at the fdo lower filter driver level you will filter all

IRPs (well all correctly forwarded IRPs) coming out of your target FDO

  • which as you want to deal with the SRBs going from disk to scsi -
    sounds like where you want to be.

Yes, I has going through the code of disk.sys supplied with DDK, it
seems that IOCTL handling is done quite a lot by the driver. Now I have
two options, either I place my driver *above* disk.sys and intercept the
IOCTLs, manually simulate the desired operations, reference is disk.sys
and send them up, while disk.sys remains oblivious of such calls, else I
attach the driver as a lower filter driver to disk.sys and intercept the
calls disk.sys makes to the lower driver and modify them. Option two
does not look very good to me, as Disk.sy might have routines to
directly get information from the devices (please correct me if I am
wrong).

Many of you have however, pointed out that I should attach below
disk.sys as a lower filter. What I am unable to perceive, is how do I
send correct information for the SRBs when disk.sys *doesn’t* issue an
IRP always for them (referring to the sample code).

I again apologise as it is a very emilentary question, may be not worth
your time Still if some of you can help, it would be great.

  • Developer

If you filter at the fdo upper filter driver level you will filter all

IRPs coming into your FDO, which you have already done and already
rejected as inadequate.

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032 www.hollistech.com

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Developer
> Sent: Friday, August 05, 2005 1:53 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] system bus extender
>
> david,
>
> I am trying to write a filter for a sector level disk driver.
> If you have had the time and patience to have read a few other posts

> of mine, in other threads, you would know that the probelm I am
> facing is with IOCTL calls to the disk.sys driver. I was attaching
> my driver above disk.sys and intercepting all calls to READ nad
> WRITE and encrypting them secor wise. All was going fine till I
> found out that IOCTL handling would be impossible, and since I did
> encrypt all sectors of a partition, I was confusing disk.sys!!!
>
> Learned ppl suggested that I attach my driver below disk.sys.
> Hence all these questions.
>
> Any suggestions now.
>
> thanks.
>
> developer
>
> On 8/5/05, David J. Craig wrote:
> > > What are you filtering? ATAPI devices? SCSI devices?
> > ATAPI ports?
> > > SCSI ports? Maybe disk drives? The answer to those
> > questions leads to
> > > a simple logical conclusion of where and what you filter. Try
> > > N,N,N,N,Y. What are you going to do with USB or 1394 or
> > iSCSI, or FC
> > > drives? They all connect to only one driver if they are
> > supporting a hard drive.
> > >
> > > “Developer” wrote in message
> > news:xxxxx@ntdev…
> > > beg your pardon just read peter’s mail where he wrote
> > >
> > > “But they are not called system bus extenders. They’re
> > called filter
> > > drivers. They work like any other PNP filter driver.”
> > >
> > > so I rephrase my question, if I need to write a driver that
> > attaches
> > > itself below disk.sys and above atapi.sys or scsi.sys, which is a
> > > better option, writing an upper filter driver for atapi.sys or
> > > scsi.sys or writing a lower filter for disk.sys.
> > >
> > >
> > >
> > >
> > > On 8/5/05, Developer wrote:
> > > > what would be the advantages of writing a lower filter
> > driver rather
> > > > than a system bus extener in my case?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 8/5/05, Maxim S. Shatskih wrote:
> > > > > No, write the LowerFilter for Disk class devices.
> > > > >
> > > > > Maxim Shatskih, Windows DDK MVP StorageCraft Corporation
> > > > > xxxxx@storagecraft.com http://www.storagecraft.com
> > > > >
> > > > > ----- Original Message -----
> > > > > From: “Developer”
> > > > > To: “Windows System Software Devs Interest List”
> > > > >
> > > > > Sent: Thursday, August 04, 2005 1:41 PM
> > > > > Subject: [ntdev] system bus extender
> > > > >
> > > > >
> > > > > If I want to write a driver attaching itself below
> > disk.sys , do I
> > > > > have to write a system bus extender type of a driver
> > that extends
> > > > > atapi.sys ?
> > > > >
> > > > > thanks in advance for your help.
> > > > > –
> > > > >
> > > > > - Developer
> > > > >
> > > > > —
> > > > > Questions? First check the Kernel Driver FAQ at
> > > > > http://www.osronline.com/article.cfm?id=256
> > > > >
> > > > > You are currently subscribed to ntdev as: unknown
> > lmsubst tag argument:
> > > > > ‘’
> > > > > To unsubscribe send a blank email to
> > > > > xxxxx@lists.osr.com
> > > > >
> > > > >
> > > > > —
> > > > > Questions? First check the Kernel Driver FAQ at
> > > > > http://www.osronline.com/article.cfm?id=256
> > > > >
> > > > > You are currently subscribed to ntdev as:
> > xxxxx@gmail.com To
> > > > > unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> > > > >
> > > >
> > > >
> > > > –
> > > >
> > > > - Developer
> > > >
> > >
> > >
> > > –
> > >
> > > - Developer
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@gmail.com To
> > > unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> >
> > –
> >
> > - Developer
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag
> > argument: ‘’
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>

–

- Developer

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com