Arm版WindowsでVivaldiが終了しきれず次回起動できなかった件（ATOKが原因・解消済み）
#108
はじめに
Arm版WindowsでVivaldiを閉じると、本体のプロセスが1つだけ残って次に起動できなくなる症状がずっと出ていた。9月27日に調べてATOKが原因というところまでは分かったが、自分で直せる話ではなかったので回避策でしのいでいました。
そのまま問い合わせもせず放置していたら、10月17日のアップデートで直っていた。せっかく調べたので、供養として記録を残しておきます。
サマリ
Vivaldiの終了時にATOKのヘルパー LMASVR.EXE が起動し、Vivaldi本体がその応答を待ったまま止まっていたのが原因だった。Microsoft IMEでは起きなかったので、ATOKとの組み合わせの問題でした。
止まったプロセスは taskkill /F でも消せず、消すにはサインアウトか再起動しかありませんでした。
| 項目 | 内容 |
|---|---|
| OS | Windows on Arm |
| ブラウザ | Vivaldi（ARM64版） |
| IME | ATOK Tech Ver.36（Arm用アップデートモジュール適用済み） |
症状
Vivaldiを起動すると「Please wait for Vivaldi to close.」と「Force startup」ボタンだけの小さいウィンドウが出て、そこから先に進まなかった。タスクマネージャーを見ると、前回閉じたはずの vivaldi.exe が1つ残っていた。
つまり、前回のVivaldiが閉じきっていないせいで新しいVivaldiが立ち上がれない状態です。なので、まずはこの残ったプロセスを消すところから始めました。
調べたこと
強制終了できなかった
taskkill /IM vivaldi.exe /F /T子プロセスは消えたが、1つだけ「理由: 実行中のタスクのインスタンスがありません。」と言われて残った。タスクマネージャーでは「実行中」と出ているのに、taskkill からは見えていなかった。
/F で消せないので、普通の止まり方ではない。それでも念のため、よくある原因から先につぶすことにしました。
よくある原因は関係なかった
Vivaldiが閉じきらないときは拡張機能が原因のことが多いので、全部無効にしてみたが変わらなかった。Arm機なのでx64版をエミュレーションで動かしている可能性も確かめたが、入っていたのはちゃんとARM64版だった。
どちらも外れだったので、残っているプロセスそのものを調べることにしました。
残っていたのは本体だった
Chromium系のブラウザはタブや拡張機能ごとに子プロセスを分けているので、まず残っているのがどれかを確かめた。
Get-CimInstance Win32_Process -Filter "ProcessId=4772" | Select-Object CommandLine子プロセスなら --type=renderer のような引数が付くが、これには --type= が無かった。なので残っていたのはVivaldi本体（メインプロセス）で、メモリも約226MB握ったままだった。
本体が何かに引っかかっているなら、何を待っているのかを見れば分かる。そこで待機チェーンを見てみました。
LMASVR.exe を待っていた
タスクマネージャーの「詳細」タブで残ったプロセスを右クリックして「待機チェーンの分析」を開くと、LMASVR.exe を待っていると出た。ちなみにここで Stop-Process -Id 4772 -Force も試したが、「プロセスが見つかりません」だった。
LMASVR.exe という名前に見覚えがなかったので、次はこれが何者かを調べた。
LMASVR.exe はATOKのものだった
Get-Process LMASVR | Select-Object Id, Path, Company, Description場所は C:\Program Files\JustSystems\ATOK36_X64\LMASVR.EXE で、発行元はジャストシステム、説明は「ATOKヘルパーサーバー」だった。署名も Valid なので怪しいものではありません。
普段は動いておらず、Vivaldiを閉じようとしたときにだけ現れていた。それなら LMASVR.exe を止めれば待ちがほどけるはずなので、止めてみました。
LMASVR.exe を止めても無駄だった
LMASVR.exe 自体はすんなり強制終了できた。でも vivaldi.exe は残ったままで、待ちはほどけなかった。
Get-CimInstance Win32_Process -Filter "ProcessId=6084" | Select-Object ProcessId, ThreadCount, HandleCount, ParentProcessId残ったプロセスを見ると ThreadCount = 1 だった。抜け殻ではなく、スレッドが1本だけカーネル内の待ちから抜けられなくなっている状態だった。
ここまででATOKがかなり怪しくなったので、最後にIMEを替えて比べてみました。
Microsoft IMEでは起きなかった
Vivaldiで使うIMEをMicrosoft IMEにしたら、何度閉じても再現しなかった。ジャストシステムが出しているArm用のアップデートモジュールは当てていたが、ATOKだと相変わらず起きた。
これで原因はATOKで確定しました。
結論
流れは冒頭の図のとおり。ATOKのようなIMEは入力先のアプリの中に入り込んで動いていて、Vivaldiの終了時には LMASVR.EXE を呼んで後始末をしようとする。この後始末が返ってこないので、Vivaldi本体は止まったままになっていたわけです。
しかもWindowsから見ると、このプロセスはもう終了処理に入った後の扱いになっていた。終了命令を受け付ける段階を過ぎているので、taskkill は「インスタンスがありません」と答え、/F を付けても消せなかった。それなのに実体は残っているので、次に起動したVivaldiが「前のがまだ閉じていない」と判断して止まる、という流れでした。
試したことをまとめるとこうなります。
| 対応 | 結果 | メモ |
|---|---|---|
| 拡張機能をすべて無効化 | 再現 | 拡張機能は無関係 |
| ARM64版かを確認 | ARM64版 | エミュレーションは無関係 |
taskkill /F /T | 終了できない | 「インスタンスがありません」 |
Stop-Process -Force | 終了できない | 「プロセスが見つかりません」 |
| LMASVR.EXE を強制終了 | 残ったまま | LMASVR 自体は終了できる |
| ATOK Arm用アップデート適用 | 再現 | 適用済みでも起きる |
| Microsoft IMEで使う | 再現しない | 原因はATOKと確定 |
原因は分かったが、ATOKの中の話でこちらでは直せなかったので、回避策で使い続けることにしました。
結末
Windowsにはアプリのウィンドウごとに IME を覚えておく設定があるので、VivaldiだけMicrosoft IMEにしていた。
- 設定 →「時刻と言語」→「入力」→「キーボードの詳細設定」
- 「アプリ ウィンドウごとに異なる入力方式を設定する」をオンにする
- Vivaldiを開いた状態で
Win＋Spaceを押して、Microsoft IMEに切り替える
ただ、Vivaldi上で一度でもATOKに切り替えると、再発するため完全な解決状態ではなかった。
ジャストシステムには問い合わせないまま、しばらく放置していた。そうしたら10月17日のアップデートの後、VivaldiでATOKを使って閉じても vivaldi.exe が残らなくなっていました。
というわけで、この件はもう起きません。
おわりに
この件自体はもう起きないはずだが、強制終了できないプロセスが残る系のトラブルには同じ調べ方が使えます。