Windows I/Oの深層(第6回・最終回) ── ミニフィルターの仕組みとProcmonによる遅延調査

ファイルを開くだけなのに、特定のPCでは時間がかかる。ウイルス対策ソフトを入れた環境では、ビルドや大量のファイルコピーが遅くなる。一方、Process Monitorを起動すると、自分のアプリを変更していないのにファイル操作の記録が見える。

この二つを理解する手掛かりが、ファイルI/Oの途中で監視や制御を行う、ファイルシステムフィルタードライバーです。Windowsには、そのための拡張点が用意されています。¹

連載「Windows I/Oの深層」の最終回では、現在の標準的な実装方式であるミニフィルターを取り上げます。前半で仕組みを押さえ、後半では fltmc とProcmonを使って「どの環境で、どの操作が遅いのか」を調べる手順につなげます。ドライバーを開発しないアプリ開発者にも、性能問題を切り分けるための見取り図になるはずです。

1. まず結論

ミニフィルターは、Windows付属のフィルターマネージャー(FltMgr)に「どの操作を、どの段階で処理するか」を登録するドライバーです。FltMgrは、登録内容とアルティチュードという相対位置の指定に従ってコールバックを呼びます。アプリから見れば同じファイル操作でも、途中にあるフィルターの処理が、結果や所要時間に影響することがあります。²

ただし、「フィルターがある」と「そのフィルターが遅さの原因である」は別です。 fltmc は構成を確認する道具、Procmonは操作を観察する道具です。どちらも、一覧や一つの数値だけで原因を確定する道具ではありません。

本記事では、次の区別を軸に読み進めます。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全34件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. 挟まる者たちの歴史 ── レガシーフィルターからFltMgrへ

ファイルシステムフィルタードライバーは、ファイルシステムや他のフィルターに向かう要求を監視・制御するドライバーです。ウイルス対策、暗号化、バックアップなどで使われ、要求の記録だけでなく、パラメーターの変更やアクセスの拒否なども行えます。ここでいう「割り込む」は、CPUのハードウェア割り込みではなく、I/Oの処理経路に介在するという意味です。¹

レガシー方式では、フィルター自身がデバイスオブジェクトをデバイススタックに接続し、要求を下位へ渡したり、完了を処理したりします。接続順序や安全な取り外し、他のフィルターとの共存まで、実装側が扱う範囲が広い方式です。

これに対してミニフィルター方式では、スタックへの接続などの共通処理をFltMgrが引き受け、各ドライバーは必要な操作のコールバックを登録します。 ミニフィルターもカーネルモードのドライバーであり、ドライバーオブジェクトがなくなるわけではありません。変わるのは、ファイルシステムのスタックに参加するための仕組みです。³

flowchart TB
    accTitle: レガシー方式とミニフィルター方式
    accDescr: レガシー方式ではフィルター自身がスタックへ接続し、ミニフィルター方式ではFltMgrに処理を登録することを比較する図。
    ROOT["ファイルI/Oへの参加方法"]
    ROOT -->|"レガシー方式"| LEG["フィルター自身が接続"]
    ROOT -->|"ミニフィルター方式"| MINI["FltMgrに処理を登録"]
    LEG --> OWN["接続・完了処理を実装"]
    MINI --> SHARED["FltMgrが共通処理を担当"]

図1: フィルター自身がスタックへ接続する方式と、FltMgrに処理を登録する方式の比較。

図は、ミニフィルターに代わってFltMgrがスタックへ接続する構成を示しています。実際にはレガシーフィルターとの共存のため、FltMgrが複数のフレームとして異なる位置へ接続することもあります。共存には配置上の制約があり、ミニフィルター化だけで相性問題が全て解消するわけではありません。²

FltMgrはロード順による位置の不安定さを抑え、稼働中のアンロードも支援します。ただし、取り外せるのは対応するコールバックを実装し、アンロードを許可するドライバーです。調査中に任意のフィルターを外してよい、という保証ではありません。³

3. ミニフィルターの動き ── pre/postコールバック

ミニフィルターは、たとえば IRP_MJ_CREATE に対応するオープン・作成操作や、IRP_MJ_WRITE に対応する書き込み操作を処理対象として登録します。preコールバックは下位へ渡す前、postコールバックは下位から結果が戻る段階の処理です。両方を登録することも、必要な側だけを登録することもできます。²

次の図は、AとBがどちらも同じ操作を処理し、preで下位へ要求を渡してpostの呼び出しを求めた場合です。

sequenceDiagram
    accTitle: 下位へ渡して完了を受け取る場合のコールバック順序
    accDescr: AとBの両方が対象操作を登録して下位へ渡しpostを求める場合、preは高いアルティチュードから、postは逆順に呼ばれる。
    participant FM as FltMgr
    participant A as フィルターA（高）
    participant B as フィルターB（低）
    participant FS as ファイルシステム
    FM->>A: pre
    FM->>B: pre
    FM->>FS: 下位へ渡す
    FS-->>FM: 処理結果
    FM-->>B: post
    FM-->>A: post

図2: 通常の往復ではpreが高いアルティチュードから低い順、postがその逆順になります。全ての要求でこの往復が発生するわけではありません。

preの戻り値は、その後の処理を決めます。代表的なものを整理すると、次のようになります。⁴⁵

あるフィルターがpreで要求を完了した場合、要求はそれより下位のフィルターやファイルシステムには進みません。FLT_PREOP_COMPLETE を返したフィルター自身のpostも呼ばれず、既に要求を受けてpostを求めた上位側へ完了が戻ります。したがって「登録してあるから必ずpreとpostが両方呼ばれる」とは考えないことが重要です。⁴

また、保留は単なる待ち時間の追加ではありません。保留したドライバーには、要求を適切に再開・完了させる責任があります。実装では操作種別、IRQL、バッファーの寿命、キャンセルなどの制約も扱います。本記事の表は処理の見取り図であり、そのまま実装手順になるものではありません。⁵

3.1 ファストI/Oも対象になるが、「全I/Oが見える」わけではない

FltMgrが扱うのはIRPベースのI/Oだけではなく、ファストI/Oとファイルシステムフィルター(FSFilter)のコールバック操作も含まれます。「IRPを使わない経路だからミニフィルターには見えない」という理解は誤りです。逆に、全てのアクセスが必ずIRPになり、同じコールバック列を通るという理解も正確ではありません。²

観察できる範囲は、接続しているボリューム、登録した操作、登録時の除外条件、上位で要求が完了するかどうかなどで変わります。メモリマップされたファイルへの個々のメモリアクセスが、その都度一つのファイルI/Oイベントとして記録されるわけでもありません。レガシーフィルターにもファストI/Oを扱う仕組みはあり、ファストI/Oへの対応そのものがミニフィルターだけの機能ではありません。³⁶

4. アルティチュード ── 「標高」が順序を決める

同じ操作に複数のフィルターが関わるなら、どの順序で処理するかを決める必要があります。その相対位置を指定するのがアルティチュード(altitude)です。数値が大きいほどファイルシステムから遠い側、小さいほど近い側に位置します。スレッドの優先度や、その製品の性能・重要度を表す数値ではありません。⁷

設定はドライバーのインスタンス定義に記述され、実際にあるボリュームへ接続されたものがインスタンスになります。同じ定義が複数のボリュームに適用されるため、ボリュームごとに別のアルティチュードを発行するわけではありません。 一つのドライバーに複数の定義を持たせることも可能ですが、複数アルティチュードの割り当ては一般的な使い方ではありません。⁷

用途別のロード順グループと番号帯は、次のように定められています。

flowchart TB
    accTitle: ミニフィルターの用途別アルティチュード帯
    accDescr: 高い数値ほどファイルシステムから遠い相対位置になる。図は一部のグループの抜粋であり最上位から最下位までを網羅しない。
    TOP["数値が大きい側"] --> 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["さらに下の用途別グループへ"]

図3: 用途別のアルティチュード帯の抜粋。実際にはActivity Monitorより上の帯もあり、監視フィルターが常にスタック全体の最上位になるわけではありません。

最初のアルティチュードはMicrosoftに申請します。同じロード順グループですでに整数の値を割り当てられている場合は、その値に小数部を付けたアルティチュードを作り、Microsoftへ連絡する仕組みもあります。既存の整数値を持たない開発者が、任意の番号を自由に使ってよいという意味ではありません。⁷

開発時は、Request a Filter Altitude Identifierに従い、fsfcomm@microsoft.com 宛てに件名 Filter altitude request のASCIIテキストメールを送ります。会社名、長期利用する会社の連絡先、製品名・URL、説明、ドライバーファイル名、フィルター種別、起動種別、希望するグループと番号などを記入します。公式の案内では処理に30営業日を見込む必要があり、希望どおりの番号になるとは限りません。開発・配布の計画段階で確認しておく項目です。⁸

5. 住人紹介 ── fltmcで見るあなたのPC

仕組みが分かったら、実際の構成を確認します。管理者としてコマンドプロンプトを開き、次の読み取り用コマンドを実行します。⁹¹⁰

:: ロードされているファイルシステムフィルターの一覧
fltmc filters

:: フィルターとボリュームの接続状況
fltmc instances

:: ボリュームの一覧
fltmc volumes

fltmc filters は、引数なしの 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

filters に名前があることと、問題のファイルが置かれたボリュームに接続されていることは分けて確認します。構成比較では instances まで見るのがポイントです。接続先を確認しても、その操作に対するコールバック登録や、実際に行った処理までは分かりません。¹⁰

5.1 よく見かけるフィルター

WdFilter はMicrosoft Defenderのフィルターで、割り当てはAnti-Virus帯の 328010 です。cldflt はCloud Files APIを支えるクラウドファイルフィルターで、409500 が割り当てられています。OneDriveのファイルオンデマンドでは、ローカルのプレースホルダーと同期プロバイダーが連携して、必要なデータを取得します。ファイルを開くたびに必ず全体をダウンロードする、という意味ではありません。¹¹¹²

Procmonのファイルシステム監視もミニフィルターを利用します。起動前後の fltmc filters を比較すると、環境によっては PROCMON で始まる名前のドライバーを確認できます。末尾の番号やロード・アンロードのタイミングは固定と考えず、手元の状態を確認してください。

ただし、Procmonのレジストリやプロセス・スレッドの監視まで、全てがファイルシステム用のミニフィルターで実現されるわけではありません。また、Procmonの一行は物理ディスクアクセス一回を意味しません。ファイル操作の観察と、ストレージ装置の動作の観察は別の層です。¹³

6. ウイルス対策はどこで時間を使うのか

ファイル操作の途中でスキャン結果を待つ構成なら、その待ち時間はアプリが操作を終えるまでの時間に含まれます。小さなファイルを大量に作成・更新するビルドでは、一つずつの確認処理が積み重なることもあります。ただし、毎回のアクセスでファイル全体を読み直すと決まっているわけではなく、スキャンの条件やタイミングは製品・設定によって異なります。¹⁴

次は、オープン後の検査をアプリへ結果を返す前に行う場合の概念図です。特定製品の内部実装や、全てのファイルの処理順を保証する図ではありません。

sequenceDiagram
    accTitle: スキャン結果を待ってオープンを完了する構成の例
    accDescr: post-createで検査を行う製品構成を例示する。全製品の実装を示す図ではなく、必ず毎回スキャンするわけでもない。
    participant APP as アプリ
    participant AV as AVミニフィルター
    participant FS as ファイルシステム
    APP->>AV: ファイルを開く
    AV->>FS: 条件を確認して下位へ渡す
    FS-->>AV: オープン成立
    Note over AV: この例ではpost-createで検査結果を待つ
    alt 検査で許可された場合
        AV-->>APP: 成功結果
    else 拒否が必要な場合
        Note over AV: 制約に従ってオープンを取り消す
        Note over AV: 作成・上書きの変更は巻き戻さない
        AV-->>APP: 失敗結果
    end

図4: post-createで検査結果を待つ構成の例。実際の検査条件・時期は製品によって異なり、これだけで遅延の原因を特定することはできません。

技術的には、成功したcreateのpostコールバックで FltCancelFileOpen を呼び、失敗ステータスを設定してオープンを失敗扱いにする仕組みがあります。ただし、これはファイル変更を巻き戻す機能ではありません。新規作成したファイルを削除したり、上書き前の内容を復元したりするものではなく、呼び出しにはハンドル作成前などの制約があります。¹⁵

6.1 除外設定は「フィルターの撤去」ではない

除外設定は、その設定が適用されるスキャンの対象を減らすものです。フィルター自体をスタックから取り外す設定ではなく、他社のEDR、バックアップ、暗号化フィルターなどに共通して効く設定でもありません。同じ製品群でも、ウイルス対策の除外と他の保護機能の除外を同一視しないことが必要です。¹⁴

したがって、除外しても遅い場合に考えるべきなのは「設定が壊れている」とは限りません。適用対象や管理ポリシー、別のフィルター、ファイルシステム、ネットワーク、アプリ側の待機などを確認する余地があります。逆に除外で速くなっても、その結果だけでスキャン以外の要因がないとまでは言えません。

広い除外や保護機能の停止を、最初の調査手順にはしません。 先にログと再現条件を記録し、変更が必要なら管理者とリスクを確認したうえで、範囲・期間・元に戻す手順を決めます。誤検知への対処は「自社開発のWindowsアプリがウイルス扱いされたら」でも扱っています。¹⁴

6.2 Dev Driveは、条件付きでスキャンの影響を抑える選択肢

開発用のファイル置き場では、Dev Driveも検討対象になります。Microsoft Defenderのパフォーマンスモードは、対象のファイルオープンに対するスキャンを非同期に行い、保護を残しながら性能への影響を抑える仕組みです。Microsoftは、開発用途でのフォルダー除外に対する、より安全な代替として位置付けています。¹⁶¹⁷

ただし、信頼済みDev Driveであること、Defenderが主たるウイルス対策として動作していること、リアルタイム保護が有効であることなどが前提です。一般のNTFSフォルダーを指定すれば同じ動作になるわけでも、全てのウイルス対策製品が非同期スキャンに切り替わるわけでもありません。 Dev Driveではフィルターの接続ポリシーも確認し、必要なセキュリティ製品やバックアップ製品との互換性を確かめます。¹⁷¹⁶

7. 「あの環境だけ遅い」を調べる

調査では、遅い操作を特定する → 対象ボリュームの構成を比較する → 候補を追加測定で確かめる、という順序で進めます。毎回遅い場合も、初回だけ・時々だけ遅い場合も、フィルターを候補から外す理由にはなりません。

7.1 まず再現条件を揃える

比較する前に、アプリのバージョン、操作内容、入力ファイル、保存先、実行ユーザー、OSとセキュリティ製品のバージョンを記録します。ローカルファイルとUNCパス、未取得のクラウドファイルとローカルに取得済みのファイルを混ぜて比較しないようにします。

初回と二回目以降も分けます。キャッシュの状態、同期の進行、他の処理の有無が違えば、同じ操作でも所要時間は変わり得ます。何度か再現し、アプリ全体の経過時間と、トレースを採取した時間帯を対応させます。

7.2 Procmonで遅い操作を見つける

Procmonを管理者として起動し、いったんキャプチャーを停止して既存のイベントを消します。対象を絞り、必要な操作を再現する間だけ記録して停止すると、後で読み返しやすくなります。基本操作は「Process Monitor実践ガイド」も参照してください。¹³

1. Options > Select Columns… で Duration を表示します。
2. Filter > Filter…(Ctrl+L) で対象のプロセス名やPIDを指定し、Add を押してから適用します。子プロセスやサービスが実際のI/Oを行う場合は、それらも調査対象にします。
3. キャプチャーを開始して症状を再現し、停止します。Operation、Path、Result、Durationを一緒に確認し、必要に応じてDurationのフィルター条件や Tools > File Summary を使って対象を絞ります。

イベント一覧のDurationヘッダーをクリックすれば並べ替えられる、という手順には依存しません。短時間の操作が大量に発生する問題では、長いDurationだけを抽出すると原因候補を落とすため、件数も確認します。また、CreateFile は新規作成だけでなく既存ファイルのオープンにも現れます。操作名だけでなく詳細を読みます。¹³¹⁸

ここでのDurationは、Procmonがそのイベントとして観測した操作の所要時間です。特定のミニフィルターだけの実行時間ではありません。 下位のファイルシステムやデバイス、ネットワークなどの待ちが含まれ得ます。並行する操作のDurationを足しても、アプリ全体の経過時間と一致するとは限りません。

7.3 fltmcの差分を「候補」に変える

速い環境と遅い環境で fltmc filters と fltmc instances を採取し、問題の保存先に接続されたフィルターを比較します。次のように、観察した事実と、その解釈を分けます。

スタックにフィルター名が現れるのは、その処理経路を調べる手掛かりです。しかし、名前が載っているだけで、そのドライバーが長時間動作した証拠にはなりません。必要ならWindows Performance Recorder/AnalyzerなどでCPU実行や待機の状況も採取し、製品の診断情報と突き合わせます。¹⁹

Defenderを疑う場合には、公式のパフォーマンスアナライザーでスキャンの負荷が大きいファイルやプロセスを確認できます。対応環境の管理者PowerShellで記録を開始し、別の操作で症状を再現した後、Enterで停止します。次は記録先フォルダーも作る例です。²⁰

$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'))

# 記録中に対象の操作を再現し、Enterで記録を停止する
New-MpPerformanceRecording -RecordTo $tracePath

# スキャンへの影響が大きいファイルを確認する
Get-MpPerformanceReport -Path $tracePath -TopFiles 10 -TopScansPerFile 5

このレポートが示すのも、Defenderのスキャンについての情報です。上位に出たパスをそのまま除外リストへ移すのではなく、再現時の遅さと関連しているかを確かめます。採取ログにはファイル名やユーザー名などが含まれることがあるため、保存先・共有先にも注意します。

設定変更による比較は、ここまでの証拠を集めた後に行います。本番環境で fltmc unload を試したり、アルティチュードを書き換えて順序を変えたりすることを、一般的な対処法にはしません。

8. 連載の総仕上げ ── 6回の地図

連載全体では、アプリのAPI呼び出しから、名前解決、I/O要求、完了通知、キャッシュ、ファイルシステムまでを見てきました。今回のミニフィルターは、そのうちファイルシステムへの要求を監視・制御する位置にあります。

flowchart TB
    accTitle: Windows I/O連載の各回が扱う観点
    accDescr: 各回の主題を関連付ける概念図。一本の実行経路ではなく、全API呼び出しがIRP、ディスク、IOCPを通るという意味ではない。
    APP["アプリのファイル操作"]
    SYNC["第2回: 同期・非同期I/O"]
    IOM["第1回: I/OマネージャーとIRP"]
    FLT["第6回: FltMgrとミニフィルター"]
    FS["第5回: NTFSの内部構造"]
    CACHE["第4回: キャッシュマネージャー"]
    IOCP["第3回: IOCPと完了後の処理"]
    APP -. "呼び出し方法" .-> SYNC
    APP -. "要求処理の構造" .-> IOM
    IOM -. "ファイルI/Oの監視・制御" .-> FLT
    FLT -. "下位へ進む場合" .-> FS
    FS -. "キャッシュ有効I/Oで協調" .- CACHE
    SYNC -. "対応する完了通知方式" .-> IOCP

図5: 連載各回の関係を示す概念図。全てのI/Oが全ての箱を通るわけではなく、デバイスへのアクセスや割り込みを伴わずに完了する経路もあります。IOCPも、対応するハンドルや通知設定で使う完了通知の仕組みです。

図は一つの実行トレースではありません。ファストI/O、キャッシュで処理できる要求、下位に渡らず完了する要求などでは経路が変わります。APIの呼び出し、ファイルシステムの操作、IRP、物理ディスクアクセスを一対一に対応させないことが、各回をつなぐときの注意点です。²

• 第1回: I/Oシステムの全体像 ── 名前解決、オブジェクト、IRPとデバイススタック
• 第2回: 同期・非同期I/O ── ハンドルのモード、OVERLAPPED、完了の扱い
• 第3回: IOCPと.NETスレッドプール ── 完了通知と処理の継続
• 第4回: キャッシュマネージャー ── 書き込み、キャッシュ、ストレージへの反映
• 第5回: NTFSの内部構造 ── MFT、ストリーム、リンク、ジャーナル
• 第6回: ミニフィルター(本記事) ── ファイルI/Oの監視・制御と、環境依存の遅延調査

9. まとめ ── 連載の結びに

ミニフィルターは、FltMgrが用意するコールバックを通してファイルI/Oに関わります。通常の往復ではpreが高いアルティチュードから低い順、postが逆順ですが、登録内容や途中での完了によって実際の経路は変わります。

この仕組みを知ると、Procmonにファイル操作が現れる理由や、セキュリティ製品がファイルアクセスの時間に影響し得る理由を説明できます。同時に、監視できる範囲と、その観測だけでは分からないことも見えてきます。

「特定環境だけ遅い」ときは、Procmonで操作を絞り、fltmc instances で接続先を確認し、製品の診断機能や条件を揃えた比較で裏付ける。除外設定やDev Driveは、その後で適用条件と保護への影響を確認して選ぶ。この順序なら、推測だけで保護を弱めることなく、調査を進められます。

連載で扱った構造は、原因を一つに決めつけるためではなく、次にどこを測ればよいかを判断するための地図です。アプリの一行の下で何が起き得るかを分けて考えることが、不具合や性能問題を再現・説明できる形にする第一歩になります。

関連記事

• Windows I/Oの深層(第1回): I/Oシステムの全体像
• Windows I/Oの深層(第4回): キャッシュマネージャー
• Windows I/Oの深層(第5回): NTFSの内部構造
• Process Monitor実践ガイド
• Microsoft Defenderの誤検知対応と性能影響
• Process Explorer・Handle・VMMapによる調査
• Windowsアプリのセキュリティ最小チェックリスト

関連する相談領域

合同会社小村ソフトでは、「客先のPCだけファイル操作が遅い」「セキュリティ製品を導入してから動作が変わった」といったWindows業務アプリの性能問題・不具合の調査を扱っています。原因がフィルターなのか、アプリ・ファイルシステム・ネットワークなのか分からない段階でも、調査対象になります。

お問い合わせの際は、分かる範囲で、遅くなる操作、発生する環境と発生しない環境、ローカル・共有フォルダー・クラウドのどこを使うか、導入しているセキュリティ製品をお知らせください。機密情報を含むログやファイルの共有方法は、先にご相談ください。

• Windowsアプリ開発
• 不具合調査・原因解析
• 技術コンサルティング

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

ファイルシステムフィルタードライバーとミニフィルターは何が違いますか？

ファイルシステムフィルタードライバーは、ファイルI/Oの監視や制御を行うドライバーの総称です。ミニフィルターはその実装方式の一つで、Windowsのフィルターマネージャー(FltMgr)に操作ごとのコールバックを登録します。レガシー方式との主な違いは、スタックへの接続や完了処理などの共通処理をFltMgrが担当することです。ミニフィルター同士の相対位置はアルティチュードで決まります。稼働中のアンロードは、そのドライバーが対応し、取り外しを許可する場合に限られます。

ウイルス対策ソフトはすべてのファイルアクセスを毎回スキャンしますか？

必ずしもそうではありません。ミニフィルターは、接続先のボリュームや登録した操作などの条件に応じて呼ばれます。そのうえで何をスキャンするかは、製品のポリシー、ファイルの変更状態、除外設定などによって変わります。ファイルI/Oを監視する仕組みがあることと、全アクセスでファイル全体を再スキャンすることは別です。

ウイルス対策ソフトの除外設定は、フィルタードライバーを取り外す設定ですか？

通常は違います。除外対象について、その設定が適用されるスキャンを省略するための設定です。他製品のEDR、バックアップ、暗号化などをまとめて無効にするものでもありません。除外の対象範囲は製品や保護機能によって異なり、広いフォルダー除外は保護を弱めます。性能調査では先に測定し、設定変更は管理者と合意した最小範囲で行います。

Process Monitorだけで、遅いフィルタードライバーを特定できますか？

Procmonは遅い操作や対象パスを探すのに役立ちますが、Durationは個々のミニフィルターの処理時間ではありません。スタックにドライバー名が現れるだけでも原因は断定できません。fltmcで対象ボリュームへの接続を確認し、製品の診断機能や追加のトレース、条件を揃えた比較で裏付けます。また、Procmonの記録は物理ディスクへの全アクセスを漏れなく表すものではありません。

ビルドが遅い場合、Dev Driveに移せば必ず改善しますか？

必ず改善するとは限りません。Microsoft Defenderのパフォーマンスモードは、信頼済みDev Drive、Defenderが主たるウイルス対策であること、リアルタイム保護が有効であることなどが前提です。対象のファイルオープンに対するスキャンを非同期化して影響を抑えますが、他社製品の動作や、CPU・ネットワークなど別のボトルネックまで解消する機能ではありません。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。