Process Monitor(ProcMon)実践ガイド ── 「設定が読まれない」「ACCESS DENIED」を10分で特定する

「設定ファイルを書き換えたのに、アプリの挙動が変わらない」「開発機では動くのに、客先の端末だけ起動直後に落ちる」「昨日までは動いていた。プログラムは何も変えていない」──不具合調査の依頼は、たいていこの形でやってきます。そしてこの種の症状の多くは、ソースコードをいくら読んでも原因にたどり着けません。アプリが実際にどのファイルを読み、どのレジストリを見て、何に失敗したかは、コードではなく実行環境が決めるからです。

その「実際に何が起きたか」を記録してくれるのが、Microsoftが無償で提供しているSysinternalsツールの Process Monitor(ProcMon) です。ファイルシステム・レジストリ・プロセス/スレッドの活動をリアルタイムに全部記録する、いわばWindowsの行動ログレコーダーで、当社の不具合調査でもWinDbgと並んで出番の多いツールです。¹

強力な反面、何もせず起動すると毎秒数千〜数万件のイベントが流れてきて、初見では「多すぎて読めない」で終わりがちです。この記事では、ProcMonを実務で使うための最短ルート──フィルタの掛け方、Result列の読み方、症状別の定番調査パターン、本番環境での注意点、そして他の調査ツールとの使い分け──を、不具合調査の現場目線で整理します。

1. まず結論

• ProcMonが答えてくれる質問は「このプロセスは、いつ・どのパスに・何をして・どうなったか」です。設定ファイルがどこから読まれているか、DLLがどの順で探索されたか、どの操作がACCESS DENIEDになったか、が数分で分かります。
• 使い方の定石は「まずProcess Nameで対象プロセスにIncludeを掛け、次にResultで異常系に絞る」です。生のイベントを上から読むツールではありません。
• Result列は異常に見えて正常なものが多数あります。BUFFER OVERFLOWは正常なAPIの往復、NAME NOT FOUNDは探索順の途中経過であることがほとんどです(4章)。
• フィルタは表示上の絞り込みであり、裏では全イベントが記録されています。ログを保存して人に渡すときは全イベントで保存します。逆に長時間キャプチャではDrop Filtered Eventsでメモリを守ります(5章)。
• ProcMonは万能ではありません。「今どのプロセスがこのファイルを掴んでいるか」はProcess Explorer、クラッシュの瞬間の状態はクラッシュダンプ、CPUをどこで使っているかはPerfViewの領分です(7章)。

症状からツールを選ぶ早見表を先に置いておきます。

2. ProcMonとは何か ── 導入は1分で終わる

Process MonitorはSysinternalsツール群の1つで、ファイルシステム・レジストリ・プロセス/スレッドの活動をリアルタイムに表示する監視ツールです。かつてのFilemonとRegmonという2つのツールを統合・強化した後継で、イベントごとの詳細情報、非破壊のフィルタ、スレッドスタックの記録、ブートタイムロギングなどを備えています。¹

導入は簡単です。インストーラーはなく、ダウンロードページからZIPを取得して展開し、Procmon.exe を実行するだけです。急ぎの調査では、Sysinternals Liveというサービスを使って https://live.sysinternals.com/procmon.exe から直接実行することもできます。² 初回起動時に使用許諾への同意を求められ、カーネルドライバーを読み込むため管理者権限(UACの昇格)が必要です。管理者権限がなぜ要るのかという一般論は「Windowsの管理者特権が必要になるのはいつなのか」で書いたとおりで、OS全体のイベントを見るツールは典型的な「要昇格」の側です。

起動した瞬間からキャプチャが始まり、画面にイベントが流れ始めます。主要な操作は3つだけ覚えれば足ります。

1行のイベントは「Time(時刻)・Process Name(プロセス)・PID・Operation(操作)・Path(対象パス)・Result(結果)・Detail(詳細)」で構成されます。Operationは CreateFile(ファイルを開く/作る)、ReadFile/WriteFile、RegOpenKey/RegQueryValue など、Win32 APIにおおむね対応した粒度です。つまりProcMonのログは「アプリとOSの会話の記録」であり、アプリが設定ファイルを読むつもりで実際にはどこを読んだのか、という「つもり」と「実際」の差がそのまま見えます。

3. フィルタ ── ProcMonは絞り込んでから読むツール

何もせずキャプチャすると、アイドル状態のWindowsでも毎秒数千件のイベントが流れます。ProcMonの実用性はフィルタの使い方で決まると言ってよく、定石は次の2段階です。

第1段階: プロセスで絞る。 Ctrl+Lでフィルタダイアログを開き、Process Name / is / myapp.exe / Include を追加します。ツールバーの照準アイコンを対象アプリのウィンドウにドラッグして、そのプロセスだけにフィルタを掛ける方法もあります。

第2段階: 結果や操作で絞る。 「失敗している操作を探したい」なら Result / is not / SUCCESS / Include(異常系だけ表示)。「書き込みだけ見たい」なら Category / is / Write / Include。「この設定ファイルに触っているのは誰か」ならプロセスで絞らず Path / contains / app.config / Include、という具合です。

さらに実務で多用するのが、イベント行の右クリックからの対話的な絞り込みです。目的に近い行を1つ見つけたら、右クリックして「Include ‘このパス’」「Exclude ‘このプロセス’」を選ぶだけで、ダイアログを開かずにフィルタが積み重なっていきます。ノイズ源(ウイルス対策ソフト、インデクサーなど)をExcludeで消していき、目的の操作の前後だけを残すのが基本動作です。目視の補助にはハイライト(Ctrl+H)も使えます。フィルタと同じ条件式で行に色を付けられるので、「全体の流れは見たいが異常系だけ目立たせたい」ときはフィルタではなくハイライトにします。

3つ、知らないとハマる仕様があります。

• フィルタは表示の絞り込みであって、記録の絞り込みではありません。 裏では(既定では)全イベントが記録されており、フィルタを外せばいつでも全体に戻れます。非破壊フィルタと呼ばれる所以で、「絞り込みすぎて証拠を取り逃す」ことが起きにくい設計です。¹
• フィルタ設定は次回起動時に引き継がれます。 前回の調査のフィルタが残ったまま「何も表示されない」と悩むのは全員が一度は通る道です。表示がおかしいと思ったらFilterメニューのReset Filter(Ctrl+R)を最初に疑ってください。
• 既定でいくつかのExcludeが入っています。 ProcMon自身やページングI/Oなどは最初から除外されています。「システム全体を漏れなく」が要件の調査では既定フィルタの存在を意識してください。

4. Result列の読み方 ── 異常に見えて正常なもの

フィルタで異常系に絞ると、今度は「異常っぽい結果」が大量に出てきて驚くことになります。ここで重要なのは、Result列の異常値の大半は正常な動作の一部だということです。主要なResultの読み方をまとめます。

このうち調査の主役になるのは NAME NOT FOUND・ACCESS DENIED・SHARING VIOLATION の3つです。それぞれ定番の調査パターンがあるので、次章で症状側から見ていきます。

逆に見落としがちなのが「SUCCESSが原因」のパターンです。たとえば「直した設定ファイルが反映されない」の答えが、別の場所にある古い設定ファイルへのSUCCESSだったことは一度や二度ではありません。異常系だけ見ていると正常に読み込まれた「間違った正解」を見逃すので、パスで絞ってそのファイル種別へのアクセスを成功も含めて全部見るのが確実です。

5. 症状別の定番調査パターン

5.1 「設定を直したのに反映されない」── どこから読んでいるかを特定する

Path / contains / 設定ファイル名 でIncludeを掛けてアプリを起動すると、アプリがその名前のファイルをどのフォルダーから、どの順で探したかが一覧になります。よくある真相は次のどれかです。

• exeと同じフォルダーではなく %APPDATA% や ProgramData 配下のコピーを読んでいた(初回起動時にコピーする設計だった)
• 32bitプロセスからのレジストリ・システムフォルダーアクセスがWOW64のリダイレクトを受けて、見ているつもりの場所と実際の場所がずれていた
• インストール先の Program Files 配下への書き込みが仮想化(VirtualStore)されて、読み書きが別の場所に化けていた

どれもProcMonならPathにフルパスが出るので一目で分かります。設定ファイルの置き場所をどう設計すべきかという裏返しの話は「appsettings.jsonだけじゃない ── 構成管理の実務」に書きました。

5.2 「この環境でだけ起動しない」── DLLの探索を追う

起動直後に落ちる・「DLLが見つかりません」系のエラーが出る場合は、プロセスでIncludeした上で Path / ends with / .dll を追加し、NAME NOT FOUNDの連鎖を眺めます。WindowsのDLL探索は決まった順序でフォルダーを辿るので、ProcMonのログには「探索順のとおりにNAME NOT FOUNDが並び、どこかでSUCCESSする(または最後まで見つからない)」という形がそのまま現れます。最後までSUCCESSしないDLLが犯人です。逆に「SUCCESSしているが、意図しない場所の古いDLLを掴んでいる」パターンもここで見つかります。探索順序の理屈は「Windows DLL名前解決の仕組み」を併読してください。

COM/ActiveXがらみの「クラスが登録されていません」も同型で、RegOpenKey の CLSID 配下へのNAME NOT FOUNDとして観測できます。32bit/64bitの取り違えで別ビューのレジストリを見に行っている事故は、「Office 2024/Microsoft 365でActiveXが動かない原因と確認手順」で書いた手順のとおりProcMonが最短です。

5.3 「ACCESS DENIEDになる」── 誰の権限で動いているかを疑う

ACCESS DENIEDを見つけたら、そのイベントをダブルクリックしてProcessタブを確認します。そのプロセスがどのユーザーとして動いていたかが出るので、「サービスはSYSTEMではなく制限されたサービスアカウントで動いていた」「タスクスケジューラ起動時だけ別ユーザーだった」という食い違いがここで判明します。対象がファイルなら、そのパスのACLと突き合わせれば原因確定です。なお、ウイルス対策ソフトが介入しているケースでは、直前直後に別プロセス(対策ソフトのエンジン)が同じパスに触っている様子が見えることが多く、これも時系列で記録するProcMonならではの証拠になります。

5.4 「たまにファイル処理が失敗する」── SHARING VIOLATIONの相手を探す

共有違反は時系列が命の調査です。パスでIncludeを掛けてプロセスのフィルタは掛けずにキャプチャすると、失敗の瞬間に同じファイルを誰が開いていたかが前後の行に現れます。バックアップソフト・ウイルス対策・Excelの残骸プロセスあたりが定番の相手です。ファイル連携でこの競合をそもそも起こさない設計は「ファイル連携の排他制御の基礎知識」に、Excelプロセスが残る問題は「C#のExcel操作でEXCEL.EXEが残る問題」にまとめています。「今この瞬間、誰が掴んでいるか」を知りたいだけなら、ProcMonよりProcess Explorerのハンドル検索(Ctrl+F)が速いことも付記しておきます。³

5.5 「起動が遅い」── どこで時間を食っているかの当たりを付ける

列の設定で Duration 列を追加すると、個々の操作に掛かった時間が見えます。また Tools メニューの Process Activity Summary や File Summary で、プロセス・ファイルごとの操作回数と時間を集計できます。「起動時に数万回のレジストリ読み取りをしていた」「ネットワーク越しのパスへのアクセスがタイムアウトまで待っていた」といった当たり付けには十分です。ただしCPUをどこで使っているかの本格的なプロファイリングはProcMonの領分ではありません。I/Oではなく計算で遅い場合はPerfViewとdotnet-traceに交代します。

5.6 起動時・ログオン時の問題 ── ブートロギング

「サービスがログオン前に失敗する」「スタートアップ登録したアプリが起動しない」など、ProcMonを手で起動するより前に問題が起きるケースには、Optionsメニューの Enable Boot Logging を使います。次回起動時のブート初期からのイベントが記録され、その次にProcMonを起動したときに保存を促されます。ブートタイムロギングはProcMonの公式機能として提供されているもので、¹ スタートアップ順序・ログオンスクリプトがらみの調査ではこれが唯一の目です。

6. ログの保存と受け渡し ── 顧客環境で採ってもらう場合

不具合調査の実務では、再現する環境が顧客側にしかないことが珍しくありません。ProcMonのログはPMLファイルとして保存でき、別のマシンで開いても全カラム・全詳細が見られるので、「顧客に採ってもらい、こちらで解析する」という分業が成立します。依頼するときの手順書は次の形にしています。

1. Procmon.exeを管理者として実行し、使用許諾に同意する
2. 起動したらいったんCtrl+Eでキャプチャを停止し、Ctrl+Xで表示をクリアする
3. Ctrl+Eでキャプチャを開始し、問題の操作を再現する
4. 再現できたら(またはエラーが出たら)すぐCtrl+Eで停止する
5. File > Save で、Events displayed using current filter ではなく All events を選んでPML形式で保存し、ZIP圧縮して送付する

ポイントは5の「All events」です。先方の画面にフィルタが残っていても、記録自体は全量あるので、こちらで自由に絞り直せます。再現に時間が掛かる・いつ起きるか分からない問題では、そのままだとメモリを消費し続けるため、Filter > Drop Filtered Events を有効にして対象プロセスだけ記録するか、File > Backing Files で保存先を仮想メモリではなくファイルに切り替えるかの少なくとも一方を指定します。この2つを知らずに一晩流すと、メモリを食い尽くして調査対象より先にProcMonが限界を迎えます。

自動化したい場合はコマンドラインスイッチも使えます。/AcceptEula で同意ダイアログを抑止し、/BackingFile で記録先ファイルを指定、/Runtime で秒数指定の自動停止、/Terminate で実行中のProcMonを終了、といった組み合わせで「障害発生時にオペレーターがバッチを1つ実行すれば証拠が残る」形にできます。障害時に何を採取するかをあらかじめ決めておく考え方は、クラッシュダンプ収集やイベントログ設計と共通です。

7. ProcMonの限界と、他ツールとの使い分け

ProcMonは「操作の時系列」を見るツールであり、すべての調査に向くわけではありません。当社の調査での役割分担はこうなっています。

境界で迷いやすいのは次の3つです。

• ネットワーク: ProcMonはTCP/UDPの接続・送受信イベント(どのプロセスがどこと通信したか)は記録しますが、パケットの中身は見えません。プロトコル調査はWiresharkかWindows標準のpktmonへ。⁴
• メモリ: 「メモリ使用量が増え続ける」はProcMonでは追えません。マネージドヒープならGCかリークかの切り分け、ハンドルならハンドルリーク調査の手順に進みます。
• スタック: 実はProcMonも各イベントの発行元スレッドスタックを記録しており(イベントのダブルクリック→Stackタブ)、シンボルを設定すれば「誰がこのファイルアクセスを発行したか」をコードレベルで特定できます。ここまで来るとWinDbgの世界と地続きで、シンボル(PDB)の管理が効いてきます。

8. まとめ ── 「コードを読む前に、事実を見る」

環境依存の不具合調査で最初にやるべきことは、コードを読むことでも仮説を立てることでもなく、実際に何が起きたかの記録を取ることです。ProcMonはそのための最短ルートで、導入1分・キャプチャ数分で「どのパスを・どの順で・どの権限で触って・何に失敗したか」という動かぬ事実が手に入ります。フィルタの2段階(プロセス→Result)、異常に見えて正常なResultの読み方、全イベント保存での受け渡し──この3つを押さえれば、「開発機では再現しません」で止まっていた調査が、その日のうちに一歩進みます。

当社では、再現条件の分からない不具合の調査、顧客環境でしか起きない障害の証拠採取手順の整備、ProcMon・WinDbg・PerfViewを組み合わせた原因解析を請け負っています。「ログには何も出ていないが動かない」という段階からでもお手伝いできます。

関連記事

• WinDbg + SOSでクラッシュダンプを読む ── 収集した後の実務解析入門
• PerfViewとdotnet-traceで「遅い」を特定する ── .NETパフォーマンス調査の実務入門
• Windowsクラッシュダンプ収集入門 - WER/ProcDump/WinDbg
• Windows DLL名前解決の仕組み - 検索順序とSxS
• 産業用カメラ長期稼働クラッシュ調査 - ハンドルリーク編

関連する相談領域

合同会社小村ソフトでは、環境依存で再現しにくい不具合の原因調査、障害時の証拠採取手順の整備、既存Windowsアプリのトラブルシューティング支援を扱っています。

• 不具合調査・原因解析
• 技術相談・設計レビュー
• 既存Windowsソフトの改修・保守
• お問い合わせ

参考リンク

関連する記事

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

関連トピック

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

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

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

よくある質問

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

ProcMonは本番環境で動かしても大丈夫ですか？

短時間のキャプチャなら実務上よく行われますが、無条件に安全ではありません。ProcMonはドライバーを読み込んで大量のイベントを記録するため、イベントの発生量が多いサーバーではCPUとメモリを目に見えて消費します。対策は3つで、(1)再現操作の直前に開始して直後に停止し、キャプチャ時間を最短にする、(2)長時間の監視が必要な場合はFilter メニューのDrop Filtered Eventsを有効にしてフィルタ外のイベントを保持しない、(3)記録先をメモリではなくファイルにするBacking Fileを設定する、です。また業務時間外の実施やスナップショット取得後の実施など、通常の変更作業と同じ承認プロセスに乗せることをおすすめします。

イベントが多すぎて目的の行が見つかりません。どう絞り込めばよいですか？

最初にProcess Nameで対象プロセスだけにIncludeを掛け、次にResultで異常系(NAME NOT FOUND、ACCESS DENIEDなど)に絞るのが定石です。目的の行が1つ見つかったら、その行を右クリックして表示されるIncludeやExcludeで対話的に絞り込んでいきます。逆に「フィルタを掛けたまま保存して情報が足りなかった」という失敗も多いので、ログをファイルに保存して他の人に渡す場合は、フィルタはあくまで表示上の絞り込みであることを意識して全イベントを保存してください。なお、フィルタ設定は次回起動時にも引き継がれるため、「何も表示されない」ときは前回の古いフィルタが残っていないかをFilterメニューのReset Filterで確認してください。

Result列のBUFFER OVERFLOWはバグや攻撃の兆候ですか？

違います。セキュリティ用語のバッファオーバーフロー攻撃とは無関係で、「呼び出し側が用意したバッファより必要なデータが大きかったので、必要サイズを返した」という正常なAPIの往復です。多くのAPIは最初に小さいバッファで呼んで必要サイズを教えてもらい、確保し直して再呼び出しする設計なので、直後に同じパスへのSUCCESSが並んでいれば問題ありません。同様に、NAME NOT FOUNDも「探索順の途中で見つからなかった」だけのことが多く、最終的にどこかでSUCCESSしていれば異常ではありません。異常系のResultは「その操作の失敗がアプリの症状と因果でつながっているか」まで確認して初めて原因と言えます。

Process ExplorerとProcess Monitorはどう使い分けますか？

Process Monitorは「操作の流れ(いつ・どのプロセスが・どのパスに・何をして・どうなったか)」を時系列で記録するツール、Process Explorerは「今この瞬間の状態(どのプロセスがどのファイルやDLLを開いているか、CPU・メモリの使用状況)」を見るツールです。たとえば「このファイルを削除できない。誰が掴んでいるのか」を知りたいならProcess Explorerのハンドル検索が最短で、「アプリがこのファイルをいつ・どんな順で読んでいるのか」を知りたいならProcess Monitorです。実務では両方をSysinternals Suiteとして常備し、状態はProcess Explorer、履歴はProcess Monitorと覚えておくと迷いません。

著者プロフィール

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

小村 豪

合同会社小村ソフト 代表

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