System lagging when my filter driver attaches to C:

NTFSD
1

I have written a minifilter driver to implement Policy-Based Access Control (PBAC) for the file system. Currently, my implementation is very simple. Below is the situation of my driver implementation:

  1. The PBAC driver attaches to all devices (including the C: drive);
  2. It processes IRP_MJ_CREATE type IOs on the devices, obtaining the IO request filename in the pre-callback using FltGetFileNameInformation;
  3. Using the obtained filename (e.g., \Device\HarddiskVolume4\dir1\file.txt), it traverses through the access rule list. Each rule in the rule list contains a path (e.g., \Device\HarddiskVolume4\dir1) and performs prefix matching checks against the filename;
  4. If the filename matches the rule prefix, it sets the IRP_MJ_CREATE result to STATUS_ACCESS_DENIED and returns the IO result. If there's no match, it allows the IO to continue normal processing.

This implementation can already functionally achieve my goals. However, I've noticed that my system has become sluggish. After investigation, I found that the system doesn't lag when I don't attach to the C: drive.

I suspect that system IOs on the C: drive going through my PBAC driver are causing increased response latency, which leads to system sluggishness. I hope to improve this issue. I currently have three optimization ideas:

  1. Add whitelist directories on the C: drive (e.g., C:\Windows\System32), where files in these directories would not be subject to access control;
  2. Add a process whitelist. If the IO request comes from a process with PID less than 4 (system processes), then no access control would be applied;
  3. Use stream context to cache access status for each file. In the file's IRP_MJ_CREATE pre-callback, first check if there's a stream context (FltGetStreamContext). If not, perform rule matching while setting a stream context for the file and caching the matching result in the stream context. The next time the file is opened, directly determine accessibility through the stream context.

My experience in driver development is quite limited, so I would love to pick the brains of experienced engineers on whether there might be better solutions or suggestions for handling this scenario. I would be immensely grateful for any valuable insights you could share.

2

I recommend starting by looking at performance traces to confirm that your driver is causing the slowdown, and then digging in to see where the slowdown is happening. In my experience, the results are often surprising.

3

Thanks for the tip, Alnoor. I’ve started checking out the Windows Performance Toolkit like you suggested. It makes sense to confirm what’s causing the slowdown before making changes.

Also wondering—has anyone seen performance issues when using FltGetFileNameInformation a lot, especially on system paths like C:\Windows? I’m thinking it might be part of the slowdown in my case.

Any advice would be really helpful!