Windows 11 Pro で TCPView を使っていたら、ある日突然「Sent Packets / Sent Bytes / Rcvd Packets / Rcvd Bytes」がすべて空白になった――インターネットは普通に使えるのに、TCPView だけが沈黙している。この少し不思議で厄介な現象について、原因の考え方と実践的な復旧手順、そして再発防止のコツまでをまとめます。
TCPViewで送受信パケット・バイト数が表示されない症状の整理
まずは、問題を正しく言語化しておきます。今回のケースの典型的な状況は次のようなものです。
- OS は Windows 11 Pro
- Sysinternals の TCPView を常用している
- ファイアウォールの送信規則を大量に無効化している最中に現象が発生
- ブラウザもメールも普通に使えており、インターネット接続自体は生きている
- しかし TCPView の 送受信パケット／バイト数の列がすべて空白（ゼロではなく空欄）
このとき多くの人が「TCPView が壊れた？」「OS のネットワーク機能がおかしくなった？」と不安になりますが、実際には以下のような仕組み上の要因で説明できます。
TCPViewのカウンタはどこから情報を取っているのか
TCPView は単に「現在の接続一覧」を見ているだけではありません。送受信バイト数やパケット数を表示するために、Windows 内部の ETW（Event Tracing for Windows） やネットワークスタックの統計情報を参照しています。
- カーネルレベルのトレースセッション（NT Kernel Logger）から情報を取得する
- TCP/IP スタックや Winsock の統計を組み合わせて表示する
- そのため、トレース機構やスタック側の状態が崩れるとカウンタが更新できなくなる
今回のように「ファイアウォール送信規則を大量にいじっている最中」に発生した場合、以下のようなことが起きた可能性があります。
- ネットワークトレース用の ETW セッションが停止／異常状態になった
- Winsock（ソケット API）のカタログが壊れ、統計情報を正常に取れなくなった
- セキュリティソフトやファイアウォールがトレースフックに干渉した
インターネットは生きているので「通信そのもの」は問題なく動いています。しかし、「通信を観察するための機構」だけが壊れている状態と考えると、現象のイメージがつかみやすくなります。
まず確認したい基本：管理者権限と再起動
本格的な対処に入る前に、前提条件となる基本チェックを押さえておきましょう。
TCPViewは「管理者として実行」が前提
TCPView はカーネルレベルの情報まで参照するため、標準ユーザー権限では情報が不足する場合があります。送受信カウンタが空白になったら、まず次の点を確認します。
- TCPView のショートカットや exe を右クリックし、「管理者として実行」で起動しているか
- 常用するなら、ショートカットの「互換性」タブから 「管理者としてこのプログラムを実行する」 にチェックを入れておく
これだけでカウンタが復活するケースもあるため、最初に試す価値のあるポイントです。
PC再起動直後にTCPViewを起動してみる
次に効果的なのが、PC再起動後すぐに TCPView を立ち上げる方法です。
- Windows を再起動
- 起動後、他のアプリを動かす前に TCPView を 管理者として実行
- Web ブラウザなどで通信を少し発生させ、カウンタが動くか確認
ネットワークトレースに関わる多くの問題は、再起動時に初期化されます。再起動後にカウンタが戻るようであれば、一時的なトレース機構の不整合だったと判断できます。
| チェック項目 | 確認内容 | 期待される結果 |
|---|---|---|
| 起動権限 | TCPView を「管理者として実行」しているか | 管理者で起動すると一部の情報が復活することがある |
| 起動タイミング | Windows 再起動直後に TCPView を起動 | 送受信カウンタが通常どおり動作するかを確認 |
これでも改善が見られない場合、次のステップとしてネットワークスタックと ETW セッションに踏み込んでいきます。
ネットワークスタックをリセットして統計情報を再構築する
TCPView のカウンタに関係する Winsock と IP スタックが壊れている場合、コマンドでリセットすることで復旧する可能性があります。
実行前の注意点
- 以下のコマンドは管理者権限のコマンドプロンプトで実行します
- VPN クライアントやプロキシソフトなど、一部のネットワーク関連ソフトの設定が初期化される可能性があります
- 実行後は必ず再起動が必要です
実行するコマンド
管理者権限でコマンドプロンプトを開き、次の 2 行を順番に実行します。
netsh winsock reset
netsh int ip reset
- netsh winsock reset → Winsock カタログを初期状態に戻し、ソケットレベルのフックや異常な設定をリセットします。
- netsh int ip reset → TCP/IP スタックの設定を初期化し、IP レベルの異常な状態をリセットします。
その後、Windows を再起動し、再度 TCPView を管理者として起動してカウンタが回復しているか確認します。
| コマンド | 役割 | 影響・注意点 |
|---|---|---|
| netsh winsock reset | Winsock カタログのリセット | ネットワーク関連ソフトのフック設定が解除される場合あり |
| netsh int ip reset | IP スタックのリセット | 手動で設定した IP・ルーティング設定などが初期化されることがある |
特に、サードパーティ製のセキュリティソフトや VPN を頻繁に入れ替えている環境では、これらのレイヤにフックを残したままアンインストールされていることもあり、その結果として TCPView のような監視ツールが正常に動作できなくなることがあります。
ETW（Event Tracing for Windows）セッションを確認・再開する
送受信カウンタが突然すべて空白になった場合、ETW の NT Kernel Logger セッションが停止している可能性も高いです。これは TCPView が依存している、カーネルレベルのネットワークトレース機構です。
ETWセッションの状態を確認する
管理者として PowerShell を起動し、次のコマンドを実行します。
logman query -ets
ETW セッション一覧が表示されるので、その中にある 「NT Kernel Logger」 の状態を確認します。
- Running（実行中）になっている → 原因は別にある可能性が高い
- Stopped になっている、もしくは表示されない → セッションが止まっている／壊れている可能性が高い
| 状態 | 意味 | TCPViewへの影響 |
|---|---|---|
| Running | NT Kernel Logger が正常稼働 | カウンタ未表示の場合は Winsock や TCPView 側を疑う |
| Stopped / Not Found | セッション停止・異常 | 送受信カウンタに必要なトレースが取得できない |
NT Kernel Logger を手動で再開する
「NT Kernel Logger」が停止している場合、次のコマンドで再開を試みます。
logman start "NT Kernel Logger" -p "Microsoft-Windows-Kernel-Network" 0xFFFFFFFF 0x5 -ets
これは、Microsoft-Windows-Kernel-Network プロバイダーからネットワーク関連のトレースを細かく取得するための設定です。実行後、再度 TCPView を開いてカウンタが動き出すか確認します。
- 再起動が難しいサーバー環境や長時間動かしている PC でも、このコマンドだけで復旧するケースが非常に多い
- もし別のモニタリングツールやログツールが NT Kernel Logger を強制停止していた場合も、このコマンドで再度有効化できます
なお、既に別のツールが同じセッションを使用している場合はエラーになることもあります。その場合は、どのツールが ETW を占有しているかを確認する必要があります。
代替ツール（CurrPortsなど）でOS側の問題かどうかを切り分ける
TCPView のカウンタが空白のとき、OS側のトレース機構が壊れているのか、TCPView単体の問題なのかを切り分けるのも重要です。ここで役立つのが、NirSoft の CurrPorts のような代替ツールです。
切り分けの考え方
TCPView と別系統の実装を持つツールで送受信バイト数が見えるかどうかを見ることで、原因の領域を絞り込めます。
- CurrPorts でも送受信バイトが表示されない → OS 側のトレース機構やネットワークスタックに問題がある可能性が高い
- CurrPorts では正常に表示される → TCPView のみの問題、もしくはバージョン依存のバグである可能性が高い
| ツール | 特徴 | カウンタ表示状況から分かること |
|---|---|---|
| TCPView | Sysinternals 製。プロセス名との関連付けが分かりやすい | ここだけ表示されない場合、TCPView の設定／バージョン／権限が怪しい |
| CurrPorts | 軽量で情報量が多い接続ビューア | ここでも表示されなければ、OS 側トレース機構の不調を疑う |
代替ツールでもカウンタが空白であれば、前述の netsh コマンドによるスタックリセット や ETW セッション再開 がより強く疑われます。
ファイアウォールやセキュリティソフトによる影響を考える
今回のケースでは、ファイアウォールの送信規則を大量に無効化していたタイミングで現象が発生しています。ここから見えてくるポイントは次のとおりです。
- Windows Defender ファイアウォールやサードパーティ製ファイアウォールは、ネットワークスタックにフックを挿入して動作している
- 短時間に大量のルール変更・無効化を繰り返すことで、トレースやフィルタリングの内部状態が不整合になることがある
- その結果として、通信自体は通るが「統計情報を拾う側」だけが機能しなくなることがある
確認しておきたいポイント
- Windows Defender ファイアウォールのサービスが 実行中 になっているか
- サードパーティ製セキュリティソフトを併用している場合は、一時的に停止して症状が変わるか
- 極端な「全ブロック」設定にしていないか（特にローカルネットワークやプリンタ周り）
ファイアウォール設定をシビアに詰めた環境では、「通信の安全性」と「可視化のしやすさ」をどうバランスさせるかが重要になります。次の章でその考え方を詳しく見ていきます。
TCPViewのおすすめ設定と恒久的な安定運用のコツ
単発の復旧だけでなく、「今後もカウンタが安定して動き続ける」状態を作ることも大事です。ここでは TCPView 側で取れる工夫をまとめます。
TCPViewのバージョンを最新にしておく
- Sysinternals Suite をまとめて最新版に更新する
- 古い TCPView では、Windows 11 上での細かな挙動に不整合が出る可能性があります
特に OS の大型アップデート後（例：22H2 → 23H2 など）は、ツール側も新しいバージョンにしておくとトラブルを避けやすくなります。
描画負荷と解決処理を抑えて安定動作を狙う
TCPView には、見やすさのためのオプションが色々と用意されていますが、これらが高頻度更新と組み合わさると負荷が高くなり、結果として表示が不安定になることもあります。おすすめは次の設定です。
- Options > Resolve Addresses のチェックを外す → IP アドレスからホスト名への逆引きを行わなくなるため、負荷軽減とレスポンス向上が見込めます。
- Options > Show Unconnected Endpoints のチェックを外す → 未接続のソケットを非表示にし、一覧をすっきりさせられます。
- Update Speed を「Normal」または「Low」にする → 更新頻度を落とすことで、カウンタ更新の安定性を高めます。
| 設定項目 | 推奨値 | 効果 |
|---|---|---|
| Resolve Addresses | オフ | 逆引き DNS を行わず軽量化、カウンタ更新が安定しやすくなる |
| Show Unconnected Endpoints | オフ | 一覧の情報量を適度に絞り、問題のある接続を見つけやすくする |
| Update Speed | Normal / Low | 更新頻度を抑えて描画負荷とトレース負荷を軽減 |
こうした微調整によって、TCPView がカウンタの更新に集中しやすい環境を整えられます。
プライバシー重視で通信を絞るときの注意と実践テクニック
「余計な通信はすべて遮断したい」という目的でファイアウォールを細かく設定していると、TCPView のようなツールは非常に役立ちます。一方で、やり方を誤ると「必要な通信まで止めてしまい、逆にトラブルの原因になる」ことも少なくありません。
いきなり全ブロックにしない
- まずは 観察モード で、TCPView や CurrPorts で「どのプロセスがどこに通信しているか」を把握する
- その上で、「不要」と判断できた通信先から段階的にブロックしていく
- 特に、LAN 内のプリンタ・NAS・ルーター との通信は、意図せず止めると印刷やファイル共有で困る原因になります
意外と通信するプロセスの例
- プリンタドライバ（印刷待ちのスプーラやステータス取得で想像以上に通信することがある）
- 一部の Web サイト（JavaScript で多数のサードパーティにアクセスする）
- クラウド連携ソフト（バックグラウンドで頻繁に通信する）
TCPView の送受信カウンタが正常に機能している状態なら、こうしたプロセスごとの通信量を見ながら、「どれくらい通信しているのか」「どのドメインにどの程度の頻度でアクセスしているのか」をチェックし、それに応じてルールをチューニングしていくのが理想です。
ここまでやっても直らない場合の追加チェックポイント
ここまでの対処を行ってもなお、TCPView のカウンタが完全に空白のまま…という場合、より広い視点での OS 側トラブルを疑う必要が出てきます。
システムファイルの整合性チェック
Windows のシステムファイルに破損があると、ネットワークトレースに関連するコンポーネントが正常に動かないことがあります。以下のコマンドで整合性をチェックします。
- 管理者としてコマンドプロンプトを起動
- 次のコマンドを順に実行
sfc /scannow
必要に応じて DISM を併用することもあります。
DISM /Online /Cleanup-Image /RestoreHealth
これにより、システムファイルの破損や不整合が自動的に修復される場合があります。修復が行われた場合は、再起動後に TCPView の挙動を再確認します。
新規ユーザープロファイルでの再現テスト
ユーザープロファイル固有の設定やレジストリエントリが原因になっている場合、新規ユーザーアカウントを作成して同じ環境で TCPView を使ってみることで切り分けができます。
- 新しいローカルユーザーまたは Microsoft アカウントを作成
- そのユーザーでログインし、TCPView を管理者として実行
- 送受信カウンタが正常に動作するか確認
新規ユーザーで問題が出ない場合は、元のユーザープロファイル側の設定をより詳細に確認する必要があります。
再発防止のための運用チェックリスト
最後に、TCPView の送受信パケット／バイト数が空白になるトラブルを避けるために、日頃から意識しておきたいポイントをチェックリストとしてまとめます。
| 項目 | 内容 | ポイント |
|---|---|---|
| 管理者権限での実行 | TCPView を常に「管理者として実行」 | ショートカットの互換性設定で固定しておく |
| ツールのバージョン | Sysinternals Suite をこまめに更新 | OS アップデート後は特に要確認 |
| 描画負荷の調整 | Resolve Addresses / Show Unconnected Endpoints をオフ | Update Speed も無理に高速にしない |
| ファイアウォール運用 | 段階的にブロック／許可を設定 | LAN 内機器や必須通信を誤って止めない |
| トラブル時の基本手順 | 再起動 → netsh リセット → ETW 再開 → 代替ツールで切り分け | 順番を決めておくと再現時にも落ち着いて対処できる |
まとめ：TCPViewの送受信カウンタが空白になったときにやるべきこと
TCPView の送受信パケット・バイト数が突然すべて空白になってしまう現象は、一見すると謎めいていますが、「通信そのもの」ではなく「通信を観察するための機構」が壊れている と考えると整理しやすくなります。
実際の対処としては、次のステップで落ち着いて原因を絞り込むのがおすすめです。
- TCPView を管理者として実行し、PC 再起動直後にも試してみる
- netsh winsock reset / netsh int ip reset を実行し、Winsock と IP スタックをリセットする
- PowerShell から logman query -ets で NT Kernel Logger の状態を確認し、必要に応じて logman start “NT Kernel Logger” -p “Microsoft-Windows-Kernel-Network” 0xFFFFFFFF 0x5 -ets で再開する
- CurrPorts などの代替ツールで OS 側の問題か TCPView の問題かを切り分ける
- それでも改善しない場合は、sfc /scannow や DISM、新規ユーザーでの再現テストなど、より広い観点で OS の整合性を確認する
そして、問題が解決したら、ファイアウォールのルールや TCPView の設定を見直し、プライバシー保護と通信可視化のバランスを取りながら運用していくことが大切です。TCPView のカウンタがきちんと動いていれば、「どのアプリがどこに、どれくらいの量のデータを送っているのか」を細かく観察でき、安心して Windows 11 を使いこなせるようになります。
コメント