Visual Studio 2019とVisual Studio 2022を同じ開発用PCに入れている環境で、ブルースクリーン（BSOD）が頻発すると「複数バージョンのVisual Studio（VS）が原因では？」と疑われがちです。本記事では、VSの共存可否、BSODが起きる仕組み、そしてWinDbgとミニダンプで原因を技術的に特定・説明する手順を、現場で使える形にまとめます。
Visual Studio 2019と2022は同一PCに共存できる？
Visual Studioは、複数バージョンを同一マシンに入れるサイドバイサイドインストール（side-by-side）を前提としており、VS 2019とVS 2022を同じWindowsにインストールして使い分ける運用は一般的です。企業では、既存製品の保守（旧ツールチェーンやSDKが必須）と、新規開発（新機能や最新SDKが必須）を並行するために、複数世代のVSを併用することが珍しくありません。
ただし、共存で起きやすいのは主にユーザーモード側のトラブルです。
- ディスク使用量が増える（SDK、キャッシュ、エミュレーターなどが重複しやすい）
- 既定の起動バージョンやファイル関連付けが期待どおりにならない
- 拡張機能が片方のVSでしか動かない／相性が出る
- MSBuildや.NET SDKの選択がプロジェクトにより変わり、ビルド結果が揺れる
これらは確かに困りますが、PC全体が落ちるBSODの一次原因とは切り分けて考える必要があります。
BSODの基本：なぜWindowsはブルースクリーンになるのか
BSOD（BugCheck）は、Windowsが「このまま動かすとデータ破壊やセキュリティ上の重大事故につながる」と判断したときに、システムを保護するために強制停止する仕組みです。原因として多いのは次の2系統です。
- カーネルモードで動くコードの不具合（デバイスドライバー、ファイルシステムフィルター、仮想化、セキュリティ製品のカーネル部品など）
- ハードウェア起因（メモリ不良、ストレージ不良、電源・温度、周辺機器、ファームウェア不整合など）
VS本体は通常ユーザーモードで動くアプリケーションです。ユーザーモードのプロセスはOSの保護機構の中で動作するため、単体でカーネル領域を破壊してBSODを起こすことは基本的にできません。ここが「VSの複数インストールがBSODの一次原因である可能性は低い」と説明できる根拠になります。
| 要素 | 動作する場所 | 障害の典型 | BSODへの直結度 |
|---|---|---|---|
| Visual Studioなどのアプリ | ユーザーモード | アプリのクラッシュ、フリーズ、ビルド失敗 | 低い（直接ではなく、ドライバー不具合の引き金になる程度） |
| 各種ドライバー（GPU/AV/ストレージ等） | カーネルモード | メモリ破壊、整合性エラー、I/O異常 | 高い（主要原因） |
| ハードウェア（RAM/SSD/電源等） | 物理 | ビット化け、読み書きエラー、温度暴走 | 高い（症状が不規則になりやすい） |
よくある主張を、技術的に整理する
社内で議論が拗れやすいのは、主張が「それっぽい」一方で、検証が難しいからです。次の表のように、論点を整理してから調査に入ると、感情論になりにくくなります。
| よくある主張 | 技術的な整理 | 現場での確認ポイント |
|---|---|---|
| 「VSを複数入れているからBSOD」 | VS自体はユーザーモード。一次原因はドライバーやハード故障が多い | ミニダンプ解析で.sys（ドライバー）が出るか |
| 「VSを消したら止まった＝VSが原因」 | 高負荷トリガーが消えて“出にくくなった”だけの可能性がある | 再現条件（ビルド/デバッグ/アイドル）と相関があるか |
| 「Windows（ntfs.sys）が悪い」 | NTFSの上に挟まるフィルタードライバーが原因で巻き込まれていることが多い | スタックにサードパーティ.sysが混ざっていないか |
| 「とにかくVSを1つに統一しよう」 | 標準化としては合理的だが、BSODの原因説明とは別問題 | 安定性（BSOD）と統制（標準化）を分けて議論できているか |
「VSが関係する」ことはあるが、「複数VSが原因」とは限らない
現場では、VS使用中にBSODが起きると「VSが原因」と感じてしまいます。ここは否定ではなく、因果関係を分解して説明するとスムーズです。
VSが“引き金”になりやすい理由
- 大量のファイルI/O：ビルド、NuGet復元、npm/yarn、生成物（bin/obj）、キャッシュなどでストレージへの負荷が非常に高い
- デバッグ・計測：デバッガ、プロファイラ、トレースはOSの深いところまで触る（セキュリティ製品が監視を強めることもある）
- GPUアクセラレーション：エディターやUI描画がGPUドライバーの弱点を踏むことがある
- 仮想化・エミュレーション：Androidエミュレーター、WSL2、Hyper-Vなどの利用で仮想化スタックが関わる
重要なのは、これらはVSが1つしか入っていなくても起きる点です。つまり「複数バージョン共存だからBSOD」という単純な図式は成立しにくく、実際は周辺ドライバーやハードウェアの不安定さが、VSの高負荷操作で顕在化しているケースが多くなります。
ワークロード次第では“カーネル要素”が増えることもある
VS本体はユーザーモードですが、導入するワークロードや周辺ツールによっては、結果的にカーネル要素（ドライバーやフィルター）が増えることがあります。これは「複数VS」固有というより、「開発環境を厚くした結果」の話です。
| 機能・ツールの例 | 増えやすい要素 | 確認のヒント |
|---|---|---|
| 仮想化（WSL2/Hyper-V/エミュレーター） | 仮想化スタック、仮想NIC、関連ドライバー | Hyper-V/WSL2の有効化状況、VPN併用の有無 |
| セキュリティ製品（EDR/DLP） | ファイル/ネットワークのフィルタードライバー | 導入製品のドライバー一覧、例外設定の要否 |
| 周辺機器デバッグ（USB、ドライバー署名関連） | デバイスドライバー、署名/検証の変化 | 直近で接続した機器・導入したドライバーの有無 |
まずは事実を集める：停止コード・ミニダンプ・発生条件
BSOD対策で最も大事なのは、早い段階で推測から証拠ベースに切り替えることです。最低限、次の情報があるだけで調査の精度が大きく変わります。
| 集める情報 | 具体例 | 調査での使い道 |
|---|---|---|
| 発生日時 | YYYY/MM/DD HH:MM | Windows更新、バックアップ、定期スキャン、ドライバー更新との相関を見る |
| 停止コード（Stop code） | IRQL_NOT_LESS_OR_EQUAL など | メモリ・ドライバー・I/Oなど、疑う方向を絞る |
| 画面に出たドライバー名 | xxxxx.sys（出る場合） | 犯人候補がほぼ決まる（製品特定へ進める） |
| 直前の作業 | ビルド中／デバッグ開始直後／アイドル時 | 再現条件の特定、トリガーの切り分け |
| ミニダンプ | C:\\Windows\\Minidump\\xxxx.dmp | WinDbgで原因ドライバーを特定するための核心資料 |
信頼性モニターで“いつから悪化したか”をつかむ
Windowsには、アプリクラッシュや更新履歴を時系列で見られる「信頼性モニター」があります。BSODが「いつから増えたか」「更新やドライバー変更と重なっていないか」を把握するのに便利です。コマンドから開くなら次の方法が手軽です。
perfmon /relイベントビューアで「BugCheck」や「WHEA」を探す
ミニダンプが取れない場合でも、イベントログに手掛かりが残ることがあります。特に、ハードウェア起因のエラーはWHEA（Windows Hardware Error Architecture）として記録されることがあります。権限や運用ルールの範囲で、IT部門にログ抽出を依頼できると強いです。
WinDbgで原因を説明可能にする：ミニダンプ解析の手順
社内で最も説得力が出るのは、「誰が見ても同じ結論に到達できる材料」を出すことです。BSODはミニダンプをWinDbgで解析すると、落とした可能性の高いドライバー（.sys）やスタックが確認できます。
WinDbgを準備してダンプを開く
- WinDbgをインストール（Microsoft Store版でも可）
- 対象の
.dmp（例：C:\\Windows\\Minidump\\配下）を開く
シンボルを設定する（スタックの精度が上がる）
シンボルが正しく設定されないと、スタックが読めず「原因不明」に見えやすくなります。よく使う設定例です（ローカルキャッシュ先は環境に合わせて変更してください）。
.symfix
.sympath+ srv*C:\\Symbols*https://msdl.microsoft.com/download/symbols
.reload /f!analyze -v で全体像を掴む
!analyze -vここで見るべきポイントは次のとおりです。
- BugCheck（停止コード）：エラーの種類（メモリ系、I/O系、整合性チェックなど）
- Probably caused by：犯人候補として挙がるモジュール（確定ではないが重要）
- STACK_TEXT：落ちる直前に通っていた処理の流れ
- MODULE_NAME / IMAGE_NAME：具体的な.sys名
怪しい.sysを“製品名”に紐付ける
abcxyz.sysのようなサードパーティドライバーが見えたら、次のコマンドで詳細を確認します。
lmvm abcxyz表示されるCompanyNameやProductName、パス情報から、EDR/アンチウイルス、VPN、バックアップ、暗号化、仮想化、周辺機器など、どの製品に属するかが見えてきます。社内説明では「VSが悪い」よりも「このドライバーがこの条件で落ちている」の方が合意形成が速いです。
停止コードから“次に疑う方向”を決める
| 停止コード例 | ざっくり意味 | 次に疑うもの |
|---|---|---|
| IRQL_NOT_LESS_OR_EQUAL | 高IRQLでの不正アクセス | ドライバー不具合、RAM、電源・温度 |
| PAGE_FAULT_IN_NONPAGED_AREA | 参照すべきでない領域を参照 | ドライバー、RAM、ストレージ周り |
| SYSTEM_SERVICE_EXCEPTION | システムサービス中の例外 | GPU/AV/FSフィルター、Windows更新後の不整合 |
| KERNEL_SECURITY_CHECK_FAILURE | 整合性チェック失敗 | ドライバーのメモリ破壊、互換性問題 |
| CRITICAL_PROCESS_DIED | 重要プロセスが停止 | ストレージ、システム破損、セキュリティ製品の副作用 |
ミニダンプで足りないときの相談ポイント
ミニダンプは軽量で扱いやすい一方、情報が不足するケースもあります。解析が「原因特定に至らない」場合は、IT部門にカーネルメモリダンプ等の取得可否を相談してください（保存容量や個人情報の取り扱いルールが絡むため、社内規定に従うのが前提です）。
ntfs.sys / fltmgr.sysが見えるとき：本当に疑うべき相手
解析結果でntfs.sys（NTFS）やfltmgr.sys（Filter Manager）がスタックに出ることがあります。この場合、「WindowsのNTFSが悪い」と見えてしまいますが、実務では次のパターンが多いです。
ファイルシステムの上に挟まるフィルタードライバー（ウイルス対策、DLP、バックアップ、暗号化、同期、仮想ファイルシステム等）が原因で、結果としてNTFS/Filter Managerの文脈で落ちている、という構図です。
| 疑う対象 | 代表例 | VS利用とぶつかりやすい理由 | 次のアクション |
|---|---|---|---|
| アンチウイルス／EDR | リアルタイムスキャン、振る舞い検知 | ビルドで短時間に大量のファイルを生成・削除する | ベンダーアップデート、除外設計の相談、互換性情報の確認 |
| DLP／暗号化 | 透過暗号化、監査ログ | 生成物が増えるほど監視・変換処理が増える | 設定見直し、対象フォルダの設計、ベンダーにダンプ提供 |
| 同期／バックアップ | クラウド同期、スナップショット | node_modulesやbin/objの増減が激しく監視負荷が高い | 同期対象外の作業領域を用意、スケジュール調整 |
| 仮想ファイルシステム | 仮想ドライブ、リダイレクト | ビルドや復元がファイルシステム機能を強く使う | 該当ドライバー更新、不要なら無効化、ベンダー確認 |
原因カテゴリ別：現実的な対処の方向性
WinDbgで.sysが特定できたら、次は「どう直すか」です。社内で動かしやすい順に、現実的な打ち手を整理します。
| 原因カテゴリ | 対処の例 | ポイント |
|---|---|---|
| セキュリティ製品（AV/EDR/DLP） | 最新版へ更新、特定フォルダの除外、設定の互換モード、ベンダー調査依頼 | 除外は最小範囲で。根拠としてダンプ解析結果（.sys名）を添えると通りやすい |
| GPUドライバー | 更新／ロールバック、企業推奨版へ統一、VSの視覚効果を軽くする | 「最新＝安定」とは限らない。特定版で安定することも多い |
| ストレージ・チップセット | NVMe/RAID/チップセットドライバー更新、SSDファーム更新、診断 | ビルドの大量I/Oで顕在化しやすい。イベントログとSMARTも併用 |
| 仮想化・VPN・ネットワークフィルター | 不要機能の無効化、仮想NIC/フィルタードライバー更新 | 開発用途のエミュレーターやVPNが絡むと、ネットワーク系BSODの原因になりやすい |
| ハードウェア | メモリ診断、温度・電源確認、周辺機器切り離し、部品交換 | 停止コードが揺れる／再現条件が一定しない場合は疑う価値が高い |
セキュリティ部門を納得させる「検証」の作り方
「VSを複数入れているから」という主張に対して、感情ではなく検証で答えるのが最も建設的です。おすすめは次の二段構えです。
VSを1バージョンだけにした環境で再現するか
- 検証用PC（または同等構成の検証環境）を用意
- VS 2022のみ（またはVS 2019のみ）をインストールして業務相当の負荷をかける
- 同様にBSODが出るなら、複数VS共存が一次原因である可能性は大きく下がる
- 出ないなら、差分（ドライバー、セキュリティ製品設定、周辺機器、更新状況）を洗い出して次の仮説へ
この検証は「複数VSが原因」という仮説を、誰でも理解できる形で検証できます。
ミニダンプ解析で“落とした主体”を特定する
並行してWinDbg解析を進め、「Probably caused by」「スタック」「lmvm」で得られた情報を根拠に、原因ドライバー（製品）へ調査依頼を出します。ここまで揃うと、議論は「VSを消す」ではなく「ドライバーを直す／更新する」に自然に移ります。
管理者権限がない環境での現実解：記録＋依頼のテンプレ
開発者がローカル管理者権限を持たない職場では、ドライバー更新やセキュリティ設定変更は自力でできません。その場合でも、次の2点を徹底すると状況が動きやすくなります。
- 再現性のある情報を記録する（日時、停止コード、作業内容、ダンプ）
- 依頼内容を“技術的な作業指示”に落とす（WinDbg解析、対象.sysの特定、ベンダー調査）
チケットやメールに貼れる依頼文例：
・現象：開発用PCでBSODが断続的に発生
・発生タイミング：ビルド中／デバッグ開始直後／アイドル時 など（発生ごとに記録）
・停止コード：XXXX（スクリーンまたはイベントログ）
・ダンプ：C:\\Windows\\Minidump\\ の.dmpを提供ください（または取得をお願いします）
・お願い：WinDbgで !analyze -v を実行し、原因ドライバー（.sys）と製品名の特定をお願いします
・補足：VS 2019/2022が共存していますが、ユーザーモードアプリ単体が一次原因でBSODになる可能性は低いため、ドライバー／ハードウェア起因の確認を優先したいですよくある誤解（社内で揉めやすいポイント）
「VSを消したらBSODが止まった＝VSが原因」では？
VSを消すと、ビルドやデバッグなど高負荷のトリガーが消えるため、一時的にBSODが出にくくなることがあります。しかしそれは「根本原因（ドライバーやハードウェア）が直った」ことと同義ではありません。再発防止の観点では、ダンプ解析で原因主体を特定して対処する方が堅実です。
「ntfs.sysが出た＝Windowsの不具合」では？
多くの場合、NTFSの上に挟まるフィルタードライバー（AV/EDR/DLP/同期/暗号化など）が絡んで落ちています。ntfs.sysやfltmgr.sysは“現場に居合わせただけ”のことも多いため、スタック上のサードパーティ.sysやlmvmの情報を見て判断します。
「複数VSはセキュリティ的に危ないから禁止」は正しい？
運用ポリシーとして「標準化のためにVSは1世代に統一する」はあり得ます。ただし、それは主に運用コストやパッチ管理の話で、BSODの直接原因の説明とは別です。議論を混ぜると結論がぶれやすいので、「安定性（BSOD）」と「標準化（運用・統制）」を分けて扱うのがポイントです。
まとめ：VSの数を疑う前に、原因を“特定できる形”にする
Visual Studio 2019と2022の共存は一般的で、複数インストールそのものがBSODの一次原因になる可能性は高くありません。BSODを再発防止まで含めて解決するには、停止コードとミニダンプを軸にWinDbgで原因ドライバー（.sys）や関係製品を特定し、更新・設定見直し・ベンダー対応・ハード診断へつなげるのが王道です。
「VSを減らす」より先に、「原因を証拠で説明できる状態にする」——この進め方を共有できれば、セキュリティ部門とも建設的に合意形成ができます。
コメント