The Depths of Windows I/O (Part 6, Final) — Filter Drivers and Minifilters: Why Procmon and Antivirus Scanners Can Intercept I/O

This is the final instalment of the series “The Depths of Windows I/O”.

Ever since Part 1 drew a box labelled “file system filters (antivirus, encryption, Procmon, and the like)” on the device stack diagram, the ones that sit in between have kept turning up throughout this series: why Procmon can record every I/O operation (Part 1); “file access is slow only in that one environment” (Part 2); the reparse point that makes OneDrive start downloading the instant a file is opened (Part 5). This instalment finally faces that interposing mechanism itself head-on — file system filter drivers and minifilters — and ties off every thread the series has left dangling.

1. The Bottom Line First

• “Intercepting I/O” is an extension point the OS officially sanctions. A file system filter can see, rewrite, deny, or handle in its place a request made to the file system (Section 2).¹
• The current standard is the minifilter. To solve the problems of the legacy approach that intercepted the device stack directly (unpredictable ordering, no way to unload), the model changed generations to one that registers callbacks with the Filter Manager (FltMgr) that ships with Windows (Section 2).²³
• The mechanics are pre/post callbacks. Before and after each operation, filters are called in registration order — that is, altitude order. Pass through, complete, deny, rewrite — the “choices a driver has” from Part 1 apply directly (Section 3).²
• Altitude decides the order. Each purpose-specific group is assigned a numeric band (Activity Monitor 360000-389999, Anti-Virus 320000-329999, and so on), and each instance attached to a volume gets a unique number within it (Section 4).⁴⁵
• You can see who lives on your PC with fltmc. Procmon (only while it is running), antivirus software, OneDrive’s cloud filter — they all line up here (Section 5).
• An antivirus exclusion setting means “skip that product’s own scan” — it has no effect on other minifilters. Exclusions trade away protection, and for development volumes there is a safer option: Dev Drive (asynchronous scanning) (Section 6).⁶⁷
• Investigating “why is only this one environment slow” starts with Procmon’s Duration column and comparing fltmc configurations (Section 7).

2. A History of Those Who Interpose — From Legacy Filters to FltMgr

A file system filter driver is a driver that can intercept requests bound for the file system (or the volume beneath it). It can log a request, monitor it, alter its contents, and even deny it or handle it in the request’s place — it is the foundation on which antivirus software, encryption, backup, and hierarchical storage software are built.¹

The old implementation approach (the legacy filter) stacked its own device object directly onto the device stack we saw in Part 1. The mechanism is straightforward, but in practice it was riddled with problems: the order in which filters stacked up depended on load order and was hard to guarantee, once stacked a filter could not safely get out again (it could not be unloaded), and it became a breeding ground for compatibility bugs between filters.

So Windows introduced the Filter Manager (FltMgr). FltMgr itself sits on the stack as an OS-supplied filter, and individual filter functionality registers callbacks with FltMgr as a minifilter.²

flowchart TB
    subgraph OLD["Legacy approach"]
        L1["Legacy filter A"]
        L2["Legacy filter B"]
        LFS1["File system"]
        L1 --> L2
        L2 --> LFS1
        NOTE1["Order is left to load order<br/>cannot be unloaded safely"]
    end
    subgraph NEW["Minifilter approach - the current standard"]
        FM["Filter Manager - FltMgr<br/>ships with the OS, the only thing that sits on the stack"]
        M1["Minifilter A - higher altitude"]
        M2["Minifilter B - lower altitude"]
        LFS2["File system"]
        FM -. "registers callback" .- M1
        FM -. "registers callback" .- M2
        FM --> LFS2
        NOTE2["Order is deterministic via altitude<br/>can load at any time<br/>a supporting filter can also unload"]
    end

Figure 1: A change of generation — from “stacking” onto the stack to “registering” with FltMgr

The advantages of the minifilter model are officially enumerated — it can load at any time, ordering can be controlled, and a filter that implements an unload callback can even be unloaded while running (a filter that does not implement one, or that refuses, cannot be removed).³ To coexist with legacy filters, FltMgr can sit at multiple points on the stack as several “frames”, and a minifilter is guaranteed to return to the same position (the same altitude) even after being unloaded and reloaded.² Practically all modern antivirus, monitoring, and sync software is built as this kind of minifilter.

3. How a Minifilter Behaves — Pre/Post Callbacks

A minifilter declares to FltMgr “which operations it is interested in”. For example, it might be interested only in IRP_MJ_CREATE (open) and IRP_MJ_WRITE (write). Then, every time such an operation flows through, its pre callback (before the operation) and post callback (after the operation) are invoked.

sequenceDiagram
    participant IOM as I/O Manager
    participant FM as FltMgr
    participant A as Minifilter A<br/>higher altitude
    participant B as Minifilter B<br/>lower altitude
    participant FS as NTFS

    IOM->>FM: Request - IRP_MJ_CREATE and the like, the world of Part 1
    FM->>A: pre callback
    FM->>B: pre callback
    FM->>FS: To the file system
    FS-->>FM: Result
    FM-->>B: post callback
    FM-->>A: post callback
    FM-->>IOM: Completion - back into the completion flow from Part 1

Figure 2: Pre/post callbacks. The outbound leg is called in order from highest altitude to lowest, and the return leg in reverse order

What can each callback do? The same structure as “the three choices a driver has” from Part 1, Section 4.3, is offered here through a safer API.

flowchart TB
    PRE["The pre callback is invoked"]
    Q{"What to do with this operation"}
    PASS["Pass it straight through<br/>also declare no post callback needed, if so"]
    DENY["Deny it<br/>return access denied or similar immediately<br/>e.g. - virus detected, write blocked"]
    DONE["Complete it itself<br/>e.g. - a cloud filter fetches<br/>the real content and hands it over"]
    MOD["Modify parameters or content, then pass it on<br/>e.g. - an encryption filter"]
    PRE --> Q
    Q --> PASS
    Q --> DENY
    Q --> DONE
    Q --> MOD

Figure 3: The choices available to a pre callback. “Observe, stop, take over, or rewrite” are all officially supported

And here is where the homework from Part 4 gets collected: minifilters can also witness Fast I/O (the shortcut that skips creating an IRP). That is because FltMgr threads its callback mechanism through the Fast I/O path too, so there is none of the legacy-era problem of “being blind whenever the shortcut is taken”. The fact that Procmon’s log even lists FASTIO_ lines is entirely down to this vantage point.

4. Altitude — “Elevation” Decides the Order

When several filters are interested in the same operation, who sees it first is a serious question. If antivirus doesn’t see it before encryption, it ends up scanning ciphertext; if a monitoring tool isn’t above everyone else, it cannot observe the whole picture.

Altitude is what decides this order. A load order group and a numeric band are defined for each type of filter. To be precise, the unit that carries an altitude is not the driver as a whole but the “instance” of a minifilter attached to a volume. Numbers are unique, and the larger the number, the higher up the stack (closer to the application) it sits.⁴ A single driver can define multiple instances and appear at different altitudes, which is why the fltmc instances listing is per instance.

flowchart TB
    APP["Closer to applications - larger numbers"]
    G1["FSFilter Activity Monitor - 360000 to 389999<br/>observes and records I/O, Procmon lives here"]
    G2["FSFilter Undelete - 340000 to 349999<br/>recovering deleted files"]
    G3["FSFilter Anti-Virus - 320000 to 329999<br/>detecting and removing viruses"]
    G4["FSFilter Replication - 300000 to 309999<br/>replicating to a remote location"]
    G5["FSFilter Continuous Backup - 280000 to 289999<br/>continuous backup"]
    G6["Further down - Content Screener,<br/>Quota Management, System Recovery,<br/>encryption and compression bands continue"]
    FS["Closer to the file system - smaller numbers"]
    APP --> G1 --> G2 --> G3 --> G4 --> G5 --> G6 --> FS

Figure 4: Altitude bands - excerpt. Each purpose has a defined “elevation it should occupy”

The important point is that these numbers are allocated and managed by Microsoft.⁵ A vendor does not simply claim one; it applies and is granted one — which is why “monitoring sits above antivirus, and antivirus sits above encryption” holds as an order on every PC. This was the answer to the legacy era’s “load-order lottery.”

Where to apply if you’re building your own minifilter. For developers, here is just the next step to take. You request an altitude by following the procedure in Request a Filter Altitude Identifier: send an English-language email to fsfcomm@microsoft.com with the subject “Filter altitude request”. You need to fill in the company name; a contact (not a personal address but a company alias usable long-term); the product name; the product URL; a description of the filter; the driver’s file name; the filter type; the start type; and your desired load order group and desired altitude. It is also explicitly stated that you should plan for 30 business days of processing, that there is no expedited channel, and that the altitude you are assigned may differ from what you requested.⁸ Note also that a company that already holds an integer altitude within the same load order group may choose its own value by appending a decimal to that number (for example, 325000.3), and in that case a follow-up email after the fact is all that’s required.⁸

5. Meet the Residents — Your PC as Seen Through fltmc

Enough theory — let’s look at the real thing. From an elevated command prompt:

:: List of registered minifilters, with altitudes
fltmc

:: Which filters are attached to which volumes
fltmc instances

:: View it from the volume side
fltmc volumes

Running fltmc with no arguments produces the same listing as fltmc filters. The output has four columns, and Microsoft’s documentation shows an example in the same format.⁹

C:\Windows\system32>fltmc

Filter Name                     Num Instances    Altitude    Frame
------------------------------  -------------  ------------  -----
bindflt                                 1        409800         0
cldflt                                  1        409500         0
WdFilter                                4        328010         0
luafv                                   1        135000         0
FileInfo                                4         45000         0

The above is an illustrative excerpt. The cast of names and instance counts differ by environment, but because the altitude values are fixed numbers assigned by Microsoft, you can cross-check them against the published list mentioned in Section 4.

Here is what each column means.

Even from just these five lines you can read off that bindflt and cldflt sit in the topmost FSFilter Top band (400000-409999), WdFilter sits in the Anti-Virus band (320000-329999), and FileInfo sits in the lowest FSFilter Bottom band (40000-49999). The picture from Section 4 — “each purpose has a defined elevation it should occupy” — is confirmed directly by the numbers. And if you start Procmon and run fltmc again, one more line appears in the Activity Monitor band (360000-389999), starting with PROCMON.

The cast varies by environment, but the typical residents are all familiar faces from this series.

• WdFilter — Microsoft Defender’s minifilter. It sits in the Anti-Virus band. On many PCs it is a checkpoint that every single file I/O operation must pass through.
• cldflt — the cloud files filter. It is the workhorse behind OneDrive’s Files On-Demand, and it prepares the real content when the reparse point (placeholder) we saw in Part 5 is opened.¹⁰
• PROCMON24 (or similar) — a temporary minifilter in the Activity Monitor band that appears only while Process Monitor is running. This is the trick behind how Procmon can see every I/O operation.¹¹ Try running fltmc before and after starting it and compare.
• Beyond that, there are backup software, encryption (data-loss-prevention) products, EDR, virtualised storage, and more — the more business-oriented the PC, the more residents it accumulates.

Looking back, in this final instalment, at Procmon — the tool we have used since Part 1 — from outside the toolbox, we find a neat closed loop: the observer, too, turns out to be a resident of the very mechanism it observes.

6. Where Does Antivirus Software Spend Its Time?

The single biggest practical impact of filters is the cost of antivirus scanning. Here is a diagram of where the time is actually spent (details vary by product; what follows is a typical shape).

sequenceDiagram
    participant App as Application
    participant AV as AV minifilter
    participant FS as NTFS

    App->>AV: Open a file
    Note over AV: pre-create - evaluating the path and policy up front
    AV->>FS: Pass it through - performs the open
    FS-->>AV: Open succeeds - post-create
    Note over AV: If the file hasn't been scanned yet,<br/>scan its contents here<br/>and revoke the open if there's a problem<br/>this is the main reason opens get slow
    AV-->>App: If there's no problem, the handle is returned
    App->>AV: Write and close
    Note over AV: A modified file becomes<br/>a rescan target, e.g. on close
    Note over App,FS: With a large number of small files, such as build intermediates,<br/>this round trip piles up once per file

Figure 5: Where scanning cost is incurred. Small per file, it dominates once you have tens of thousands of files

With this in mind, two practical topics can be understood precisely.

What an exclusion setting technically does. For I/O on a path matching the exclusion list, the filter’s scanning is skipped. The filter does not vanish from the stack — what actually happens is that the decision “don’t inspect this” gets made earlier. There is one more important limitation: an exclusion only works for the filter belonging to the product that holds that setting. Microsoft Defender’s exclusion setting changes WdFilter’s scanning, and has no effect whatsoever on the behaviour of any other minifilter sitting alongside it (a competing antivirus product, EDR, backup, encryption, and so on). If “I added an exclusion and it’s still slow”, suspect that a different resident is spending the time (compare with fltmc in Section 7). The effect is large, but an exclusion reliably weakens protection at that location. Microsoft’s own documentation repeatedly warns that, because exclusions reduce defences, they should be kept to a minimum after weighing the risk.⁶ The practical handling of false positives and their performance impact is covered in “When Your In-House Windows App Gets Flagged as a Virus”.

Dev Drive — a new answer. This is a dedicated volume designed for development workloads (lots of small files), on which Microsoft Defender runs in performance mode (asynchronous scanning). It is positioned as a safer alternative to folder exclusions: by default no additional filters get attached, while at the same time a strong warning is spelled out against running with every filter removed.⁷ It is Microsoft’s current recommended answer to “I want builds to be faster, but exclusions scare me.”

7. The Investigation Procedure for “Only This One Environment Is Slow”

As a final step, let’s fold every tool this series has built up into a single procedure.

flowchart TB
    S["Symptom - the same app, but file access is slow only in one particular environment"]
    P1["Look at Procmon's Duration column<br/>which operation - IRP_MJ_CREATE? WRITE?<br/>is where the time goes"]
    Q1{"Is one specific operation uniformly slow?"}
    F1["Compare fltmc instances against a fast environment<br/>look at the difference in filter configuration"]
    Q2{"Is a filter in the difference the cause?"}
    A1["An exclusion setting - with a risk assessment - or<br/>considering Dev Drive, or talking to the vendor"]
    A2["Suspect something other than a filter -<br/>the cache Part 4, fragmentation or the MFT Part 5,<br/>the network destination UNC, or the device itself"]
    S --> P1 --> Q1
    Q1 -->|"Yes"| F1 --> Q2
    Q2 -->|"Yes"| A1
    Q2 -->|"No"| A2
    Q1 -->|"No - sporadic"| A2

Figure 6: Isolating filter-caused slowness. The keys are “time taken per operation” and “the difference in filter configuration between environments”

There are two key points. First, Procmon carries a per-operation duration (Duration). If you can break “it’s slow” down into “which operation is slow”, the manhunt is half done. Second, differences between environments are often differences in filter configuration. A development machine versus a production machine, your own PC versus a customer’s PC — simply lining up fltmc output side by side reveals which candidates deserve suspicion.

The first three moves if you’ve never touched Procmon. The Duration column is not shown by default, so here — to keep you from getting stuck at this step — are just the operations needed.

1. Launch Procmon.exe as an administrator.
2. Open Options menu > Select Columns… and check Duration in the list of columns.
3. In Filter menu > Filter… (Ctrl+L), enter Process Name / is / the target exe name / Include, then click Add before clicking OK (the condition is not applied unless you click Add).

With that done, click the Duration column to sort it, and the operations eating the most time collect at the top. For a per-process or per-file summary, you can also use Tools menu > File Summary. General Procmon operation is covered in full in “A Practical Guide to Process Monitor (ProcMon)”.

8. The Series, Brought Together — A Map of Six Instalments

With that, every box on the map drawn in Part 1 has been opened. Let’s put the whole thing on one diagram.

flowchart TB
    APP["Application<br/>ReadFile / WriteFile / async-await"]
    API["Part 2 - Synchronous and asynchronous I/O<br/>handle modes and OVERLAPPED"]
    IOCP["Part 3 - IOCP and the .NET thread pool<br/>receiving completions and running continuations"]
    IOM["Part 1 - I/O Manager and the IRP<br/>name resolution, three objects, the device stack"]
    FLT["Part 6 - Filters and minifilters<br/>FltMgr, altitude, pre/post"]
    CACHE["Part 4 - The Cache Manager<br/>256KB views, the lazy writer, Fast I/O<br/>works in cooperation with NTFS"]
    NTFS["Part 5 - NTFS<br/>the MFT, streams, links, two journals"]
    HW["The storage stack and the device"]
    APP --> API
    API --> IOM
    IOCP -. "completion returns here" .-> APP
    IOM --> FLT
    FLT --> NTFS
    NTFS -. "Cache-enabled I/O cooperates<br/>the file system calls into the cache" .- CACHE
    NTFS --> HW
    HW -. "interrupt to completion, Part 1" .-> IOCP

Figure 7: A map of the whole series. The Cache Manager is not a “layer things pass through” but a partner that cooperates with the file system; on a cache miss, NTFS issues the request on to storage

• Part 1: The Big Picture — every read and write becomes an IRP
• Part 2: Synchronous / Asynchronous — the real meaning of OVERLAPPED
• Part 3: IOCP — the basement beneath async/await
• Part 4: The Cache — when does your WriteFile actually reach the disk
• Part 5: NTFS — understanding the file system through the MFT
• Part 6: Filters and Minifilters (this article) — why Procmon and antivirus scanning can intercept I/O

9. Summary — Closing Out the Series

Here is the summary for this final instalment.

• Intercepting I/O is an extension point the OS officially sanctions, and the current standard is registering callbacks with FltMgr, i.e. a minifilter. Order is decided deterministically by altitude, and Microsoft allocates and manages the numbers.²⁴⁵
• The mechanics are pre/post callbacks. You can pass through, deny, take over, or rewrite, and you can witness Fast I/O too. Procmon, Defender, and OneDrive are all residents of this same mechanism.¹¹¹¹⁰
• An exclusion setting equals skipping the scan, and it trades away protection. For development volumes there is a safer option: Dev Drive (asynchronous scanning).⁶⁷
• “Only this one environment is slow” gets isolated using Procmon’s Duration and the configuration difference reported by fltmc — the series’ tools become the investigation procedure itself, unchanged.

And if the whole series has to be summed up in a single line, it is this — Windows I/O is a consistent design in which the destination is decided in a namespace, the request is packed into a packet, the IRP, and flowed between layers, and each layer is built so it can choose to see it, hold it, or take it over. Underneath a single line of File.ReadAllText, this six-part structure runs every single time. Instead of memorising how an API behaves, being able to derive “it must work this way” from this map — that is the capability this series wanted to leave you with. Thank you for staying with this long journey.

Related Articles

• The Depths of Windows I/O (Part 1) — Every Read and Write Becomes an IRP: The Big Picture of the I/O System
• The Depths of Windows I/O (Part 4) — Cache Manager: When Does Your WriteFile Actually Reach the Disk?
• The Depths of Windows I/O (Part 5) — NTFS Internals: Understanding the File System Through the MFT
• A Practical Guide to Process Monitor (ProcMon) — Pinpointing “Settings Not Applied” and “ACCESS DENIED” in 10 Minutes
• When Your In-House Windows App Gets Flagged as a Virus — Handling Microsoft Defender False Positives and Living With the Performance Impact
• Process Explorer / Handle / VMMap in Practice — Chasing Hangs, Leaks, and “File in Use” from the State Right Now
• A Minimum Security Checklist for Windows App Development

Related Consulting Areas

KomuraSoft LLC handles investigations into performance problems and defects in Windows business applications that involve filter drivers — cases such as “it’s slow only in one particular environment” or “security software interferes with our own application.”

• Windows Application Development
• Bug Investigation and Root Cause Analysis
• Technical Consulting & Design Review
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

What's the difference between a file system filter driver and a minifilter?

Both are "drivers that intercept I/O requests to the file system", but they differ in which generation of interception method they use. The older legacy filter approach stacked its own device object directly onto the file system's device stack, which meant position was decided by load order and hard to guarantee, and there were problems such as not being able to unload safely once loaded. The current standard, the minifilter, registers callbacks with the Filter Manager (FltMgr) that ships with Windows, saying in effect "please call me before and after this operation". Position is decided deterministically by a number called the altitude, it can be loaded at any time, and a filter that implements an unload callback can even be removed while running. Nearly all modern filters — antivirus, encryption, monitoring tools, cloud sync — are implemented as minifilters.

Why can antivirus software inspect every file access?

Because the OS officially provides an extension point for exactly this purpose. A minifilter can register code with the Filter Manager to be called before (the pre callback) and after (the post callback) operations such as opening, reading, or writing a file. An antivirus filter sits in the altitude band reserved for anti-virus (320000-329999), and can, for example, scan the contents immediately after a file open succeeds (post-create) and, if there's a problem, revoke that open so the access fails. As we saw in Part 1 of this series, every file I/O operation flows down the device stack, so the logic is that standing at a fixed position along that path lets you inspect every access. It isn't a hack — it's a mechanism built into the design of the OS.

What does an antivirus exclusion setting (folder exclusion) actually do, technically?

For I/O on a path matching the exclusion list, it makes that product's filter skip the scanning it would otherwise perform. The filter itself does not disappear from the stack; the closer-to-accurate understanding is that the decision "don't inspect this path" gets made earlier. An important limitation is that an exclusion only works for the product that holds that setting. For example, a Microsoft Defender exclusion setting changes the scanning done by Defender's filter (WdFilter), and has no effect on the behaviour of other minifilters that sit alongside it — a competing antivirus product, EDR, backup software, and so on. Each product needs its own exclusion setting, and when "it's still slow even after I added an exclusion", a different filter can be the cause. And as Microsoft's documentation repeatedly warns, an exclusion weakens protection at that location, so it should be kept to a minimum together with a risk assessment. For development use, it is also worth considering Dev Drive (performance mode, i.e. asynchronous scanning), which is designed as a safe alternative to folder exclusions.

How does Process Monitor record every single I/O operation?

Because Procmon itself registers itself with the Filter Manager at startup, as a minifilter in the altitude band for Activity Monitor. If you run fltmc from an elevated command prompt while Procmon is running, you can confirm that a filter with a name starting PROCMON appears in the listing. Because it is present at the pre and post stages of I/O operations on every volume as a minifilter, it can record, without omission, which process performed which operation on which file. The reason the IRP and Fast I/O terminology we've followed throughout this series shows up directly in Procmon's display is precisely because it is observing from a position standing right on the path I/O itself takes.

When a development machine's builds are slow, should I suspect filter drivers?

It's well worth suspecting. A build is a mass of creating, reading, writing, and deleting a huge number of small files, and each one of those becomes a target for inspection by the filters (especially antivirus scanning), which makes it the workload where filter cost is most likely to surface. The basic investigation procedure is to check Procmon's Duration column to see which operation the time is going into, and to compare the difference in filter configuration between environments with fltmc instances. As countermeasures, alongside an exclusion setting adopted after assessing the risk, there's also using Dev Drive, which is designed specifically for development volumes. On a Dev Drive, antivirus runs in performance mode (asynchronous scanning), and Microsoft positions this as a safer alternative to an exclusion setting.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.