Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTFSD
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Performance Regression regarding UNC access

Bastian_WeßlingBastian_Weßling Member Posts: 10

Hello everyone,

we develop a product that uses a minifilter to restrict which files may be accessed in which way on which device. We noticed that the performance for accessing files on UNC shares regressed over the past Windows versions - without our product, but even more so with our product installed.

We measured startup times of Visual Studio Code from a network share:

  • Without our product:
    ** Windows 7: 8,89s
    ** Windows 10 1709: 9,99s
    ** Windows 10 1909: 11,32s
    ** Windows 10 2004: 16,68s

  • With our minifilter:
    ** Windows 7: 9,51s
    ** Windows 10 1709: 28,34s
    ** Windows 10 1909: 40,04s
    ** Windows 10 2004: 34,65s

Does anyone have any pointers for me?

  • How can I profile the minifilter?
  • Was there any change in Windows that would lead to such a regression? If so, is there a known remedy we could implement to decrease the gap between performance with and without our driver?

Thank you!

Comments

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 401
    via Email
    My preferred way of profiling something like this is Process Monitor.
    With and without our filter, and below/above our filter (4 cases,
    giving us a chance to see if the slowdown is in our driver or not).

    So much for SMB3 :)


    > we develop a product that uses a minifilter to restrict which files may be
    > accessed in which way on which device. We noticed that the performance for
    > accessing files on UNC shares regressed over the past Windows versions -
    > without our product, but even more so with our product installed.
    >
    > We measured startup times of Visual Studio Code from a network share:
    >
    > * Without our product:
    >
    > ** Windows 7: 8,89s
    >
    > ** Windows 10 1709: 9,99s
    >
    > ** Windows 10 1909: 11,32s
    >
    > ** Windows 10 2004: 16,68s
    >
    >
    > * With our minifilter:
    >
    > ** Windows 7: 9,51s
    >
    > ** Windows 10 1709: 28,34s
    >
    > ** Windows 10 1909: 40,04s
    >
    > ** Windows 10 2004: 34,65s
    >
    >
    >
    > Does anyone have any pointers for me?
    >
    > * How can I profile the minifilter?
    > * Was there any change in Windows that would lead to such a regression? If
    > so, is there a known remedy we could implement to decrease the gap between
    > performance with and without our driver?
    >
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,317

    Agree. Well, with ProcMon you’re not really “profiling” as in timing so much as you’re analyzing what’s going on. The operative question is “Why is it so much slower? What’s different from the unfiltered case?” This is rarely fun.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,401

    No idea about the regression without your filter. I wouldn't start by looking at closing that gap to get your numbers down though.

    You can get timings for your minifilter callbacks with WPR/WPA

    That gives you VERY fine grained data though and not really helpful if you don't know what you're looking for.

    I'd start by thinking about what my driver does and how it might impact an app launch. At a high level, what does your driver do? Approve/deny based on hash? Name? Do you filter every open? Every read?

    One random thing pops to mind: do you query for normalized names? That can be killer on the network.

    -scott
    OSR

  • Bastian_WeßlingBastian_Weßling Member Posts: 10

    After lots of research using procmon as well as WPT, I come to the same conclusion: We channel each request through a user mode process that works like this: At first we determine the user name and also the executable name (via GetModuleFileNameEx). If I replace this code with returning constant strings, VSCode starts much faster - and I did not even have to touch the filter driver. That part of the problem seems to be of our own making. We then use these names to check against a list of rules (is the user allowed to open a file X using Y program for reading/writing/deleting/...?).

    I believe that our rules also are not as fast as they could be, but the biggest problem seems to be the lack of a cache for the executable names. Resolving the same name for every request is just bound to be slower than necessary.

  • Bastian_WeßlingBastian_Weßling Member Posts: 10

    As a side question, how badly does it reduce performance if our minifilter simply returns FLT_PREOP_DISALLOW_FASTIO for all FastIo requests? If Windows 10 relies more on FastIo, that would be another reason for the regression we are noticing when our driver is installed.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE