突然MacBook Proがフリーズし、カーソルもキーボードも反応しなくなる症状が発生しました。SafariやChrome、外部モニター、macOSまで疑いながら原因を調査した記録です。
MacBook Proを使っている最中、突然マウスカーソルが止まり、キーボードも反応しなくなるようになりました。
数秒から20秒ほど待つと復帰することもあれば、そのままログイン画面へ戻されることもあります。
画面は完全に固まっているのに、再生していた音楽だけは流れ続けていることもありました。
最初は、SafariやChromeなどのアプリが一時的に重くなっているだけだと思っていました。しかし、ブラウザを変更しても、外部モニターを外しても、macOSを再インストールしても症状は改善しません。
最終的にはMacBook Pro本体の故障まで疑いましたが、クラッシュレポートを確認すると、毎回のように同じキーワードが記録されていました。
- WindowServer
- WATCHDOG
- HIDEvents
この記事では、MacBook Proが突然フリーズするようになってから、原因の方向性を絞り込むまでに行った調査をまとめます。
この記事では、原因を特定するまでの調査内容を紹介します。実際に行った対策と改善までの経緯は、解決編で詳しく紹介しています。
- 発生していたフリーズの症状
- 試した切り分け方法
- WindowServer・WATCHDOG・HIDEventsとは
- 原因が入力デバイス周辺に絞られるまで
MacBook Proで発生していたフリーズの症状
発生していたのは、特定のアプリだけが固まる一般的なフリーズとは少し違う症状でした。
主な症状は次のとおりです。
- マウスカーソルが突然動かなくなる
- キーボード入力を受け付けなくなる
- 画面全体が数秒から20秒ほど操作不能になる
- 音楽や音声だけは再生され続けることがある
- 復帰後、停止中に動かしたカーソルの軌跡が一気に反映される
- そのままログイン画面へ戻されることがある
特に気になったのが、画面と入力操作が止まっているのに、音楽はそのまま再生されることでした。
Mac全体の処理が完全に停止しているのではなく、画面表示や入力操作に関係する部分だけが応答しなくなっているようにも見えます。
また、数秒後に復帰した際、フリーズ中に動かしていたマウスカーソルがまとめて動くこともありました。
入力そのものが失われているというより、入力された情報を画面へ反映する処理が一時的に滞っているような、不思議な挙動でした。
使用していたMacと周辺機器
検証時の環境は次のとおりです。
- MacBook Pro 14インチ
- M2 Pro
- メモリ16GB
- SSD 1TB
- macOS Sequoia
- Dell U2723QX
- Kensington SlimBlade Pro
- Apple Magic Trackpad
- BetterTouchTool
- Karabiner-Elements
- KensingtonWorks
MacBook Proは、ブログ執筆やWebブラウジング、画像編集などに使用していました。
ブラウザで多数のタブを開くことはありますが、フリーズは負荷の高い作業中だけに起きていたわけではありません。
比較的軽い作業しかしていないときや、音楽を再生しているだけの状態でも発生しました。
そのため、単純に「処理が重すぎて固まった」とは考えにくい状況でした。
最初にSafariを疑った
普段はSafariをメインブラウザとして使用しています。
フリーズはWebブラウジング中に発生することが多かったため、最初はSafariの不具合や、開いているタブの多さが原因ではないかと考えました。
SafariはmacOSの画面表示やシステム機能とも深く関係しているため、Safariが何らかのきっかけになっていても不思議ではありません。
そこで、Safariの使用を減らし、Chromeへ切り替えて様子を見ました。
しかし、Chromeを使用している最中にも同じようにカーソルが動かなくなり、画面全体がフリーズしました。
反対に、Chromeを終了してSafariだけを使用しているときにも発生します。
さらに、ブラウザをほとんど操作していない状態でも症状が出ました。
この結果から、ブラウザそのものが直接の原因である可能性は低いと判断しました。
外部モニターを取り外して検証
次に疑ったのが、外部モニターです。
Dellの27インチ4Kモニター「U2723QX」をMacBook Proへ接続して使用していました。
画面表示が止まる症状だったため、次のような可能性を考えました。
- 4K出力による負荷
- 外部モニターとの相性
- 接続ケーブルや接続方式の問題
- HDRや解像度設定の影響
- macOSと外部ディスプレイ間の不具合
そこで、外部モニターを取り外し、MacBook Proの内蔵ディスプレイだけで使用してみました。
しかし、内蔵ディスプレイのみの状態でもフリーズは再発しました。
外部モニターを接続しているときに症状が出ることはありましたが、外しても発生するため、少なくとも、外部モニターだけが原因とは考えにくいと判断しました。
メモリ不足や高負荷も確認
Macがフリーズするときに、まず考えられる原因の一つがメモリ不足です。
使用していたMacBook Proのメモリは16GBです。
SafariやChromeで多数のタブを開いていると、メモリ使用量が増え、スワップが発生することもあります。
そこで、アクティビティモニタを開き、フリーズが発生しそうな状況で次の項目を確認しました。
- メモリ使用量
- メモリプレッシャー
- スワップ使用量
- CPU使用率
- 異常に負荷の高いプロセス
しかし、メモリプレッシャーは極端に高い状態ではなく、CPU使用率にも明らかな異常は見当たりませんでした。
また、重いアプリを終了している状態でも同じフリーズが発生します。
もしメモリ不足が主な原因であれば、使用するアプリや作業量を減らすことで症状が改善するはずです。
実際には作業負荷との関連性が見えなかったため、メモリ不足が主な原因とは考えにくいと判断しました。
SSDの異常を確認
次に、内蔵SSDの異常も疑いました。
ストレージに問題があると、データの読み書きが止まり、アプリやmacOSが応答しなくなることがあります。
ディスクユーティリティを起動し、内蔵ストレージに対して「First Aid」を実行しました。
しかし、First Aidを実行しましたが、ストレージに異常は検出されませんでした。
空き容量にも余裕があり、容量不足が原因とも考えにくい状況でした。
フリーズ以外には、ファイルの読み書きに失敗する、データが破損する、Macの起動に異常に時間がかかるといった症状もありませんでした。
このため、SSDが直接の原因である可能性も低いと判断しました。
macOSを再インストールしても改善しなかった
ブラウザ、外部モニター、メモリ、SSDを確認しても原因が見つからなかったため、macOS自体の不具合も疑いました。
macOSのシステムファイルが破損していたり、アップデートの際に何らかの問題が起きていたりする可能性もあります。
そこで、macOSの再インストールを実施しました。
再インストールによってシステム側の問題が修復されれば、フリーズも改善するのではないかと考えたためです。
ところが、再インストール後も同じ症状が発生しました。
カーソルとキーボードが反応しなくなり、しばらく待つと復帰する、またはログイン画面へ戻されるという挙動に変化はありません。
ここまで試して改善しないとなると、MacBook Pro本体のハードウェア故障も考えざるを得ません。
ただし、音声は再生され続けることや、一定時間後に操作が復帰することを考えると、完全なハードウェア故障だけでは説明しにくい症状にも思えました。
ログイン画面へ戻された後のクラッシュレポート
フリーズから復帰せずログイン画面へ戻された場合、macOSにはクラッシュレポートが残っていました。
それまでは内容を詳しく確認していませんでしたが、原因を特定する手がかりになるかもしれないと思い、レポートを読み返してみました。
すると、複数回のクラッシュレポートに、ほぼ同じ内容が記録されていました。
Termination Reason:
Namespace WATCHDOG
monitoring timed out for service:
WindowServer
unresponsive dispatch queue(s):
com.apple.WindowServer.HIDEvents
この記録から、WindowServerが一定時間応答せず、監視処理がタイムアウトしていたことが分かりました。
さらに、WATCHDOGとHIDEventsという見慣れない単語も記録されていました。
SafariやChrome、外部モニターばかりを疑っていましたが、クラッシュレポートは別の方向を示しているように見えます。
ここから、WindowServer、WATCHDOG、HIDEventsが何を意味しているのか、一つずつ調べることにしました。
WindowServerとは?
まず気になったのが、クラッシュレポートに毎回記録されていた「WindowServer」というプロセスです。
調べてみると、WindowServerはmacOSで画面表示を管理する非常に重要なシステムプロセスでした。
例えば、
- デスクトップの表示
- アプリのウィンドウ表示
- マウスカーソルの描画
- 画面の切り替え
- 外部ディスプレイへの出力
など、私たちが普段見ている画面のほとんどに関わっています。
例えるなら、Macの「画面表示の司令塔」のような存在です。
WindowServerが正常に動かなくなると、画面が更新されなくなったり、マウスカーソルが止まったり、画面上の操作が反映されなくなったりする可能性があります。
実際に発生していた症状を振り返ると、
- カーソルが止まる
- キーボードが反応しない
- 数秒後にまとめてカーソルが動く
という挙動は、WindowServerに問題が起きている可能性と一致しているように思えました。
しかし、ここで一つ疑問が残ります。
「なぜWindowServerが止まってしまうのか?」
WindowServerそのものに問題があるのか、それとも別の何かが影響しているのか。
その答えを探すため、次に「WATCHDOG」という記録について調べてみました。
WATCHDOGとは?
クラッシュレポートには、次のような記録がありました。
Termination Reason:
Namespace WATCHDOG
最初は「WATCHDOG」という言葉の意味も分かりませんでしたが、調べてみると、macOSにはシステムの状態を監視する仕組みがあり、一定時間応答しなくなったプロセスを強制終了させることがあるようです。
つまり、このログから分かったのは、
「WindowServerが異常終了した」
というより、
「WindowServerが一定時間応答しなかったため、macOSの監視機構によって強制終了された」
という状況だったということです。
この違いは、とても重要でした。
もしWindowServer周辺のシステムファイルに問題があるのであれば、macOSの再インストールで改善する可能性もあります。
しかし、実際には再インストール後も症状は変わりませんでした。
ということは、WindowServerを止めてしまう別の原因があるのではないか。
そう考えるようになりました。
HIDEventsとは?
もう一つ気になったのが、この記録です。
unresponsive dispatch queue(s):
com.apple.WindowServer.HIDEvents
ここで出てくる「HID」は、
Human Interface Device
の略です。
少し難しく聞こえますが、簡単に言えば、人がMacを操作するための機器を扱う仕組みです。
例えば、
- マウス
- キーボード
- トラックパッド
- ペンタブレット
- ゲームコントローラー
などがHIDに含まれます。
つまり、このログは、
入力デバイスに関係する処理で、WindowServerが正常に応答できなくなっていた可能性
を示しているように思えました。
もちろん、このログだけで原因を断定することはできません。
しかし、それまで行ってきた切り分けを振り返ると、少なくとも、ここまでの検証では次の可能性は低いと考えました。
- Safariではなかった
- Chromeでもなかった
- 外部モニターでもなかった
- メモリ不足でもなかった
- SSDでもなかった
- macOSを再インストールしても改善しなかった
という結果になっています。
そう考えると、今まであまり疑っていなかった「入力デバイス」や、その周辺ソフトウェアへ目を向ける必要があるのではないかと思うようになりました。
少しずつ原因が絞られてきた
ここまで調査を進めてきて、一つ、かなり可能性が高いと考えられることがありました。
それは、
毎回ほぼ同じクラッシュレポートが残っている
ということです。
つまり、偶然ではなく、同じ原因によってフリーズが発生している可能性が高いと考えられました。
また、画面や入力操作だけが止まり、音楽だけは再生され続けることがあるという症状も、WindowServer周辺で問題が起きているという考え方と矛盾しません。
もちろん、この時点ではまだ決定的な原因は分かっていません。
それでも、
「画面表示そのもの」
ではなく、
「入力デバイスや、その周辺ソフトウェア」
へ調査対象を絞り込めたことは、大きな前進でした。
まとめ
今回の調査では、
- Safari
- Chrome
- 外部モニター
- メモリ
- SSD
- macOS
など、思いつく限りの原因を一つずつ切り分けていきました。
その結果、クラッシュレポートには毎回、
- WindowServer
- WATCHDOG
- HIDEvents
という共通点があることが分かりました。
この時点ではまだ原因を断定することはできません。
しかし、「入力デバイスや、その周辺ソフトウェアに問題があるかもしれない」というところまでは、かなり絞り込めました。
では、実際に何を見直したところ、フリーズは改善したのでしょうか。
次回の【解決編】では、入力デバイス関連のソフトウェアを見直すことになった経緯と、実際に行った対策、その後の変化について詳しく紹介します。
実際に行った対策と、その後の経過は解決編で紹介しています。


コメント