Mini-filter vs. legacy performance overhead of opening a file in IRP_MJ_CREATE

NTFSD
1

Has anyone compared the difference between the performance overhead
of issuing a FltCreateFile/Ex/2 vs. issuing a IRP_MJ_CREATE from a
legacy driver?

For one project, I need to make 2 additional file open calls during
processing of IRP_MJ_CREATE in a mini-filter, and that mere code
presents such a performance overhead that we cannot ship the driver (it
seems to be the primary cause, though in some cases certain AVs “help”).

Most of the time, the creates will go to a non-existing file, but we
cannot make rules where to make them (i.e. only in a set of directories
for example).

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

2

When you say “issuing a IRP_MJ_CREATE from a legacy driver” do you mean
calling IoCreateFile(…) or do you literally mean allocating and sending an
IRP_MJ_CREATE IRP below ?

Thanks,
Alex.

3

Either - I reckon for a legacy driver both would have the same performance.

Alex Carp wrote:

When you say “issuing a IRP_MJ_CREATE from a legacy driver” do you mean
calling IoCreateFile(…) or do you literally mean allocating and sending an
IRP_MJ_CREATE IRP below ?

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

4

Well, FltCreateFile(Ex(2)) isn’t really that thick of a layer over
IoCreateFileEx if I remember correctly.

Just for the fun of it, can you replace your FltCreateFile call with an
IoCreateFile and see what the perf hit is ?

For the archive I want to state that this approach would definitely have
issues in production but for perf testing in this limited scenario it might
work.

Thanks,
Alex.

5

Which version of Windows are you using for the benchmark Dejan?

I seem to recall that on XP we saw the context switch overhead of using kernel handles was stunningly high (it does a KeStackAttachProcess to the system process, but uses a different mechanism in later versions) for example. I wouldn’t expect that overhead at all for sending an IRP_MJ_CREATE directly, but I would expect to see it in IoCreateFileSpecifyDeviceObjectHint (as I think that context switch is implemented in this routine.)

Tony
OSR

Hope to see everyone September 19 for the next Developing File Systems for Windows seminar (http://www.osr.com/fsd.html)

6

We tested on several XP and W7 configurations (other OSes as well, but these two make 95% of the test machines if not more).
Does using kernel handles also apply to using ObReferenceObjectByHandle to get the file object and then using that file object or not? This is what we do in the mini-filter for obvious reasons (FltMgr API don’t support handles and yet FltCreateFile only a handle!!!)

Tony Mason wrote:

Which version of Windows are you using for the benchmark Dejan?

I seem to recall that on XP we saw the context switch overhead of using kernel handles was stunningly high (it does a KeStackAttachProcess to the system process, but uses a different mechanism in later versions) for example. I wouldn’t expect that overhead at all for sending an IRP_MJ_CREATE directly, but I would expect to see it in IoCreateFileSpecifyDeviceObjectHint (as I think that context switch is implemented in this routine.)

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.