2023年3月中旬ごろのWindowsセキュリティ更新と、Chrome/Edge（Chromium系）の自動更新が重なった時期から、Blazor WebAssembly（.NET 6/7）をVisual Studioでデバッグ起動すると「起動直後にクラッシュする」「ブレークポイントがあるだけで落ちる」といった不具合が報告されました。この記事では、症状の特徴・原因の考え方・すぐ効く回避策・恒久対応まで、現場で迷わないように整理します。
Windows更新後に起きるBlazor WebAssemblyデバッグクラッシュとは
問題が表面化したのは、Windowsの更新（特にセキュリティ更新）後に、ブラウザー側も自動更新されるタイミングが重なったケースです。Blazor WebAssemblyプロジェクトをVisual Studioから「デバッグの開始」で起動すると、ブラウザーが立ち上がるもののすぐ終了したり、Visual Studio側のデバッグアダプターが落ちてデバッグセッションが終わったりします。
ポイントは、アプリ自体が壊れているというより、Blazor WebAssemblyの「ブラウザー連携デバッグ」部分でクラッシュが起きる点です。そのため同じプロジェクトでも、実行方法を変えると挙動が変わります。
症状の特徴
この事象は、再現条件に特徴があり、切り分けがしやすいタイプです。よくある症状をまとめると次の通りです。
- 「デバッグなしで開始」だと動くのに、「デバッグ開始」だと起動直後に落ちる
- 事前にブレークポイントが1つでもあると落ちる
- 起動後に追加したブレークポイントは、一時的に効くことがある（ただし再読み込みで再発しやすい）
- Chrome / Edge（どちらもChromium系）で発生しやすい
- Visual Studio側で「JavaScript debug adapter has exited with code 0xffffffff」などが出ることがある
| 観察できる症状 | 意味合い | まず試すべきこと |
|---|---|---|
| デバッグなしだと正常、デバッグ開始だとクラッシュ | アプリ本体よりも「デバッグ連携」が怪しい | 全ブレークポイント無効化→起動後に再設定 |
| 事前ブレークポイントがあると100%落ちる | 起動直後のブレークポイント同期がトリガーになっている可能性 | ブレークポイントを削除/無効化して再現確認 |
| Chrome/Edgeだけ不安定、別ブラウザーでは挙動が違う | Chromium側の回帰やDevTools周辺の挙動差の疑い | Chrome Beta/Edge Betaで切り分け、ブラウザー更新 |
| VSに debug adapter の終了、DevToolsProxy周辺の例外 | Visual Studioとブラウザー間の橋渡し部分が例外で落ちている | VS/ブラウザー双方を更新、回避策で作業継続 |
代表的なエラーメッセージ例
環境やタイミングで表示は変わりますが、当時よく見られたのは次のようなログ・例外です。
DevToolsProxy周辺（Blazor側デバッグ連携）
Microsoft.WebAssembly.Diagnostics.DevToolsProxy ...
System.ArgumentOutOfRangeException: Index was out of rangeVisual Studio側（JavaScriptデバッグアダプター）
JavaScript debug adapter has exited with code 0xffffffffこの手のメッセージが出ていて、かつ「ブレークポイントを事前に置くと落ちる」という再現性があるなら、今回の記事で扱う事象である可能性が高いです。
なぜ「デバッグなしで開始」なら動くのか
Blazor WebAssemblyをVisual Studioでデバッグする場合、単にアプリを起動するだけではなく、ブラウザーのDevTools（開発者ツール）相当の仕組みと連携して、WebAssemblyのデバッグ情報をやり取りします。Visual Studioはブラウザーにアタッチし、ブレークポイント設定やステップ実行のために追加の通信・プロセスを動かします。
一方で「デバッグなしで開始」は、このデバッグ連携レイヤーが動かない（もしくは最小限になる）ため、アプリ自体は普通に動く、という差が出ます。
原因の考え方
当時の結論として整理すると、現象はBlazor側のデバッグ連携（DevToolsProxyなど）と、Chromium（Chrome/Edge）側の不具合（回帰）が噛み合って起きたもの、と説明されることが多いです。
ざっくり言うと、Visual Studioが起動時に「事前ブレークポイント」をまとめて同期しようとしたタイミングで、ブラウザーから返ってくる情報が想定とズレる（または順序が崩れる）などが起き、DevToolsProxy側が例外で落ちる、という流れです。
| 登場人物 | 役割 | 今回の現象との関係 |
|---|---|---|
| Visual Studio（デバッグ開始） | ブレークポイント設定、アタッチ、ステップ実行の指示 | 起動直後にブレークポイントを一括同期しようとしてトリガーになる |
| Microsoft.WebAssembly.Diagnostics.DevToolsProxy | VSとブラウザーの間を中継し、WASMデバッグを成立させる | 想定外データを受けると例外で落ち、デバッグ全体が終了することがある |
| Chrome / Edge（Chromium） | WASM実行とDevTools Protocolの提供 | 特定バージョンで回帰があり、デバッグ連携の前提が崩れる可能性 |
| Windows更新 | 環境の更新（セキュリティ更新など） | ブラウザー更新タイミングや周辺挙動の変化と重なりやすい |
補足として、当時はChromium回帰としてissueが追われており、例として「dotnet/runtime#83452」が追跡情報として挙がることがありました（検索すれば該当の議論に辿り着けます）。
まず効く回避策
根本対応を待つ／更新を揃える前に、いったん作業を再開するための回避策です。最も手堅いのは、起動前のブレークポイントを全て無効化または削除してからデバッグ開始し、画面が立ち上がってからブレークポイントを戻す方法です。
ブレークポイントを「起動前に置かない」運用に切り替える
- Visual Studioでブレークポイントを全て無効化／削除する
- その状態で「デバッグ開始」する
- アプリの画面が表示されてから、必要なブレークポイントを追加（または再有効化）する
ブレークポイントを一括操作する代表的な導線は次の通りです。
- Visual Studio：「デバッグ」→「ウィンドウ」→「ブレークポイント」
- ショートカット例：Ctrl + Alt + B（環境により表示名が「ブレークポイント」や「ブレークポイント マネージャー」等になることがあります）
この回避策の弱点も押さえておきましょう。起動直後の初期化処理や、ページロード直後を止めたいケースでは使いづらく、ページ再読み込みで再発することがあります。その場合は、後述の「代替デバッグ手段」も併用すると現実的です。
回避策の選び方
| 回避策 | 効果 | デメリット | 向いている状況 |
|---|---|---|---|
| 起動前ブレークポイントを無効化 | 再現率が高い環境でも作業を再開しやすい | 起動直後を止めにくい | UI表示後の処理を追いたい |
| 起動後にブレークポイントを追加 | 原因トリガー（起動直後同期）を避けられる | 再読み込みで再発することがある | 一時的にしのぎたい |
| ログ出力中心に切り替える | 起動直後も追いやすい | ステップ実行ほど細かくは追えない | 初期化や依存関係の切り分け |
ブラウザー側での回避と切り分け
この事象はChromium系ブラウザーの挙動に強く影響されるため、ブラウザーを変える／更新するだけで改善することがあります。
まずは更新を確認する
- Edge / Chromeを最新に更新（修正版が配信されると改善するケースが多い）
- 更新後は一度ブラウザーを完全終了して、再起動してから試す
- 可能ならPCも再起動して、更新が中途半端に残らないようにする
一時的な逃げ道
更新しても改善しない場合、当時有効とされた逃げ道は次の通りです。
- Chrome Betaを使う（安定版と共存インストールでき、切り分けに便利）
- ブラウザーを1つ前の版に戻す（例：Chromium 110相当へ戻す、など）
- Firefoxで「実行だけ」行う（ただしBlazor WASMのデバッグがうまく効かない／シンボルが読み込めないことがある）
| 選択肢 | メリット | 注意点 |
|---|---|---|
| Chrome/Edgeを更新 | 最も正攻法。恒久対応に近い | 組織ポリシーで更新タイミングが固定されている場合がある |
| Beta/Devチャネルを使用 | 安定版と別枠で入れられ、検証が早い | 別チャネル特有の不具合が混ざる可能性 |
| ダウングレード | 「直前まで動いていた版」に戻せる | セキュリティ面のリスク。社内ルールに抵触しやすい |
| Firefoxに切替 | Chromium回帰を回避しやすい | Blazor WASMのデバッグ体験が落ちることがある |
現場的なおすすめ順は「ブラウザー更新」→「Beta併用で切り分け」→（どうしても必要なら）「ダウングレード」です。ダウングレードは、セキュリティ対策や社内規程に影響するため、個人判断での常用は避け、短期間の切り分けに留めるのが無難です。
恒久対応
根本解決に近いのは、ブラウザーとVisual Studioの更新を揃えることです。特にChromium側の修正が入った版に上がると、事前ブレークポイントでもデバッグできるようになった、という報告がありました。
更新の優先順位
- Edge / Chromeを最新へ更新（決定打になりやすい）
- Visual Studioを最新へ更新（17.5.2以降で改善したという報告もあり）
- .NET SDK（.NET 6/7の最新パッチ）と関連ワークロードを更新
更新後も不安定な場合は、次も合わせて確認すると改善に繋がることがあります。
- Visual Studioの「ASP.NETとWeb開発」ワークロードが最新になっているか
- プロジェクトのSDK/ランタイムが想定通りか（チームでバラついていないか）
- ブラウザー拡張（広告ブロック、開発支援系）を一時的に無効化して挙動が変わるか
再現確認と切り分けチェックリスト
「原因はこれ」と断定しにくい環境差があるため、切り分けを短時間で終わらせるチェックリストを用意しておくと便利です。Blazor WebAssemblyのデバッグクラッシュは、“起動前ブレークポイント”と“Chromiumバージョン”が特に効くため、そこを最短距離で潰していきます。
| チェック項目 | やり方 | 結果の読み取り |
|---|---|---|
| ブレークポイントを全無効化してデバッグ開始 | ブレークポイント一覧で全無効/削除→デバッグ開始 | 改善するなら「起動前同期」がトリガーの可能性が高い |
| 起動後にブレークポイントを追加して止まるか | 画面表示後にブレークポイントを追加し、操作で該当行を通す | 止まるなら、少なくともデバッグ自体は成立している |
| ブラウザーを別チャネルで試す | Chrome Beta/Edge Betaなどで同じ操作 | 差が出るならChromium側の回帰の影響が濃い |
| 新しいブラウザープロファイルで試す | 拡張なし・まっさらなプロファイルで起動 | 改善するなら拡張/設定が絡んでいる可能性 |
| 別PC/別ユーザーで再現するか | 同じリポジトリで別環境のVS/ブラウザーで試す | 特定端末だけならローカル環境要因が濃い |
| 最小構成の新規Blazor WASMで再現するか | テンプレートから新規作成し、ブレークポイント有無で試す | 新規でも落ちるならプロジェクト固有ではなく環境要因 |
起動直後をどうしても追いたい場合の代替アプローチ
「起動前ブレークポイントを置けない」となると、初期化周りの調査が苦しくなります。そんなときは、ブレークポイントに固執せず、次の代替策を組み合わせると進めやすいです。
ログを増やして“起動直後の状態”を可視化する
- ILoggerで重要な分岐点にログを入れる（認証、設定読み込み、DI解決、API呼び出し直前など）
- Blazor WebAssemblyなら
Console.WriteLineの出力がブラウザーのコンソールに出るケースがあるため、短期調査では有効 - 「一度だけ出したい」ログには、フラグを使ってスパム化を防ぐ
画面表示後に止められる設計に寄せる
- 初期化処理を「最初の画面表示後」に分割できないか見直す
- OnInitializedAsyncに詰め込みすぎている場合は、処理単位で関数化し、UI操作で再実行できる入口を作る
これらは「今回の不具合を避けるため」だけでなく、将来的にデバッグ環境が変わっても調査しやすい構造にするという意味でも有効です。
Blazor Serverでは起きにくい理由
同じBlazorでも、Blazor Serverはサーバー側の.NETプロセスで実行され、Visual Studioは通常の.NETデバッガーとしてアタッチします。一方、Blazor WebAssemblyはブラウザー内でWASMとして動くため、ブラウザーとの連携が不可欠です。この差により、今回のような「Chromiumの回帰×デバッグ連携」の影響は、WebAssembly側で顕在化しやすい、という整理になります。
チーム開発での再発防止
この手の問題は「自分だけ直った／自分だけ再発する」が起きやすく、チームで足並みを揃えないと、調査コストが雪だるま式に増えます。次のような運用にしておくと、再発時の復旧が速くなります。
環境を揃えるための実務的なルール
- プロジェクトにglobal.jsonを置き、チームの.NET SDKバージョンを固定する（可能なら）
- 「Visual Studioの更新目安」「ブラウザー更新の扱い（自動更新を許容するか）」をチーム内で明文化する
- 不具合が出たら、最初に共有する情報をテンプレ化する（VSのバージョン、.NET SDK、Chrome/Edgeのバージョン、再現手順、ログ）
緊急回避を“手順書化”しておく
今回のように、回避策が「ブレークポイントを事前に置かない」という運用変更になる場合、メンバー間で徹底できないと詰まります。以下のような文面をWikiやREADMEに短く入れておくと効果的です。
- デバッグ開始前は「ブレークポイントを全無効化」
- 画面が表示されたら、必要箇所のみブレークポイントを戻す
- 起動直後の調査はログ中心で行い、再現が取れたら更新で恒久対応
よくある質問
ブレークポイントを起動後に入れても、ページ再読み込みでまた落ちます
起動直後の同期処理が再度走るため、再読み込みで再発することがあります。再読み込みが必要な調査では、ブラウザー/Visual Studioの更新で恒久対応を優先しつつ、短期的にはログ中心に切り替えるのが現実的です。
「Chromeだけ」落ちて「Edgeは落ちない」ことがあります
同じChromium系でも、配信タイミングや組み込み差分、社内ポリシーによる更新管理の違いでバージョンがズレることがあります。まずはChrome/Edge双方のバージョンを確認し、Betaチャネルを使って差が出るかで切り分けると早いです。
Visual Studioを更新できない事情があります
まずはブラウザー側の更新（またはBeta併用）で改善するかを見ます。それでも無理なら、ブレークポイント回避運用＋ログ中心で進め、更新できるタイミングで恒久対応に寄せるのが安全です。ダウングレードは最終手段にし、短期間の検証に留めることをおすすめします。
.NET 6/7以外でも起きますか
本質は「WebAssemblyのデバッグ連携」と「Chromium側の挙動」にあるため、.NETのメジャーバージョンに限らず、条件が揃えば似た症状が出る可能性はあります。とはいえ、配布された修正やVisual Studio側の改善により、発生し続けるとは限りません。まずは“今の環境”を最新化し、同じ再現条件が残るかを確認するのが最短です。
まとめ
Windows更新後にBlazor WebAssemblyが「デバッグ開始だけクラッシュする」「事前ブレークポイントがあると落ちる」場合、DevToolsProxyを含むデバッグ連携とChromium側の回帰が噛み合った可能性が高いです。まずはブレークポイントの事前配置を避けて作業を再開し、並行してChrome/EdgeとVisual Studioを更新して恒久対応へ進めると、最短で安定運用に戻せます。
コメント