Chrome 起動時に数分フリーズする謎現象を UIforETW で徹底解剖し、Chromium のバグを突き止めた話

はじめに

ある日から、Windows で Chrome を起動すると必ず 1〜2 分間フリーズする、という不可解な現象に悩まされていました。

待てば使えるものの、エンジニアとしてこの「待つ」という行為が許しがたく、根本原因の特定に乗り出すことにしました。

この記事では、UIforETW (Event Tracing for Windows) を用いたパフォーマンス分析によって、最終的に Chrome 本体のバグを突き止めるまでの全プロセスを記録します。

調査方針：パフォーマンス分析ツールの導入

• Chrome を最新版に更新 → 改善せず
• 再インストール → 改善せず
• 閲覧データやキャッシュを全削除 → 改善せず

基本的なトラブルシューティングでは埒が明かないため、より低レイヤーでの挙動を可視化する必要がありました。そこで、Windows のパフォーマンス分析ツールである UIforETW を導入し、Chrome がフリーズしている間に CPU が何を処理しているのかを直接観察することにしました。

UIforETW は、Windows に組み込まれた ETW (Event Tracing for Windows) のための GUI ラッパーで、システム全体の詳細な動作ログ（トレース）をキャプチャし、WPA (Windows Performance Analyzer) で分析可能な.etlファイルを生成してくれます。

早速、Gemini に相談しながら進めることにしました。

解析ログ 1：犯人のプロセスを特定する

指示通りにトレースを実行し、生成された.etlファイルを分析しました。

この段階で判明した事実は以下の通りです。

• CPU 占有プロセスの特定: chrome.exe (20460) が CPU リソースの大半を消費している。
• 主犯スレッドの特定: CrBrowserMain というスレッドが CPU サンプル数の大部分（60,839）を占めている。

CrBrowserMainは Chrome のメインスレッドであり、UI の描画や拡張機能の初期化など、ブラウザの根幹を担っています。フリーズの原因はこのスレッドにあることが確定しました。しかし、このスレッドが具体的に「何に」時間を費やしているのかは、この時点では不明です。

解析ログ 2：シンボルの壁と突破口

CrBrowserMainスレッドのコールスタックを深掘りしても、表示されるのはchrome.dll!<SYMBOLS DISABLED>ばかり。これでは具体的な関数名がわからず、手詰まりです。

これは、分析ツールが Chrome のデバッグシンボル（.pdbファイル）を見つけられていないことが原因です。シンボルファイルは、機械語のメモリアドレスと、人間が読める関数名を対応付ける「地図」の役割を果たします。この地図がなければ、詳細な分析は不可能です。

解決策は、シンボルサーバーのパスをシステムに設定し、分析ツールに必要なシンボルファイルを自動でダウンロードさせることです。

ここで提示されたパスは Microsoft と Google の汎用的なものでしたが、より確実な Chromium 専用のシンボルサーバーを指定する必要がありました。最終的に、以下の値を環境変数 _NT_SYMBOL_PATH に設定しました。

1srv*C:\symbols\*https://chromium-browser-symsrv.commondatastorage.googleapis.com

この設定後、再度.etlファイルを読み込むと、これまで!と表示されていた部分が具体的な関数名に解決されました。最大の壁を突破した瞬間です。

解析ログ 3：フレームグラフから真犯人を特定

シンボルが解決された状態でフレームグラフを再確認すると、CPU 時間を消費している関数が一目瞭然となりました。

特に CPU 使用率が高かったのは、以下の関数です。

• chrome.dll!views::View::ReorderChildLayers (count: 36302)
• chrome.dll!views::View::ReorderChildView (count: 56298)

これらの関数名から、以下の事実が推測できます。

• views::View: Chrome の UI 要素（ボタン、タブ等）の描画に関する処理であることを示唆しています。
• ReorderChildView / ReorderChildLayers: UI 要素の順序や階層を再計算・再描画していることを意味します。

コールスタックにはTabStripやTabGroupBarといった文字列も散見され、これらを総合すると、**「Chrome が起動時にタブ、特にタブグループの UI をレンダリング・再配置するために膨大な計算を行っている」**という仮説が浮かび上がりました。

原因の特定と検証

仮説は「複雑なタブグループの構造が、起動時の UI レンダリング処理に過負荷を与えている」というものです。

これを検証するため、最も疑わしいタブグループの同期機能を無効にしてみることにしました。

1. Chrome の設定 chrome://settings/syncSetup にアクセス
2. 「同期する内容の管理」 → 「同期をカスタマイズ」
3. 「タブグループ」 のスイッチをオフにする

結果は劇的でした。あれほど頑固だったフリーズが嘘のように消え、Chrome は瞬時に起動するようになりました。

根本原因の解明：見えざる「ゴーストレンダリング」

しかし、ここで新たな疑問が生まれます。私の起動設定は「新しいタブページを開く」であり、実際にフリーズ後も空のページが表示されるだけでした。なぜ何もレンダリングしないはずなのに、タブのレンダリング処理でフリーズするのでしょうか？

つまり、フリーズの直接原因は、**別デバイスから同期された過度に複雑なタブグループの状態を、バックグラウンドで処理しようとした結果発生した、高負荷な「ゴーストレンダリング計算」**だったのです。

念のため、全ての拡張機能を無効にした状態でも現象が再現することを確認し、この問題が拡張機能ではなく Chrome 本体に起因するバグであると結論付けました。

まとめとバグ報告

当初は原因不明だった Chrome のフリーズ現象も、UIforETW を用いた体系的なパフォーマンス分析によって、最終的に「タブグループの同期機能に起因する、バックグラウンドでの高負荷な UI 計算処理」が根本原因であると突き止めることができました。

今回の調査結果は、Chromium の公式 Issue Tracker にバグとして報告済みです。

• Link to the issue: https://issues.chromium.org/issues/431111162

同様の問題に直面している方、あるいは低レイヤーでのパフォーマンス分析に興味がある方の参考になれば幸いです。