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/


VMWare Horizon, slow performance with FltPerformSynchronousIo during IRP_MJ_CLEANUP

Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 334
Hi, all,

We have a VMWare Horizon set up, regular desktop, that attaches shared
folders.
Our filter performs a query for file attributes, delete pending flag and
other "file infos" during IRP_MJ_CLEANUP. We have tested several cases, and
any call via FltPerformSyncronousIo causes extreme performance slowdowns.

Anyone have a clue how to avoid it, or found a workaround? The calls
have to be during CleanupPreOp :( FltPerformSynchronousIo is used instead
of FltQueryInformationFile, to avoid RDPDR bugcheck, since FQIF performs
async I/O.

Kind regards, Dejan.

Comments

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 334
    Noone?

    Kind regards, Dejan.


    On Wed, Jul 18, 2018 at 10:59 PM Dejan Maksimovic <
    [email protected]> wrote:

    > Hi, all,
    >
    > We have a VMWare Horizon set up, regular desktop, that attaches shared
    > folders.
    > Our filter performs a query for file attributes, delete pending flag
    > and other "file infos" during IRP_MJ_CLEANUP. We have tested several cases,
    > and any call via FltPerformSyncronousIo causes extreme performance
    > slowdowns.
    >
    > Anyone have a clue how to avoid it, or found a workaround? The calls
    > have to be during CleanupPreOp :( FltPerformSynchronousIo is used instead
    > of FltQueryInformationFile, to avoid RDPDR bugcheck, since FQIF performs
    > async I/O.
    >
    > Kind regards, Dejan.
    >
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,337
    Slow performance with high or low CPU utilization?

    Have you tried "poor man's sampling" and just break in with the debugger
    periodically during the slowdown to see what the threads are doing?

    Is it an option to switch back to FltQueryInformationFile and see if the
    perf improves? It would be interesting to know.

    -scott
    OSR
    @OSRDrivers

    -scott
    OSR

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 334
    No CPU utilization whatsoever.
    The environment is extremely hard to make, so I am testing remotely. I
    would not even know how to get them to set up WinDBG for the machine :)
    This is not a VMWare Workstation/Player machine, but a desktop
    virtualization.

    Hmm, I might try that... get back to you tomorrow.


    Kind regards, Dejan.


    On Wed, Jul 25, 2018 at 6:07 PM Scott Noone <
    [email protected]> wrote:

    > Slow performance with high or low CPU utilization?
    >
    > Have you tried "poor man's sampling" and just break in with the debugger
    > periodically during the slowdown to see what the threads are doing?
    >
    > Is it an option to switch back to FltQueryInformationFile and see if the
    > perf improves? It would be interesting to know.
    >
    > -scott
    > OSR
    > @OSRDrivers
    >
    >
    >
    > ---
    > NTFSD is sponsored by OSR
    >
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer&gt;
    >
  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 334
    Changing to FltQueryInformationFile does nothing :( The slowdown is still
    present.
    The difference is extreme. Without the call, it takes 2-3 seconds max. to
    list the shares, but with the call (either sync or async) it takes
    sometimes 3-4 minutes.

    Kind regards, Dejan.


    On Wed, Jul 25, 2018 at 6:07 PM Scott Noone <
    [email protected]> wrote:

    > Slow performance with high or low CPU utilization?
    >
    > Have you tried "poor man's sampling" and just break in with the debugger
    > periodically during the slowdown to see what the threads are doing?
    >
    > Is it an option to switch back to FltQueryInformationFile and see if the
    > perf improves? It would be interesting to know.
    >
    > -scott
    > OSR
    > @OSRDrivers
    >
    >
    >
    > ---
    > NTFSD is sponsored by OSR
    >
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer&gt;
    >
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,337
    Weird. What network file system is being used? Also, are you above or below
    the VMware minifilters?

    I'd try putting ProcMon at a very low altitude and see what happens when
    your filter does the query. Comparing that to a "normal" system might be
    interesting.

    It's more cumbersome, but you can generate crash dumps from snapshots:

    http://www.vmwarearena.com/how-to-generate-crash-dump-for-vmware-virtual-machine-guest-os-hung-issues/

    In the absence of being able to actually single step this, grabbing a few
    snapshots during the long delay might be interesting. My hope would be to
    find a call stack or pattern that points to the anomalous behavior.

    -scott
    OSR
    @OSRDrivers

    -scott
    OSR

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 334
    There aren't VMware minifilters, it appears as an MUP device, when I
    connect shares via VMWare Horizon. The shares are similar (to the user,
    they are identical) to Remote Desktop shares of the host machine.

    Yes, ProcMon below and above my minifilter is the first thing tested
    always, and nothing changes for the IRP_MJ_CLEANUPs, not even the duration
    seems to change.
    If the filter is not present, or FileStandardInformation is not queried
    during IRP_MJ_CLEANUP PreOp, then the duration showed by ProcMon is in
    microseonds, whereas, when the query is done, it is in milliseconds (IIRC,
    ProcMon shows the duration in seconds, i.e. 1.0 is 1 second, right? So our
    0.001-0.004 duration is 1-4 milliseconds)
    It is not a hang, again, just a major delay, compared to regular processing.

    Kind regards, Dejan.


    On Fri, Jul 27, 2018 at 10:40 PM Scott Noone <
    [email protected]> wrote:

    > Weird. What network file system is being used? Also, are you above or
    > below
    > the VMware minifilters?
    >
    > I'd try putting ProcMon at a very low altitude and see what happens when
    > your filter does the query. Comparing that to a "normal" system might be
    > interesting.
    >
    > It's more cumbersome, but you can generate crash dumps from snapshots:
    >
    >
    > http://www.vmwarearena.com/how-to-generate-crash-dump-for-vmware-virtual-machine-guest-os-hung-issues/
    >
    > In the absence of being able to actually single step this, grabbing a few
    > snapshots during the long delay might be interesting. My hope would be to
    > find a call stack or pattern that points to the anomalous behavior.
    >
    > -scott
    > OSR
    > @OSRDrivers
    >
    >
    > ---
    > NTFSD is sponsored by OSR
    >
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer&gt;
    >
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!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA