Maxim
Thu Apr 13 12:43:17 CDT 2006
I would detach these nasty misbehaving filters and just throw them away
from the stack (so they will no more monitor the IRP flow) above you instead of
hooking SSDT.
BTW - hooking SSDT will not filter paging IO.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com
"Kenny" <kendolew@newsgroups.nospam> wrote in message
news:768499B1-03D7-4B2F-A340-09277469A0D3@microsoft.com...
> Hooking kernel SSDT on vista wouldn't work, but hooking on the device's
> dispatch routine seems to work.
> What I don't understand is why they'd allow the driver stack to be bypassed
> directly, if a *clean* structure is required.
> sigh.
>
> --
> EWK Liew
>
>
> "Don Burn" wrote:
>
> > First hooking will not work on later OS'es. Second even if you hook you
> > cannot guarantee somebody else has not hooked so you have a real mess,
> > including you still cannot guarantee if the other hooker grabed the vectors
> > you still won't get everything. Botttom line, is if you absolutely must
have
> > all calls, your design if likely to be bad. As I said in the first post,
> > you can't assume you are on the bottom, and it is legal to just send things
> > down, so you are violating part of the Windows design.
> >
> > I would move this to NTFSD list at
http://www.osronline.com/ since that is
> > the file system list (including the Microsoft guys hang out there).
Explain
> > what you need and why you need it, there may be an answer that someone can
> > give.
> >
> >
> > --
> > Don Burn (MVP, Windows DDK)
> > Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > Remove StopSpam from the email to reply
> >
> >
> >
> > "Kenny" <kendolew@newsgroups.nospam> wrote in message
> > news:B6AAD783-DC6F-4937-88BC-1041C8DCB8EC@microsoft.com...
> > > Thanks for the reply Don,
> > > Yes, I'm working on the file system. Does that mean that hooking is still
> > > the only way forward for me? The downside is that I won't be able to
> > > unload
> > > properly as some other drivers may hook to that device after me.
> > > Isn't bypassing the driver stack a risky affair as there'll be some sync
> > > problems with other drivers layered on top?
> > > This doesn't look good for me.
> > >
> > > cheers.
> > > --
> > > EWK Liew
> > >
> > >
> > > "Don Burn" wrote:
> > >
> > >> Unfortunately there is no way to guarantee it. Since you are referring
> > >> to
> > >> mini-filters I am assuming you mean file system work. This is the
reason
> > >> Microsoft has the IFS plugfests to try to test that IFS filter drivers
> > >> play
> > >> nice with one another. Note, you have the problem anyway since you
> > >> cannot
> > >> guarantee your position in the driver stack, and there is nothing that
> > >> stops
> > >> a driver from creating and passing an IRP to a lower level driver.
> > >>
> > >>
> > >> --
> > >> Don Burn (MVP, Windows DDK)
> > >> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> > >> Remove StopSpam from the email to reply
> > >>
> > >>
> > >>
> > >> "Kenny" <kendolew@newsgroups.nospam> wrote in message
> > >> news:860CD766-152A-4EE7-A437-0405EE450952@microsoft.com...
> > >> > Hi,
> > >> > I've read somewhere that to filter an IRP properly, mini filters
should
> > >> > be
> > >> > used (besides IoAttachDeviceToDeviceStack). I've also read that it's
> > >> > dangerous to bypass the driver stack and communicate with the device
> > >> > directly
> > >> > as it may cause instablity. However, I've came across some common
> > >> > drivers
> > >> > which do that, in this case the filter manager is being bypassed (i.e.
> > >> > it
> > >> > doesn't get to filter an irp at all) for a simple read operation.
> > >> > Obviously
> > >> > all other drivers in the stack are bypassed too. Is there another way
> > >> > to
> > >> > guarantee IRP filtering, apart from the mini filter approach, besides
> > >> > hooking? I've tried hooking the dispatch routine for the device, and
it
> > >> > works, but this is a bad way, hence I'm trying to find a better
> > >> > alternative.
> > >> >
> > >> > cheers
> > >> > --
> > >> > EWK Liew
> > >>
> > >>
> > >>
> >
> >
> >