本記事の対象となる事象は、Windows環境でRustコンパイラをソースからビルドする際、./x build --stage 1（または同等のx.py実行）で0xc0000005 (STATUS_ACCESS_VIOLATION)が発生するケースです。2025年12月22日のGitHub Issueと、2026年1月13日のRust Users Forum投稿では、Visual Studio（以下VS）Insiders 2026相当の環境で同種の失敗が報告され、VS 2022 Build Toolsへ切り替えると解消した、という経緯が示されています。 (GitHub)
- 事象の整理：stage1で何が起きているか
- Windows/MSVCでの前提：Rustが想定する“推奨ツールチェーン”の範囲
- 原因候補の構造：VS 2026で起きやすいズレと再現条件
- 「VS 2026をサポートするか」の意味：公式文言と現場判断のズレ
事象の整理：stage1で何が起きているか
STATUS_ACCESS_VIOLATIONは「ビルドが失敗した」というより「ビルド中に実行されたrustc等が異常終了した」ことを意味します。 (GitHub)
Rustをソースからビルドする場合、x.py（./x）が段階的にコンパイラと標準ライブラリを構築します。典型的には、手元にある既存コンパイラ（stage0）でstage1コンパイラを作り、そのstage1で標準ライブラリ群（coreやallocなど）を再コンパイルして「stage1のsysroot」を作ります。GitHub Issueのログでは、coreのコンパイル中にrustcプロセスが0xc0000005で落ちた形になっており、終了コードだけ見ると「コンパイル結果のエラー」ではなく「プロセスのクラッシュ」に分類されます。 (GitHub)
一方で、Rust Users Forumの投稿では、同様のSTATUS_ACCESS_VIOLATIONが出た後にVS 2022 Build Toolsへ切り替えると解消したと述べています。 (The Rust Programming Language Forum)
つまり、本記事で整理する論点は「Rustコードの不整合」よりも「Windows上のツールチェーン構成差が、ビルド中に実行されるバイナリの安定性に影響した可能性」です。この点から、次にWindows/MSVC側の前提を整理します。
Windows/MSVCでの前提：Rustが想定する“推奨ツールチェーン”の範囲
Rustの公式ドキュメントでは、Windows MSVC環境で“最新のVS（当時はVS 2022）推奨”という書き方が残っており、CIでの積極検証範囲と利用者の環境がずれる余地があります。 (doc.rust-lang.org)
Rustの*-pc-windows-msvcターゲットは、MSVCツールチェーンとWindows SDK（およびリンカ等）を前提にします。rustc bookでは「最低サポートはVS 2017だがCIでは積極的にテストされていない」「最新のVS（現在はVS 2022）の利用が強く推奨」と明記されています。 (doc.rust-lang.org)
またrustup bookのMSVC prerequisitesでも、VS 2017以降をサポートしつつ、推奨は当時の最新（VS 2022）とされています。 (rust-lang.github.io)
ここで重要なのは、VS “本体”のバージョン表示と、実際に使われるMSVC toolset・CRT（Cランタイム）・Windows SDKの組み合わせが、利用者の導入経路（VS IDE / Build Tools / Insider）で変わり得る点です。そうすることによって、Rustのビルドが内部で利用するリンカやライブラリ、さらにLLVM関連のバイナリとの整合が崩れる可能性が残ります。
以上を踏まえると、VS 2026相当の環境で即座に「未対応」と断定できるわけではない一方、実務上の確認点となる“組み合わせ差”が増える状況と整理できます。
原因候補の構造：VS 2026で起きやすいズレと再現条件
本記事が示す状況は、(1) 事前に用意されたLLVM等のバイナリ、(2) 手元のMSVC/SDK、(3) ビルド中に実行されるrustc自身、の境界で不整合が起きるときにクラッシュとして表面化しやすい、という構造で説明できます。 (Chromium)
まず、Rustのソースビルドでは「LLVMをダウンロードして使う」選択肢が公式のINSTALL.mdでも示されています（llvm.download-ci-llvm = true）。 (Chromium)
この方式は環境構築を簡略化する一方、LLVMや関連DLLが特定のビルド条件（MSVC toolsetやランタイム想定）で作られている場合、利用者側のVS/Build Tools更新が進みすぎると境界の整合が崩れる余地があります。GitHub Issue側は、Win11＋VS Studio Insiders 2026の条件でstage1中に落ちるログを提示しています。 (GitHub)
さらにRust Users Forumでは、VS 2022 Build Toolsへ寄せると解消したと書かれており、「新しすぎるtoolcahin側との差」が示唆されます。 (The Rust Programming Language Forum)
次に、同じSTATUS_ACCESS_VIOLATIONでも原因が一つに限らない点は整理が必要です。別のForum投稿では、同様のcoreビルド失敗に対して「アンチウイルス等のセキュリティソフトの影響」に言及があります。 (The Rust Programming Language Forum)
つまり、(A) ツールチェーン整合、(B) 実行ファイルの介入・隔離、(C) SDKやパス混在、のいずれでも「実行中クラッシュ」として同型の症状になり得ます。要点を整理すると、次の比較が判断材料として重要です。
| 観点 | 典型的な出方 | 論点の位置づけ |
|---|---|---|
| VS/Build Toolsの世代差 | VS 2026相当で落ち、VS 2022相当で通る | LLVM/CRT/SDKの整合差が生じる可能性がある (The Rust Programming Language Forum) |
| 事前ビルドLLVMの利用 | llvm.download-ci-llvm前提で構成が単純化 |
便利だが、境界不整合が起きる余地が残る (Chromium) |
| セキュリティソフト介入 | core等のビルド中に突然落ちる |
実行ファイルの挙動が変化し得る (The Rust Programming Language Forum) |
ただし、ここでの整理は「一般に起こり得る構造」の提示であり、特定の環境での唯一の原因を示すものではありません。なお、GitHub Issue自体は“クラッシュ現象”の提示が中心で、VS 2026の公式サポート可否を確定する声明とは読み分ける必要があります。 (GitHub)
この点を踏まえ、最後に「サポート」の意味と見通しを整理します。
「VS 2026をサポートするか」の意味：公式文言と現場判断のズレ
Rust側の“推奨VS”は時点依存で更新される一方、利用者がInsiders等の先行版を選ぶと、検証範囲外の組み合わせに入る可能性が高まります。 (doc.rust-lang.org)
rustc bookとrustup bookはいずれも「VS 2017以降をサポートし、最新（当時はVS 2022）を推奨」という書き方です。 (doc.rust-lang.org)
言い換えると、VSの将来版を排除しているわけではないものの、CIでの継続テスト対象と一致するとは限りません。この結果、(1) Rust本体の不具合、(2) 依存バイナリ（LLVM等）とMSVCランタイムの組み合わせ差、(3) Windows側の保護機能やセキュリティ製品、が同じ症状に収束し、切り分けが難しくなります。
一方で、ソースビルドの手順は「LLVMをダウンロードして使う」「自前でLLVMを用意する」など複数の分岐を持ち、同じOSでも構成差が大きくなります。 (Chromium)
つまり、本記事の対象テーマに対する現実的な結論は、「VS 2026というラベル単体」ではなく、「MSVC toolset・SDK・LLVM入手方法・実行時介入の有無」をセットで見ないと再現条件を確定しにくい、という整理になります。
以上を踏まえると、Forumで示された「VS 2022 Build Toolsへ寄せると解消」という事実は、少なくとも一部の環境では“推奨ラインへ合わせるほど安定する”ことを示す判断材料になります。 (The Rust Programming Language Forum)
ただし、同型のクラッシュが常に同じ理由で起きるわけではないため、最終的にはログと構成の対応関係をもとに、原因候補を段階的に狭める必要が残ります。
