Are you attaching as a volume filter or a disk filter? Have you tried
the diskperf sample driver in the WDK? It is a class filter driver
which, I think, is what you want. You don’t have to go through what you
are doing, you are handed a device object in the AddDevice callback and
you attach to the stack. To begin, I would start there.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
------ Original Message ------
From: xxxxx@gmail.com
To: “Windows File Systems Devs Interest List”
Sent: 10/14/2016 5:45:49 PM
Subject: RE:[ntfsd] Re[2]: Re[2]: Reading a file only by using
IofCallDriver
>Thank you again for the response.
>
>I’ve been reading about setting up device filters but the information
>online is not really beginner friendly. I’ve attached a volume filter
>to the mentioned device by using the following:
>
>1) IoGetDeviceObjectPointer (for target device)
>2) IoGetDeviceAttachmentBaseRef
>3) IoCreateDevice (create the filter device)
>4) IoAttachDeviceToDeviceStackSafe
>
>So now I can filter most IRPs - except the ones being sent when the
>driver (the one I’ve been researching) first calls
>IoGetBaseFileSystemDeviceObject. It looks like this function allows
>that driver to bypass my filter driver again.
>
>The question is, is there any way to catch these IRPs? Can a
>lower-level filter help in this situation? If the answer to that
>question is yes, then my next question is how do I set a lower-level
>filter?
>
>—
>NTFSD is sponsored by OSR
>
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:>
Except for the device object that is used with IoAttachDeviceToDeviceStackSafe I’m not exactly sure about the differences between a volume, disk or class filter. I am attaching my filter driver to a disk device though. I went over the diskperf sample and used it as reference. The AddDevice callback is not relevant (at least from my limited understanding) to my situation because I’m loading my filter driver on demand and attaching to an existing device (a disk device) during OS runtime.
I am able to attach my filter driver to the stack and filter out all ‘normal’ IRPs. The problem occurs when the driver I’m researching calls IoGetBaseFileSystemDeviceObject - it gets a pointer to the device i’m filtering instead of a pointer to the filter device I created and attached to the stack. This effectively bypasses my filter driver (or everything else for that matter) when calling IofCallDriver (which jumps to storport.sys).
Is there a way to tell the kernel that my filter device is the lowest device in the stack? I know it sounds like a bad hack, but so far it doesn’t look like there’s another way to deal with how the above mentioned driver bypasses all conventional filters. Alternatively, how can I implement a filter that is effective in this situation?
Arg, I’m sorry for being such a noob. After using the !devstack command in windbg, I saw that my filter driver gets attached to the top of the stack, and not above the lowest device.
So I’m back to square one now, the stack looks like this:
\Driver\MYFILTER ffff9e09d4949e20 <-----
\Driver\partmgr ffff9e09d2355c30
\Driver\disk ffff9e09d23551b0 DR0
\Driver\LSI_SAS ffff9e09d0ebf550 0000006e
how can I get it to look like this:
\Driver\partmgr ffff9e09d2355c30
\Driver\disk ffff9e09d23551b0 DR0
\Driver\MYFILTER ffff9e09d4949e20 <-----
\Driver\LSI_SAS ffff9e09d0ebf550 0000006e
Ok I’ve learned about class filters, and I finally understand when and how AddDevice comes into play.
Thank you for the help.