Windows Server 2019環境でPowerShellを起動したところ、一瞬だけウィンドウが表示された後すぐに閉じてしまう問題に悩まされていませんか。この記事では、原因と対策を詳しく解説し、スムーズなサーバ管理を実現するための具体策を紹介します。
Windows Server 2019で発生するPowerShellクラッシュの概要
Windows Server 2019 Datacenter（バージョン1809、OSビルド17763.5576）上でPowerShellを起動すると、一瞬だけコンソールが表示された後にウィンドウが自動的に閉じてしまい、コマンドを実行することができない不具合が報告されています。さらに、CMDプロンプト上で「powershell」と入力すると「Starting the CLR failed with HRESULT 80070005.」というエラーが返されるケースもあり、イベントログには何も記録されないことからトラブルシューティングが難航しがちです。
このような症状は単にPowerShellの問題というより、.NET Framework関連やアクセス権関連など、OSに深く関わるコンポーネントが原因である可能性が高いです。そこで、以下では発生しうる代表的な原因と、その解決策について詳しく解説していきます。
考えられる主な原因
.NET Frameworkの不具合
Windows Server 2019標準のPowerShell 5.1は.NET Framework上で動作しています。CLR（Common Language Runtime）関連のエラーが示すように、.NET Frameworkファイルの破損やバージョンの競合が原因となると、正常にPowerShellが起動できないことがあります。特に「HRESULT 80070005」は「アクセスが拒否されました」を示す場合が多く、ファイルシステムもしくはレジストリへのアクセス不備につながるケースも考えられます。
アクセス権の問題
「HRESULT 80070005」がアクセス拒否を意味することから、ファイルシステムやレジストリの権限設定に何らかの問題が起きている可能性もあります。管理者権限で実行しているつもりでも、実際にはOSレベルでの権限が不足している、あるいは特定のレジストリキーに制限がかかっているなど、多岐にわたる要因が考えられます。
イベントログへの記録漏れ
イベントログにエラーが残っていないのは珍しい状況ですが、イベントログサービス自体が正しく動作していないか、あるいはログを記録するタイミングでOSが異常終了扱いと判断していない可能性があります。また、PowerShellプロセス起動時に瞬間的にクラッシュしているため、イベントロガーがフックできずに記録されないケースも考えられます。
具体的な解決策とアプローチ
ここでは代表的なアプローチを紹介します。環境によっては複数の対策を組み合わせる必要があるかもしれませんが、手順を一つずつ確かめながら実施することで、問題点を徐々に特定していくことが可能です。
.NET Frameworkのアンインストールと再インストール
.NET Frameworkの破損が疑われる場合、以下の手順で一度アンインストールを行い、最新バージョンを再インストールしてみることをおすすめします。
アンインストール手順
- 「サーバーマネージャー」を起動し、「機能の管理」または「役割と機能の追加と削除」から対象の.NET Frameworkを探します。
- 該当するバージョンをアンインストールします。
- サーバーを再起動します。
再インストール手順
- 公式マイクロソフトサイト から.NET Framework 4.8のインストーラをダウンロードします。
- インストーラを実行し、画面の指示に従ってインストールを完了させます。
- サーバーを再起動し、PowerShellが正常に起動するか確認します。
PowerShell 7の導入
従来のWindows PowerShell 5.1は.NET Framework上で動作しますが、PowerShell 7以降は.NET Core（現在は.NET 7などの新世代ランタイム）を基盤としているため、.NET Framework由来の問題を回避できる可能性があります。すぐに対応が必要であれば、PowerShell 7のインストールを試してみるのも一つの手です。
インストール例: Windows用MSIパッケージ
- Microsoft Learnの公式ドキュメントからMSIファイルをダウンロード。
- ダウンロードしたMSIファイルを実行し、セットアップウィザードの指示に従います。
- インストールが完了したら、スタートメニューまたは
pwsh.exeコマンドでPowerShell 7を起動して確認します。
Wingetを用いたインストール
# 管理者権限でコマンドプロンプトか従来のPowerShellを開き、以下を実行
winget install Microsoft.PowerShellWingetのコマンドは非常にシンプルで、一度環境を整えておけば更新作業も容易です。PowerShell 7の導入で症状が改善すれば、問題はおそらく.NET Framework周りの不具合である可能性が高いと推測できます。
ファイルシステムやレジストリのアクセス権を確認
「CLRが起動に失敗した」旨のエラーに加え、HRESULT 80070005「アクセス拒否」の意味を踏まえると、セキュリティ設定に問題が発生している可能性が否定できません。具体的には以下の点を確認しましょう。
- システムドライブ（C:\）やWindowsフォルダ、System32フォルダへのアクセス権に誤りがないか
- レジストリの
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servicesや.NET Framework関連キーにアクセス権の問題がないか - ローカルセキュリティポリシーが意図しない形で制限をかけていないか
こうした設定誤りは、セキュリティソフトやグループポリシー適用時などに発生することがあります。ドメイン環境であれば、ドメインコントローラー側のGPO設定も併せて見直すことをおすすめします。
トラブルシューティングの追加手順
すでにDISMやSFCスキャンを実施して改善が見られない場合でも、下記の追加手順を試す価値があります。
DISM/SFCの再実施とソース指定
DISMやSFCは状況によっては一度の実行で修復がすべて完了しない場合があります。イメージのソースを正しく指定して何度か再実施することで、修復されるファイルが変化するケースもあります。
DISM /Online /Cleanup-Image /RestoreHealth
SFC /scannow
# もしISOイメージをマウントしてソース指定をする場合
DISM /Online /Cleanup-Image /RestoreHealth /Source:D:\Sources\Install.wimまた、OSのビルドによってはインデックス付きのWIMファイル（Install.wimに複数のイメージバージョンが格納されている）を指定する必要があるため、/Index:1などのオプションを付けることも検討してください。
イベントログの詳細設定とProcess Monitorによる監視
イベントログに記録されないトラブルの場合は、Microsoft SysinternalsのProcess Monitorが強力な味方になります。Process Monitorを起動し、PowerShell実行時にどのファイルやレジストリキーにアクセスしているかをリアルタイムでモニタリングすることで、どこで「ACCESS DENIED」などのエラーが発生しているかを突き止められる可能性があります。
Process Monitorの利用手順
- Process Monitorをダウンロードし、管理者権限で実行。
- フィルタ機能を利用し、「Process Name」に「powershell.exe」または「pwsh.exe」を指定。
- PowerShellの起動を試み、アクセス拒否エラーやファイル未検出エラーが表示されないか確認。
- もし特定のレジストリキーやシステムファイルで問題が発生していれば、そのキーやファイルのアクセス権を見直す。
さらなる対策と補足情報
セキュリティソフトやグループポリシーの影響
一部のセキュリティソフトがPowerShellを脅威とみなすケースや、グループポリシー（特にAppLockerやSoftware Restriction Policies）で実行を制限しているケースが考えられます。サーバーの運用方針によってはPowerShellの実行が厳密に制御されている可能性もあるので、一時的にセキュリティソフトを無効化して症状が改善するかを確認するのも一手です。
ブルースクリーンやミニダンプが生成されない理由
パッと見では「クラッシュ」と表現される症状ですが、PowerShellプロセス単体が速やかに終了しているだけで、OS全体のクラッシュではないことがほとんどです。そのため、ブルースクリーンやミニダンプは生成されない場合が多く、本来の「クラッシュダンプ」を利用した解析は期待できません。ミニダンプがないという点だけで問題がないとは言い切れませんが、OSレベルでは「正しく終了した」として扱われる場合があります。
一時的に管理ツールの代替を用意
PowerShellが使えない場合でも、スクリプト実行などが急を要する場合は次のような方法を検討できます。
- PowerShell 7（Core）を一時的に利用
- Pythonなど別言語のスクリプトで代用
- シンプルな管理タスクならば古いコマンドプロンプトとWindows付属のコマンドで対応
本質的な解決ではありませんが、業務を止めないための一時的な対応策として有効です。
エラーコードと原因の整理
以下のような表でエラーコードを整理し、何が問題であるかを把握すると、対処法の選定がスムーズです。
| エラーコード | 意味 | 原因の可能性 |
|---|---|---|
| 0x80070005 (E_ACCESSDENIED) | アクセスが拒否された | ファイルシステムやレジストリの権限不足 |
| 0x80004005 | 一般的なエラー (未指定エラー) | 不明な要因、ファイル破損、GPO設定、ネットワーク経路問題など |
| 0x80070057 | パラメータが不正 | コマンドの誤指定、オプションの誤り |
| 0x80070002 | ファイルが見つかりません | 必要なライブラリや依存ファイルの欠落 |
PowerShellを起動するときに0x80070005がほぼ確実に出現する場合は、アクセス拒否周りに絞って検証を進めると効率的です。
まとめと推奨手順
Windows Server 2019でPowerShellを起動した際に即時にウィンドウが閉じてしまうトラブルは、OS管理者にとって大きなストレス要因となります。以下の対策を総合的に検討することで、多くの場合は解決へと導けるでしょう。
- .NET Frameworkの再インストール
- 破損やバージョン衝突を解消し、CLRエラーを除去。
- PowerShell 7 (Core)の導入
- .NET Frameworkを回避できるため、すぐに動作確認が行える。
- アクセス権の総点検
- レジストリキーやシステムディレクトリの権限、ドメインGPOの影響を調査。
- DISM/SFCの繰り返し実行とソース指定
- 同じコマンドでも複数回の実施やイメージファイルの指定で成果が得られる場合がある。
- イベントログの詳細設定やProcess Monitorの利用
- ログが記録されないときでも、Process Monitorで詳細なアクセス状況を把握。
これらを段階的に試すことで、現在抱えているPowerShellの起動直後クラッシュ問題を解決できる可能性が高まります。問題の根本原因は一つとは限らず、.NET Frameworkの破損とレジストリ権限の不具合が複合的に絡んでいるケースもあります。焦らずに一つ一つ切り分け、正常時の挙動との比較検証をしながら進めるのが最善策です。サーバー運用においてPowerShellは非常に便利なツールですので、この問題を解消し、業務効率を向上させていただければ幸いです。
コメント