The Depths of Windows I/O (Part 6, Final) — How Minifilters Work and Investigating Slow I/O with Procmon
· Updated: · Go Komura · Windows, Win32, I/O, Minifilter, Kernel, Device Driver, Security, Bug Investigation
Revision history (first version, published Jul 29, 2026)
- First published
Cite this article(DOI (registered archive): 10.5281/zenodo.22170821)
The DOIs below refer to previously archived versions and may not match the current text. Use this page’s URL to reference the current text.
Go Komura (2026). The Depths of Windows I/O (Part 6, Final) — How Minifilters Work and Investigating Slow I/O with Procmon. KomuraSoft LLC. https://comcomponent.com/en/blog/windows-minifilter-filter-drivers/
- DOI (registered archive)
- 10.5281/zenodo.22170821
- DOI (last registered version)
- 10.5281/zenodo.22170822
On one particular PC, simply opening a file takes a long time. On machines that have antivirus software installed, builds and bulk file copies slow down. Meanwhile, when you start Process Monitor, you can see a record of file operations even though you never changed your own application.
The key to understanding both is the file system filter driver, which monitors and controls file I/O while it is in flight. Windows provides an extension point for exactly that.1
In this final part of the series “The Depths of Windows I/O”, we take up the minifilter, the standard implementation model today. The first half covers how it works, and the second half connects that to a procedure for using fltmc and Procmon to find out which environment and which operation are slow. Even for application developers who never write a driver, it should serve as a map for isolating performance problems.
1. The Bottom Line First
A minifilter is a driver that registers with the Filter Manager (FltMgr) shipped with Windows, telling it which operations it handles and at which stage. FltMgr calls the callbacks according to that registration and according to a relative position called the altitude. From the application’s point of view the file operation is the same, but the work done by the filters along the way can affect both the result and how long it takes.2
That said, “a filter is present” and “that filter is the cause of the slowness” are two different statements. fltmc is a tool for checking the configuration, and Procmon is a tool for observing operations. Neither is a tool for settling a cause from a listing or a single number.
This article is organized around the following distinctions.
| What you want to check | Where to look | What it alone does not tell you |
|---|---|---|
| Which filters are loaded | fltmc filters |
Whether that filter handled the operation in question |
| What is attached to the volume in question | fltmc instances |
How much time each filter spent |
| Which file operations take time | Procmon events and the Duration column | The component that produced all of the delay |
| What Defender’s scanning spends time on | The Microsoft Defender performance analyzer | Performance problems in other products or in the application as a whole |
In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (34 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle
2. A History of Those in the Middle — From Legacy Filters to FltMgr
A file system filter driver monitors and controls requests headed for a file system or for another filter. It is used for antivirus, encryption, backup and similar purposes, and it can do more than record requests: it can also modify parameters or deny access. “Intercepting” here does not mean a CPU hardware interrupt. It means sitting in the middle of the I/O path.1
In the legacy model, the filter itself attaches its own device object to the device stack, passes requests down, and handles completion. Attachment order, safe removal, and coexistence with other filters are all left to the implementation, so this model puts a wide range of concerns on the driver.
In the minifilter model, by contrast, FltMgr takes on the shared work such as attaching to the stack, and each driver registers callbacks only for the operations it needs. A minifilter is still a kernel-mode driver, and the driver object does not go away. What changes is the mechanism for taking part in the file system stack.3
flowchart TB
accTitle: The legacy model and the minifilter model
accDescr: A diagram comparing the legacy model, in which the filter attaches itself to the stack, with the minifilter model, in which callbacks are registered with FltMgr.
ROOT["How to take part in file I/O"]
ROOT -->|"Legacy model"| LEG["The filter attaches itself"]
ROOT -->|"Minifilter model"| MINI["Register callbacks with FltMgr"]
LEG --> OWN["Implement attachment and completion"]
MINI --> SHARED["FltMgr handles the shared work"]
Figure 1: A comparison of the model in which the filter attaches itself to the stack and the model in which callbacks are registered with FltMgr.
The diagram shows the arrangement in which FltMgr attaches to the stack on behalf of the minifilters. In practice, in order to coexist with legacy filters, FltMgr may attach at different positions as multiple frames. Coexistence comes with placement constraints, so moving to minifilters does not by itself resolve every compatibility problem.2
FltMgr reduces the instability of position that comes from load order, and it also supports unloading while the system is running. What can actually be detached, though, is a driver that implements the corresponding callback and allows itself to be unloaded. That is no guarantee that you may remove any filter you like in the middle of an investigation.3
3. How a Minifilter Behaves — Pre- and Post-Operation Callbacks
A minifilter registers the operations it wants to handle: for example the open and create operations that correspond to IRP_MJ_CREATE, or the write operations that correspond to IRP_MJ_WRITE. The pre-operation callback runs before the request is passed down, and the post-operation callback runs at the point where the result comes back from below. A filter can register both, or only the side it needs.2
The next diagram shows the case where A and B both handle the same operation, pass the request down in their pre-operation callbacks, and ask to be called back in post-operation.
sequenceDiagram
accTitle: Callback order when the request is passed down and completion comes back
accDescr: When both A and B register for the target operation, pass it down and ask for a post-operation callback, the pre callbacks run from the higher altitude downward and the post callbacks run in the reverse order.
participant FM as FltMgr
participant A as Filter A (high)
participant B as Filter B (low)
participant FS as File system
FM->>A: pre
FM->>B: pre
FM->>FS: pass down the stack
FS-->>FM: result
FM-->>B: post
FM-->>A: post
Figure 2: In a normal round trip, the pre callbacks run from the higher altitude to the lower and the post callbacks run in the reverse order. Not every request produces this round trip.
The return value of the pre-operation callback decides what happens next. The main ones can be summarized as follows.45
| Pre-operation return value | Meaning |
|---|---|
FLT_PREOP_SUCCESS_NO_CALLBACK |
Go down the stack, and do not ask for this filter’s post callback |
FLT_PREOP_SUCCESS_WITH_CALLBACK |
Go down the stack, and ask for this filter’s post callback on completion |
FLT_PREOP_COMPLETE |
Complete the operation with the result this filter specifies. Denying access is one example |
FLT_PREOP_PENDING |
Pend the corresponding IRP-based operation and resume or complete it later |
If a filter completes a request in its pre-operation callback, the request does not travel on to the filters below it or to the file system. The post-operation callback of the filter that returned FLT_PREOP_COMPLETE is not called either, and completion goes back to the filters above that already received the request and asked for a post callback. So it is important not to assume that “both pre and post are always called because I registered for them”.4
Pending, in turn, is not simply extra waiting time. A driver that pends a request takes on the responsibility of resuming or completing it properly. An implementation also has to deal with constraints such as the operation type, IRQL, buffer lifetime and cancellation. The table in this article is an outline of the processing, not an implementation procedure you can follow as it stands.5
3.1 Fast I/O Is Covered Too, but That Does Not Mean “All I/O Is Visible”
What FltMgr handles is not only IRP-based I/O. It also covers fast I/O and file system filter (FSFilter) callback operations. The idea that “this path does not use IRPs, so a minifilter cannot see it” is wrong. The opposite idea, that every access necessarily becomes an IRP and goes through the same sequence of callbacks, is not accurate either.2
What can be observed varies with the volumes the filter is attached to, the operations it registered for, the exclusion conditions given at registration time, and whether a filter above completes the request. Nor is every individual memory access to a memory-mapped file recorded as one file I/O event each time. Legacy filters also have a mechanism for handling fast I/O, so support for fast I/O is not in itself a minifilter-only feature.36
4. Altitude — The “Elevation” That Decides the Order
When several filters take part in the same operation, the order in which they run has to be decided. What specifies that relative position is the altitude. The larger the number, the further the filter sits from the file system, and the smaller the number, the closer. It is not a thread priority, and it is not a number expressing a product’s performance or importance.7
The setting is written in the driver’s instance definition, and what is actually attached to a given volume becomes an instance. Because the same definition applies to several volumes, a separate altitude is not issued per volume. A single driver can carry more than one definition, but being assigned multiple altitudes is not a common way to use the mechanism.7
The load order groups by purpose and their number ranges are defined as follows.
flowchart TB
accTitle: Minifilter altitude bands by purpose
accDescr: The higher the number, the further the relative position from the file system. The diagram is an excerpt of some of the groups and does not cover everything from the top to the bottom.
TOP["Larger numbers"] --> M["Activity Monitor 360000-389999"]
M --> U["Undelete 340000-349999"]
U --> AV["Anti-Virus 320000-329999"]
AV --> R["Replication 300000-309999"]
R --> B["Continuous Backup 280000-289999"]
B --> LOW["On down to further groups by purpose"]
Figure 3: An excerpt of the altitude bands by purpose. There are bands above Activity Monitor as well, so a monitoring filter is not always at the very top of the whole stack.
You request your first altitude from Microsoft. If you have already been assigned an integer value in the same load order group, there is also a mechanism for building an altitude by adding a decimal part to that value and notifying Microsoft. That does not mean a developer without an existing integer value is free to use any number they like.7
During development, follow Request a Filter Altitude Identifier and send an ASCII text email to fsfcomm@microsoft.com with the subject Filter altitude request. You fill in the company name, a company contact that will remain valid long term, the product name and URL, a description, the driver file name, the filter type, the start type, and the group and number you would like. The official guidance says to allow 30 business days for processing, and you will not necessarily get the number you asked for. This is something to settle at the planning stage of development and distribution.8
5. Meet the Residents — Your PC Seen Through fltmc
Once the mechanism is clear, check the actual configuration. Open a command prompt as an administrator and run the following read-only commands.910
:: List the file system filters that are loaded
fltmc filters
:: How filters and volumes are attached
fltmc instances
:: List the volumes
fltmc volumes
fltmc filters produces the same listing as fltmc with no arguments. What follows is an illustrative example showing how to read the columns, not a measurement taken on a real machine for this article. The altitudes are published allocated values, while the set of rows and the instance counts are there for illustration.11
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
| Column | How to read it |
|---|---|
| Filter Name | The name of the filter. It does not necessarily match the product name |
| Num Instances | The number of attached instances. It does not always match the number of distinct volumes |
| Altitude | The position relative to other filters. Check the details per instance as well |
| Frame | The FltMgr frame number. <Legacy> indicates a legacy filter |
Check separately that a name appears in filters and that the filter is attached to the volume holding the file in question. The point is to go as far as instances when comparing configurations. Even after confirming what it is attached to, you still do not know which callbacks it registered for that operation or what it actually did.10
5.1 Filters You Often See
WdFilter is Microsoft Defender’s filter, allocated 328010 in the Anti-Virus band. cldflt is the cloud files filter behind the Cloud Files API, and it is allocated 409500. With OneDrive Files On-Demand, a local placeholder and the sync provider work together to fetch the data that is needed. That does not mean the whole file is downloaded every time it is opened.1112
Procmon’s file system monitoring also uses a minifilter. If you compare fltmc filters before and after starting it, on some machines you can see a driver whose name begins with PROCMON. Do not assume that the trailing number or the load and unload timing is fixed. Check the state on the machine in front of you.
That said, not all of Procmon’s monitoring, including its registry and process and thread monitoring, is implemented with a file system minifilter. And one line in Procmon does not mean one physical disk access. Observing file operations and observing what the storage device does are two different layers.13
6. Where Does Antivirus Spend Its Time?
If a product is configured to wait for a scan result in the middle of a file operation, that wait is part of the time the application takes to finish the operation. In a build that creates and updates a large number of small files, the individual checks can add up. But it is not a given that the whole file is read again on every access, and the conditions and timing of a scan differ by product and by configuration.14
The next diagram is a conceptual view of the case where the inspection after an open happens before the result is returned to the application. It does not depict any specific product’s internals, nor does it guarantee the processing order for every file.
sequenceDiagram
accTitle: An example configuration that waits for the scan result before completing the open
accDescr: It illustrates a product configuration that inspects in post-create. It is not a diagram of how every product is implemented, and it does not mean a scan happens every time.
participant APP as App
participant AV as AV minifilter
participant FS as File system
APP->>AV: open a file
AV->>FS: check the conditions and pass it down
FS-->>AV: open succeeds
Note over AV: In this example, post-create waits for the inspection result
alt Allowed by the inspection
AV-->>APP: success result
else Denial required
Note over AV: Cancel the open within the documented constraints
Note over AV: Changes from creation or overwrite are not rolled back
AV-->>APP: failure result
end
Figure 4: An example configuration that waits for the inspection result in post-create. The actual conditions and timing of the inspection differ by product, and this alone cannot identify the cause of a delay.
Technically, there is a mechanism for calling FltCancelFileOpen in the post-operation callback of a successful create and setting a failure status so that the open is treated as having failed. But this is not a feature that rolls back changes to the file. It does not delete a newly created file or restore the contents from before an overwrite, and the call has constraints such as having to happen before a handle is created.15
6.1 An Exclusion Setting Is Not “Removing the Filter”
An exclusion setting reduces what is scanned by the scanning that setting applies to. It is not a setting that detaches the filter itself from the stack, and it is not a setting that takes effect across another vendor’s EDR, backup or encryption filters. Even within the same product family, an antivirus exclusion and an exclusion for another protection feature must not be treated as the same thing.14
So when it is still slow after an exclusion, the answer is not necessarily “the setting is broken”. There is room to check what the setting applies to, the management policy, another filter, the file system, the network, and waits on the application side. Conversely, even when an exclusion makes things faster, that result alone does not let you say there are no factors other than scanning.
Do not make a broad exclusion, or turning a protection feature off, the first step of an investigation. Record the logs and the reproduction conditions first, and if a change is needed, confirm the risk with the administrator and then decide its scope, its duration, and how to undo it. Dealing with false positives is also covered in “When Your In-House Windows App Gets Flagged as a Virus”.14
6.2 Dev Drive Is a Conditional Option for Limiting the Impact of Scanning
For a place to hold development files, Dev Drive is also worth considering. Microsoft Defender’s performance mode scans the file opens it covers asynchronously, keeping protection in place while limiting the impact on performance. Microsoft positions it as a safer alternative to folder exclusions for development use.1617
It has prerequisites, though: the volume must be a trusted Dev Drive, Defender must be running as the primary antivirus, real-time protection must be enabled, and so on. Pointing it at an ordinary NTFS folder does not produce the same behavior, and not every antivirus product switches to asynchronous scanning. On a Dev Drive, also review the filter attach policy and confirm compatibility with the security and backup products you need.1716
7. Investigating “Only That Environment Is Slow”
Work through the investigation in this order: identify the slow operation, compare the configuration of the volume in question, then confirm the candidates with additional measurements. Neither “slow every time” nor “slow only the first time or only occasionally” is a reason to drop filters from the list of candidates.
7.1 First, Line Up the Reproduction Conditions
Before comparing anything, record the application version, what the operation does, the input files, the destination, the user it runs as, and the versions of the OS and the security products. Avoid comparisons that mix local files with UNC paths, or that mix cloud files not yet fetched with files already present locally.
Separate the first run from later runs as well. If the state of the cache, the progress of synchronization, or the presence of other work differs, the same operation can take a different amount of time. Reproduce it several times, and line up the application’s overall elapsed time with the window in which the trace was captured.
7.2 Finding Slow Operations with Procmon
Start Procmon as an administrator, stop the capture once, and clear the existing events. Narrowing the target and recording only while you reproduce the operation you need makes the log easier to read afterwards. For the basic operations, see “A Practical Guide to Process Monitor” as well.13
- Show Duration from Options > Select Columns….
- In Filter > Filter… (Ctrl+L), specify the process name or PID you are targeting, press Add, and then apply it. If child processes or services are the ones doing the actual I/O, include them in the investigation too.
- Start the capture, reproduce the symptom, and stop. Look at Operation, Path, Result and Duration together, and narrow the target down with a Duration filter condition or Tools > File Summary as needed.
Do not depend on a procedure that assumes you can sort by clicking the Duration header in the event list. For a problem made up of a huge number of short operations, extracting only the long durations drops candidate causes, so check the counts as well. Also, CreateFile appears not only for creating a new file but also for opening an existing one. Read the details, not just the operation name.1318
The Duration here is how long the operation took as Procmon observed that event. It is not the execution time of one particular minifilter. It can include waits in the file system, the device or the network below. Adding up the durations of operations that run in parallel does not necessarily match the application’s overall elapsed time.
7.3 Turning fltmc Differences Into “Candidates”
Capture fltmc filters and fltmc instances on both the fast machine and the slow one, and compare the filters attached to the destination in question. Keep the facts you observed separate from their interpretation, as below.
| What you observed | What to check next |
|---|---|
| A particular filter exists only on the slow machine | Its attachment to the volume in question, and the product’s version and policy |
| The configuration is the same, but only one side is slow | What gets scanned, caching, product settings, and storage or network conditions |
| Opening a particular path takes time | The stack for the operation, cloud retrieval or network waits, and the product’s own diagnostics |
| Slow only the first time, or only sporadically | First-time inspection, file changes, and the times at which synchronization or backup runs |
A filter name appearing in a stack is a clue for investigating that code path. But its name being listed is not evidence that the driver ran for a long time. If needed, capture CPU execution and wait behavior with tools such as Windows Performance Recorder/Analyzer and compare them against the product’s diagnostic information.19
If you suspect Defender, the official performance analyzer lets you check which files and processes put the heaviest load on scanning. Start the recording from an elevated PowerShell session on a supported machine, reproduce the symptom in a separate operation, and press Enter to stop. The following example also creates the folder for the recording.20
$traceDirectory = Join-Path $env:TEMP 'DefenderPerformance'
New-Item -ItemType Directory -Path $traceDirectory -Force | Out-Null
$tracePath = Join-Path $traceDirectory ('scan-{0}.etl' -f (Get-Date -Format 'yyyyMMdd-HHmmss'))
# Reproduce the target operation while it records, then press Enter to stop the recording
New-MpPerformanceRecording -RecordTo $tracePath
# Check which files have the largest impact on scanning
Get-MpPerformanceReport -Path $tracePath -TopFiles 10 -TopScansPerFile 5
What this report shows is, again, information about Defender’s scanning. Rather than moving the paths at the top of the list straight into the exclusion list, confirm whether they are related to the slowness you reproduced. The captured log can contain file names, user names and similar data, so be careful about where you store it and who you share it with.
Comparisons made by changing settings come after you have gathered the evidence above. Trying fltmc unload in production, or rewriting an altitude to change the order, is not a general remedy.
8. Rounding Off the Series — A Map of the Six Parts
Across the series we have looked at everything from an application’s API call through name resolution, I/O requests, completion notification, caching and the file system. The minifilter covered here sits at the position that monitors and controls requests headed for the file system.
flowchart TB
accTitle: The perspective each part of the Windows I/O series covers
accDescr: A conceptual diagram relating the subject of each part. It is not a single execution path, and it does not mean that every API call goes through an IRP, the disk and IOCP.
APP["An application's file operation"]
SYNC["Part 2 - Synchronous and asynchronous I/O"]
IOM["Part 1 - The I/O Manager and IRPs"]
FLT["Part 6 - FltMgr and minifilters"]
FS["Part 5 - NTFS internals"]
CACHE["Part 4 - The Cache Manager"]
IOCP["Part 3 - IOCP and processing after completion"]
APP -. "how it is called" .-> SYNC
APP -. "structure of request handling" .-> IOM
IOM -. "monitoring and controlling file I/O" .-> FLT
FLT -. "when it goes further down" .-> FS
FS -. "cooperates on cached I/O" .- CACHE
SYNC -. "matching completion notification model" .-> IOCP
Figure 5: A conceptual diagram of how the parts of the series relate. Not all I/O passes through every box, and some paths complete without any device access or interrupt. IOCP too is a completion notification mechanism used with handles and notification settings that support it.
The diagram is not a single execution trace. The path differs for fast I/O, for requests the cache can satisfy, and for requests that complete without being passed further down. Do not map API calls, file system operations, IRPs and physical disk accesses one to one — that is the point to watch when joining the parts together.2
- Part 1: The Big Picture of the I/O System — name resolution, objects, IRPs and the device stack
- Part 2: Synchronous and Asynchronous I/O — handle modes, OVERLAPPED, and handling completion
- Part 3: IOCP and the .NET Thread Pool — completion notification and continuing the work
- Part 4: The Cache Manager — writes, caching, and reaching storage
- Part 5: NTFS Internals — the MFT, streams, links and journals
- Part 6: Minifilters (this article) — monitoring and controlling file I/O, and investigating environment-dependent slowness
9. Summary — Closing the Series
A minifilter takes part in file I/O through the callbacks FltMgr provides. In a normal round trip, the pre callbacks run from the higher altitude to the lower and the post callbacks run in reverse, but the actual path changes with what was registered and with completion partway through.
Once you know this mechanism, you can explain why file operations appear in Procmon, and why a security product can affect how long a file access takes. At the same time, what can be monitored and what that observation alone cannot tell you both come into view.
When “only this environment is slow”, narrow the operation down in Procmon, confirm what is attached with fltmc instances, and back it up with the product’s diagnostic features and a comparison run under matched conditions. Choose an exclusion setting or Dev Drive after that, once you have checked the conditions under which they apply and their effect on protection. In that order, you can move an investigation forward without weakening protection on guesswork alone.
The structures covered in this series are not there to pin the cause on one component. They are a map for deciding where to measure next. Thinking separately about what can happen underneath a single line of application code is the first step toward turning a defect or a performance problem into something you can reproduce and explain.
Related Articles
- The Depths of Windows I/O (Part 1): The Big Picture of the I/O System
- The Depths of Windows I/O (Part 4): The Cache Manager
- The Depths of Windows I/O (Part 5): NTFS Internals
- A Practical Guide to Process Monitor
- Microsoft Defender False Positives and Their Performance Impact
- Investigating With Process Explorer, Handle and VMMap
- A Minimum Security Checklist for Windows Apps
Related Consulting Areas
KomuraSoft LLC handles investigations into performance problems and defects in Windows business applications, the kind described as “file operations are slow only on the customer’s PC” or “behavior changed after we deployed a security product”. Work can start even at the stage where it is unclear whether the cause is a filter or the application, the file system or the network.
When you contact us, tell us as much as you know: which operation becomes slow, the environments where it does and does not happen, whether you are using a local disk, a shared folder or the cloud, and which security products are deployed. If logs or files contain confidential information, talk to us about how to share them first.
References
-
Microsoft Learn, About file system filter drivers. The role and uses of file system filters. ↩ ↩2
-
Microsoft Learn, Filter Manager Concepts. FltMgr, instances, pre/post ordering, target operations, and coexistence with legacy filters. ↩ ↩2 ↩3 ↩4 ↩5
-
Microsoft Learn, Advantages of the Filter Manager Model. The benefits of the minifilter model and the mechanism for selecting which operations to handle. ↩ ↩2 ↩3
-
Microsoft Learn, PFLT_PRE_OPERATION_CALLBACK. The return values of the pre-operation callback and the constraints on each. ↩ ↩2
-
Microsoft Learn, Processing I/O Operations. Pending and resuming I/O, and consideration for the execution context. ↩ ↩2
-
Microsoft Learn, FAST_IO_DISPATCH structure. The fast I/O processing path, including the legacy model. ↩
-
Microsoft Learn, Load order groups and altitudes for minifilter drivers. Relative position, instance definitions, number ranges by purpose, and decimal altitudes. ↩ ↩2 ↩3
-
Microsoft Learn, Request a Filter Altitude Identifier. How to request one, what to include, and the expected processing time. ↩
-
Microsoft Learn, Blocking legacy file system filter drivers. The output columns of fltmc and the Legacy marking in the Frame column. ↩
-
Microsoft Learn, Tools for minifilter development and testing. Enumerating filters, instances and volumes with fltmc and other tools. ↩ ↩2
-
Microsoft Learn, Allocated altitudes. The published list of filter names and allocated altitudes. ↩ ↩2
-
Microsoft Learn, Cloud Files API. The foundation for cloud synchronization using placeholders. ↩
-
Microsoft Learn, Process Monitor - Sysinternals. Monitoring the file system, the registry, and processes and threads, plus filtering and the stack display. ↩ ↩2 ↩3
-
Microsoft Learn, Configure custom exclusions for Microsoft Defender Antivirus. What exclusions cover and their effect on protection. ↩ ↩2 ↩3
-
Microsoft Learn, FltCancelFileOpen. Cancelling an open in post-create, and the constraint that changes to the file are not rolled back. ↩
-
Microsoft Learn, Set up a Dev Drive on Windows 11. The uses of Dev Drive, the trust setting, and cautions about filter attachment and safety. ↩ ↩2
-
Microsoft Learn, Protect Dev Drive using performance mode. Trusted Dev Drive, the conditions under which Defender operates, and asynchronous scanning. ↩ ↩2
-
Microsoft Learn, CreateFileW. The role of an API that covers both opening an existing file and creating a new one. ↩
-
Microsoft Learn, Windows Performance Recorder. Recording system and application behavior based on ETW. ↩
-
Microsoft Learn, Performance analyzer for Microsoft Defender Antivirus. Recording scans and analyzing the load per file and per process. ↩
Related Articles
Recent articles sharing the same tags. Deepen your understanding with closely related topics.
The Depths of Windows I/O (Part 1) — Every Read and Write Becomes an IRP: The Big Picture of the I/O System
Part 1 of a series on Windows I/O from the ground up: the Object Manager namespace, the driver, device and file objects, the IRP lifecycl...
The Depths of Windows I/O (Part 5) — NTFS Internals: Understanding the File System Through the MFT
An illustrated Part 5 on NTFS internals for developers: the MFT, file records, data streams, hard links, 8.3 names, reparse points, journ...
The Depths of Windows I/O (Part 4) — Cache Manager: When Does Your WriteFile Actually Reach the Disk?
Part 4 of a diagram-led Windows Cache Manager series. It covers the cache as a file mapping, read-ahead, lazy writing, FlushFileBuffers, ...
The Depths of Windows I/O (Part 2) — Synchronous and Asynchronous I/O: What OVERLAPPED Really Means
Part 2 explains Windows synchronous and asynchronous (overlapped) I/O: FILE_FLAG_OVERLAPPED, the four notification paths, synchronous com...
The Depths of Windows I/O (Part 3) — I/O Completion Ports (IOCP) and the .NET Thread Pool: The Basement Under async/await
Part 3 of a diagram-led series on I/O completion ports (IOCP). It covers the queue plus thread-count control, the concurrency value, LIFO...
Related Topics
These topic pages place the article in a broader service and decision context.
Windows Technical Topics
Topic hub for KomuraSoft LLC's Windows development, investigation, and legacy-asset articles.
Bug Investigation & Long-Run Failures
Topic page for intermittent failures, communication diagnosis, long-run crashes, and failure-path test foundations.
Where This Topic Connects
This article connects naturally to the following service pages.
Windows App Development
We support Windows desktop applications that involve resident processing, device integration, operational logging, and maintainable structure.
Bug Investigation & Root Cause Analysis
We investigate difficult production issues such as intermittent failures, long-run crashes, leaks, and communication stoppages.
Frequently Asked Questions
Common questions about the topic of this article.
- What is the difference between a file system filter driver and a minifilter?
- A file system filter driver is the general term for a driver that monitors or controls file I/O. A minifilter is one way of implementing that: it registers per-operation callbacks with the Windows Filter Manager (FltMgr). The main difference from the legacy model is that FltMgr takes care of the shared work such as attaching to the stack and handling completion. The relative position of minifilters with respect to each other is decided by the altitude. Unloading one while the system is running is possible only when that driver supports it and allows itself to be detached.
- Does antivirus software scan every file access every time?
- Not necessarily. A minifilter is called according to conditions such as the volumes it is attached to and the operations it registered for. What it then scans depends on the product's policy, whether the file has changed, exclusion settings and so on. Having a mechanism that monitors file I/O is not the same as rescanning the whole file on every access.
- Is an antivirus exclusion setting a way of removing the filter driver?
- Usually not. It is a setting that skips, for the excluded target, the scanning that the setting applies to. Nor does it disable another vendor's EDR, backup or encryption products all at once. What an exclusion covers differs by product and by protection feature, and a broad folder exclusion weakens protection. In a performance investigation, measure first and make configuration changes only within the smallest scope agreed with the administrator.
- Can Process Monitor alone identify a slow filter driver?
- Procmon helps you find slow operations and the paths involved, but Duration is not the processing time of an individual minifilter. A driver name merely appearing in a stack is not enough to settle the cause either. Confirm the attachment to the volume in question with fltmc, and back it up with the product's diagnostic features, additional tracing, and comparisons run under matched conditions. Procmon's record is also not an exhaustive account of every access to the physical disk.
- If builds are slow, will moving them to a Dev Drive always help?
- Not always. Microsoft Defender's performance mode has prerequisites such as a trusted Dev Drive, Defender running as the primary antivirus, and real-time protection being enabled. It makes the scanning of the file opens it covers asynchronous to limit the impact, but it is not a feature that resolves the behavior of other vendors' products or other bottlenecks such as CPU or network.