Windowsでゲームやブラウザを使っている最中、操作していたウィンドウから突然フォーカスが外れるようになった。
ほんの一瞬のことだが、ゲームなら入力が途切れ、ブラウザなら文字入力が止まる。エラー画面が出るわけでもない。それでも繰り返されると、「また起きるかもしれない」という警戒が残り、集中そのものが削られていく。
今回、私の環境で原因を追ったところ、直接フォーカスを取得していたのはWSLgが起動した「msrdc.exe / RemoteApp」だった。そして、その経路を動かすきっかけになっていたのがDocker Desktopだった。
最初は、起動中のゲームやアプリを疑った
不具合が目立ったのはゲーム中だった。そこで最初は、同時に起動していた別のゲームや常駐アプリが前面へ出ているのではないかと考えた。
候補になりそうなアプリを一つずつ終了した。しかし現象は止まらず、ゲームをしていないブラウザの操作中にも発生した。
ここで「特定のゲームの不具合」という見方を捨てられた。困った現象が起きた場面と、本当の原因がある場所は、必ずしも同じではない。
PowerShellのログで、割り込んだプロセスを捕まえる
目で追うだけでは、どのウィンドウが割り込んだのか分からない。そこでPowerShellを使い、前面ウィンドウが切り替わった瞬間を記録した。
ログには、操作中のアプリの直後に次の情報が残っていた。
- プロセス：
msrdc.exe - ウィンドウ名：
RemoteApp
さらに親プロセスとコマンドラインを調べると、親はwslhost.exeで、WSLDVC_PACKAGEやwslg.rdpという文字列も確認できた。
WSLgは、LinuxのGUIアプリをWindows上で扱うための仕組みで、RDP技術を使ってLinux側の画面をWindowsへ統合している。見覚えのないRemoteAppは、外部から接続された画面ではなく、WSLのGUI統合に使われていたものだった。
Docker Desktopを止めると消え、起動すると再発した
ただし、WSLgが関係していると分かっただけでは十分ではない。なぜ、LinuxのGUIアプリを使っていないのに動いているのかが残る。
wsl --shutdownを実行しても、しばらくするとWSLとmsrdc.exeが再び起動した。そこでDocker Desktopを完全に終了し、条件を変えて確認した。
| 条件 | 結果 |
|---|---|
| Docker Desktop停止 | フォーカス喪失は発生しない |
| Docker Desktop起動 | フォーカス喪失が再発 |
| Docker Desktop再停止 | 再び発生しなくなる |
Docker DesktopはWSL 2をバックエンドとして利用できる。私の環境では、Docker Desktopの起動をきっかけにWSLが動き、その中のWSLgがRemoteAppを起動し、msrdc.exeがフォーカスを奪う経路になっていた。
重要なのは、「Docker Desktopが直接フォーカスを奪った」と一段で決めつけないことだ。
Docker DesktopがWSLを起動する
→ WSLgがRemoteAppを起動する
→ msrdc.exeがフォーカスを取得する
原因をこの粒度まで分けたことで、Dockerを使うこと自体を諦めずに済む可能性が見えてきた。
LinuxのGUIを使わないなら、WSLgだけを無効化できる
Microsoftの公式情報では、ユーザーフォルダにある.wslconfigへ次の設定を加えることで、WSLのGUIアプリ対応を無効化できる。
[wsl2]
guiApplications=false設定後は、作業中のWSLやコンテナを安全に終了したうえで、次を実行してWSLを再起動する。
wsl --shutdown既存の.wslconfigがある場合は上書きせず、現在の設定へ追記・統合する。LinuxのGUIアプリを使っている場合は、その機能も使えなくなるため、誰にでも適する方法ではない。
私の場合も、これは恒久対策の候補であり、設定後にはDocker Desktopを起動した状態でmsrdc.exeが立ち上がらないか、フォーカス喪失が再発しないかを確認する必要がある。
「犯人らしいもの」より「条件で再現できること」を信じる
今回もっとも大きかったのは、最初の推測が外れたことではない。推測と観測を分けられたことだった。
ゲーム中に起きたからゲームを疑う。RemoteAppと表示されたから、リモート接続アプリを疑う。Dockerを止めたら直ったから、Dockerそのものが悪いと考える。どれも自然だが、その段階で結論にすると、本当の経路には届かない。
一つずつアプリを止める。前面ウィンドウを記録する。親プロセスをたどる。Dockerの停止・起動・再停止で再現する。この順番によって、「なんとなく怪しい」が「同じ条件なら同じ結果になる」へ変わった。
小さな不具合ほど、我慢して使い続けやすい。しかし、集中を何度も中断する問題は、発生時間の短さだけでは測れない。原因の見えない割り込みが消耗させるのは、数秒ではなく、その後の注意力だからだ。
だからこそ、違和感を気のせいにせず、ログに変える価値がある。記録できれば、見えなかった問題にも輪郭が生まれる。そして、機能を丸ごと捨てるのではなく、必要な部分だけを残す対策を考えられるようになる。
