Windows 10 では動いていた ALM（旧 QC）ワークフローの VBScript デバッグが、Windows 11＋Visual Studio 2022（64‑bit）環境に入れ替えた途端に「Debug ▶ Attach to Process」で Script Documents が空白になる——。本稿はその“あるある”を、最短解から根本原因、再発防止まで一気に解決する実務ガイドです。
症状の概要と前提
Windows 11 環境に Visual Studio 2022 Professional（64‑bit）をクリーンインストール後、「Debug ▶ Attach to Process」実行時に Script Documents が空白でスクリプトが一切表示されない、またはブレークポイントが空の白丸（Unbound）になりヒットしない現象が発生します。対象は ALM（旧 Quality Center）クライアントのワークフローで実行される VBScript を想定していますが、wscript.exe / cscript.exe / mshta.exe、あるいは独自ホスト（WebView/IE モードや専用ランチャー）で動くスクリプト全般でも同様に起こり得ます。
典型的な症状は次のとおりです。
- Attach 直後、Script Documents ウィンドウが空のまま更新されない。
- ブレークポイントが「The breakpoint will not currently be hit. No symbols have been loaded for this document.」等のメッセージで無効化される（白丸）。
- プロセスにはアタッチできるが、ステップ実行や一時停止をかけてもスクリプトのソースが開かない。
結論（まず試す：最短の解決）
最初に次の 2 手順を実行してください。多くのケースはこれで直ります。
- コードタイプを「Script」に限定する
「Debug ▶ Attach to Process…」ダイアログで Attach to: 右の Select… をクリックし、Script（Script、JavaScript、VBScript を内包）にのみチェックを入れ、他はすべて外します。
※ Windows 11／VS 2022 の「Automatic」は複数のデバッグ エンジンを同時選択しがちで、VBScript を含むレガシー COM スクリプトでは言語マッピングに失敗して Script Documents が空になることがあります。 - Visual Studio を管理者として起動する
対象プロセス（例：企業配布のランチャーや WebView 実行ホスト）が管理者権限で動作している場合、同等の権限で VS を起動しないとスクリプト エンジンへのアタッチが拒否されます。
上記 2 点で Script Documents にソースが現れ、ブレークポイントが赤丸（Bound）になれば原因は コードタイプの過剰自動判定または権限不一致です。以降は再発防止策に進んでください。改善しない場合は下の詳細手順へ。
手順一覧（ダイジェスト）
| 手順 | 内容 | 目的／ポイント |
|---|---|---|
| 1 | コードタイプを「Script」に限定 Attach to Process の Select… で Script のみチェック | 複数エンジンの同時選択で言語マッピングが外れる問題を回避。Script Documents が正しく更新され、ブレークポイントが有効化される。 |
| 2 | VS を管理者として起動 | 対象プロセスが昇格済みのとき必須。権限差でデバッガ注入がブロックされるのを防ぐ。 |
| 3 | スクリプト デバッグ設定を確認 Tools ▶ Options ▶ Debugging で Enable JavaScript/Script Debugging 等を有効に | VS 側のスクリプト デバッグが無効化されていないかの確認。 |
| 4 | モジュールとアーキテクチャを確認 Debug ▶ Windows ▶ Modules | PDB は不要だが、vbscript.dll/jscript.dll の読み込みと、対象プロセスが x86 か x64 かを把握。間違ったプロセスにアタッチしていないかもチェック。 |
| 5 | アンチウイルス／Defender を一時無効化 | スクリプト ホストへのデバッガ注入・スレッド停止をセキュリティ製品が遮断するケースを切り分け。 |
| 6 | スクリプト エンジン DLL を再登録regsvr32 jscript.dll / regsvr32 vbscript.dll | 上書きアップグレードで COM 登録が壊れた場合の復旧。x86/x64 両方で実施。 |
| 7 | VS Installer で関連コンポーネントを確認 「Web 開発ツール」「JavaScript diagnostics」等 | スクリプト デバッグ エンジンや周辺ツールの不足を解消。 |
| 8 | devenv /log で診断ログ採取ActivityLog.xml を確認 | 読み込み失敗の詳細（対象エンジンのバインディング エラー等）を特定する最終手段。 |
なぜ起こるのか：Attach to Process と Script Documents の仕組み
Visual Studio は対象プロセスにデバッガ エンジンをインジェクト（注入）し、言語ごとの「コードタイプ」にマッピングしてソースを再構築します。Attach to: Automatic は便利ですが、Windows 11＋VS 2022（64‑bit）では Script／.NET／Native 等が同時選択になりやすく、レガシー COM ベースの VBScript では 優先順位衝突が発生して Script Documents が空になることがあります。Script のみに限定すれば、VBScript/JS 用のスクリプト デバッグ エンジンが単独で効き、Documents に動的スクリプトが展開されます。
手順の詳説（現場でやる操作）
1. コードタイプを Script のみに限定する
- Debug ▶ Attach to Process… を開く。
- Attach to: の Select… をクリック。
- 一覧で Script のみチェックし、他（.NET、Native、T‑SQL など）は外す。
- 対象プロセスを正しく選ぶ。
例：wscript.exe/cscript.exe/mshta.exe、企業ランチャー、msedge.exe（IE モード／WebView ホスト）など。
※ Show processes from all users と Show processes in all sessions にチェックを入れて見逃しを防止。 - Attach をクリック。
アタッチ成功後、Debug ▶ Windows ▶ Script Documents で対象スクリプト（.vbs、動的に生成された無題スクリプト等）が列挙され、ブレークポイントが赤丸になることを確認します。
2. Visual Studio を管理者として起動
対象プロセスが管理者権限（UAC 昇格）またはサービス経由で動いていると、通常権限の VS からはスレッド停止・コード挿入が拒否されます。スタートメニューの VS アイコンを右クリック ▶「管理者として実行」で起動し直してください。社内端末で AppLocker/WDAC が効いている場合は VS の実行ポリシーも確認しましょう。
3. スクリプト デバッグ設定を確認
- Tools ▶ Options ▶ Debugging ▶ General で Enable JavaScript/Script Debugging（名称はエディションにより微差）にチェック。
- Tools ▶ Options ▶ Debugging ▶ Just‑In‑Time で Script を有効化（JIT でスクリプト停止を拾えるようにする）。
- Tools ▶ Options ▶ Debugging ▶ Symbols はネイティブ／.NET 用。スクリプト デバッグ自体は PDB を要求しませんが、Modules ウィンドウの読み込み状況の可視化に役立ちます。
4. モジュールとアーキテクチャを確認（x86/x64 の罠）
Debug ▶ Windows ▶ Modules を開き、対象プロセスが x86（32‑bit）か x64（64‑bit） かを確認します。Script デバッグはプロセス アーキテクチャに依存します。特に ALM クライアントや古いホストは 32‑bit であることが多いため、SysWOW64 配下の vbscript.dll/jscript.dll がロードされているかを見ます。誤ったプロセス（親の msedge.exe ではなく、子のレンダラ プロセス等）にアタッチしていないかもここで気付けます。
5. セキュリティ製品の影響を切り分ける
エンドポイント保護（Defender、EDR、サードパーティ AV）が、デバッガの注入 API（DebugActiveProcess 等）を検疫・ブロックするケースがあります。一時的にリアルタイム保護を無効化するか、VS（devenv.exe）と対象プロセス、作業フォルダを除外に設定して再試行してください。企業環境ではセキュリティ チームに「開発中の一時例外」として申請するのが安全です。
6. スクリプト エンジン DLL を再登録（x86/x64 両方）
Windows 11 への上書きアップグレードや修復インストールで、vbscript.dll/jscript.dll の COM 登録が壊れていると Script Documents が更新されません。管理者のコマンド プロンプトで次を実行します。
%SystemRoot%\System32\regsvr32.exe %SystemRoot%\System32\jscript.dll
%SystemRoot%\System32\regsvr32.exe %SystemRoot%\System32\vbscript.dll
%SystemRoot%\SysWOW64\regsvr32.exe %SystemRoot%\SysWOW64\jscript.dll
%SystemRoot%\SysWOW64\regsvr32.exe %SystemRoot%\SysWOW64\vbscript.dll
32‑bit ホスト（wscript.exe など）でのデバッグには SysWOW64 側の登録が効きます。実行後は VS を再起動してください。
7. Visual Studio Installer でコンポーネント確認
- 「ASP.NET と Web 開発」ワークロード：JavaScript/TypeScript 言語サービスと診断ツールが含まれます。
- 個別コンポーネント例：JavaScript diagnostics、Diagnostic Tools、Just‑In‑Time Debugger。
- 最小構成の VS だとスクリプト デバッグ エンジン周辺が欠けることがあるため、上記が入っているか確認して不足を追加します。
8. devenv /log で診断ログを採取
- VS を閉じる。
- 「Developer Command Prompt for VS 2022」を管理者で開く。
devenv /logを実行して VS を起動。- 再現操作後に VS を終了し、
%APPDATA%\Microsoft\VisualStudio\17.0_*配下の ActivityLog.xml を開いて「Script」「Attach」「binding」「engine」などで検索。
言語サービスのバインディング失敗や権限拒否の詳細が出ます。
Windows 11 で起こりやすい落とし穴と回避策
- Automatic の過検出：複数コードタイプ併用で Script が後回しに。解決策：Script 限定。
- UAC／整合性レベル差：昇格プロセスに非昇格 VS で添付しようとして失敗。解決策：VS を管理者実行。
- x86 vs x64 の取り違え：32‑bit ホストに 64‑bit 前提で臨んで空振り。解決策：Modules でアーキテクチャ確認、必要に応じて
SysWOW64の DLL を再登録。 - VBScript の既定無効化方針：一部環境では VBScript がポリシー/機能として無効化されている場合あり。解決策：WSH の有効化と COM 登録を確認（後述）。
- IE モード／WebView 実行：親プロセスではなく、実際にスクリプトをホストする子プロセスにアタッチする必要あり。解決策：Show processes in all sessions を有効化し、子プロセスに個別アタッチ。
ALM（旧 QC）ワークフローの実践手順（例）
- ALM クライアント（ランチャー）を起動し、ワークフローの VBScript が実際に評価される画面まで進める。
- タスク マネージャで「アプリの詳細」を開き、スクリプトを実行していそうなプロセス（独自ランチャー、
wscript.exe、mshta.exe、msedge.exeの子など）を確認。 - VS を管理者で起動し、Attach to Process… ▶ Select… で Script のみチェック。
- 対象プロセスにアタッチ。Script Documents に無題スクリプトや
ActionCanExecute等のワークフロー関数が現れる。 - 任意の箇所にブレークポイントを設定し、ALM 側で該当操作を実行してヒットすることを確認。
分岐式トラブルシュート（何が起きているかで打ち手を決める）
| 観測される現象 | 原因の当たり | 対処 |
|---|---|---|
| Script Documents が空のまま | コードタイプ衝突／権限不足／誤プロセス | コードタイプを Script 限定、管理者で VS 起動、子プロセスへアタッチ |
| ブレークポイントが白丸（Unbound） | ドキュメント未バインド／実行経路に乗っていない | Script Documents 上の同一行に設定し直す、該当イベントを実行して経路を通す |
| アタッチ時に拒否（Access Denied） | UAC／EDR によるブロック | VS を管理者実行、EDR/AV 除外、企業ポリシーの一時緩和申請 |
| 一部端末だけ再現 | COM 登録破損／WSH 無効化 | regsvr32 で再登録、WSH レジストリ設定を確認 |
| 32‑bit のみ失敗 | SysWOW64 側の登録欠落 | 32‑bit DLL を SysWOW64\regsvr32.exe で再登録 |
レジストリ／ポリシーでの確認ポイント（自己責任で）
企業端末ではグループポリシーでスクリプト実行自体を制御していることがあります。変更は自己責任で、必ずバックアップと社内承認の上で行ってください。
- Windows Script Host（WSH）の有効/無効
HKLM\Software\Microsoft\Windows Script Host\SettingsHKCU\Software\Microsoft\Windows Script Host\Settings
値Enabled= 1（または未設定）で有効。0 だと WSH が無効化され、VBScript が動作しません。 - 64‑bit / 32‑bit スクリプト ホストの選択
同キーにUseWin64BitScriptHostがある場合、1 で 64‑bit を既定にします。対象ホストのビット数と一致させるのが基本です。 - JIT デバッグの許可
VS の「Just‑In‑Time（Script）」が許可されていること（Tools ▶ Options ▶ Debugging ▶ Just‑In‑Time）。
32‑bit/64‑bit の見分けと対処（具体例）
ALM クライアントや旧来のホストは 32‑bit が多数派です。次の要領で突き合わせます。
- タスク マネージャ「詳細」タブの列に「プラットフォーム」を追加（x86／x64 が見える）。
- x86 なら SysWOW64 の DLL 再登録が効く（前述の 4 行をすべて実行）。
- VS は 64‑bit でも x86 プロセスにアタッチ可能。Transport: Default、Qualifier: <ローカル> のままで問題ありません。
代替アプローチ：JIT で強制停止してから VS に拾わせる
どうしても Attach に成功しない場合、スクリプト ホストを //X オプションで起動して最初の行で停止させ、VS の JIT（Script）で拾わせる方法があります。
cscript.exe //D //X yourscript.vbs
wscript.exe //D //X yourscript.vbs
//D は最適化無効化、//X は最初の行でデバッガを起動します。企業ランチャー配下の実行でも、コマンド ライン引数に //X 相当を付与できる場合は同様に有効です。
キャッシュ破損時のリセット手順
VS の内部キャッシュ破損が疑われるときは、以下で初期化してから再試行します（VS を終了した状態で）。
- MEF キャッシュ削除：
%LOCALAPPDATA%\Microsoft\VisualStudio\17.0_*\ComponentModelCacheを削除。 - 一時ファイルの削除：
%TEMP%と%LOCALAPPDATA%\Tempをクリーンアップ。 - 設定リセット（最終手段）：
「Developer Command Prompt for VS 2022」でdevenv /ResetSettings。
再発防止の運用 Tips
- Attach のプリセットを固定化：最後に選んだコードタイプが次回に持ち越されるため、常に Script 限定で運用。
- Reattach を活用：Debug ▶ Reattach to Process（Shift+Alt+P） で直前の対象に素早く再接続。子プロセスが再生成されるホストで有効。
- プロセスの選定ルールをチームで共有：ALM、ランチャー、WebView のどのプロセスに付けるかを一覧化。
- 権限・EDR の整備：開発端末の標準除外ポリシーに VS とデバッグ対象を含める。
よくある質問（FAQ）
Q. Script Documents に「無題」ファイルしか出ず、元の .vbs が出ません。
A. ホストが動的にスクリプトを生成している可能性があります。Script Documents で該当ファイルを開き、実行時に展開されるソースへ直接ブレークポイントを置いてください。静的 .vbs を編集しても当該実行には反映されません。
Q. ブレークポイントが灰色のまま赤になりません。
A. 実行経路に該当行が入っていないか、最適化や条件付きコンパイルで行がスキップされています。イベント発火条件や //D（最適化無効）を確認してください。
Q. ある PC だけ直らないのですが？
A. COM 登録破損（regsvr32 で復旧）、WSH の無効化（Enabled キー）、EDR のポリシー差異（例外申請）を疑ってください。
安全上の注意
- regsvr32 の実行は管理者権限で慎重に。DLL のパスを必ず既定の
System32/SysWOW64に限定し、不明な DLL は登録しないでください。 - 企業ポリシー下では設定変更の申請を厳守。EDR 例外やレジストリ変更は監査対象です。
まとめ
- Windows 11＋VS 2022 で Script Documents が空になる主因は、コードタイプの自動判定による言語マッピング不一致と権限不一致。
- 最短の解決は「Script 限定」＋「管理者起動」。これで多くの事例が即時回復。
- 改善しない場合は、レジストリで WSH を確認、vbscript/jscript の再登録、x86/x64 の突き合わせ、セキュリティ製品の例外、ActivityLog.xml で証跡確認を順に実施。
- ALM（旧 QC）などレガシー ワークフローのデバッグでは、子プロセスにアタッチし、動的スクリプトにもブレークポイントを張ることがポイント。
付録：作業チェックリスト（印刷用）
| 項目 | 確認内容 | 結果 |
|---|---|---|
| コードタイプ | Attach to ▶ Select… で Script のみを選択 | □ 済 |
| 権限 | VS を管理者として実行／対象プロセスと整合 | □ 済 |
| 対象プロセス | 子プロセスへアタッチ（All users / All sessions） | □ 済 |
| WSH 有効 | HKLM/HKCU の Enabled が 1/未設定 | □ 済 |
| DLL 登録 | jscript.dll / vbscript.dll を System32/SysWOW64 の両方で regsvr32 | □ 済 |
| セキュリティ | AV/EDR の一時無効化または除外設定 | □ 済 |
| ログ | devenv /log で ActivityLog.xml を採取 | □ 済 |
コメント