# 到達できない Windows インスタンスをトラブルシューティングするための一般的なスクリーンショット
以下の情報を使用して、サービスによって返されたスクリーンショットに基づいて、到達不能な Windows インスタンスをトラブルシューティングすることができます。
+ [ログイン画面 (Ctrl\$1Alt\$1Delete)](#logon-screen)
+ [リカバリコンソール画面](#recovery-console-screen)
+ [Windows Boot Manager 画面](#boot-manager-screen)
+ [Sysprep 画面](#sysprep-screen)
+ [Getting Ready 画面](#getting-ready-screen)
+ [Windows 更新 画面](#windows-update-screen)
+ [Chkdsk](#Chkdsk)
## ログイン画面 (Ctrl\$1Alt\$1Delete)
コンソールスクリーンショットサービスにより以下の内容が返されました。
![\[ログイン画面\]](http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/images/ts-cs-1.png)
インスタンスがログイン時に到達不可能になった場合はネットワーク設定または Windows リモートデスクトップサービスに問題がある可能性があります。プロセスが大量の CPU を使用している場合、インスタンスも応答しない可能性があります。
### ネットワーク構成
次の情報を使用して、AWS、Microsoft Windows、およびローカル (またはオンプレミス) ネットワーク設定がインスタンスへのアクセスをブロックしていないことを確認します。
**AWS ネットワーク設定**
| 設定 | 検証 |
| --- | --- |
| セキュリティグループの構成 | ポート 3389 がセキュリティグループに対して開かれていることを確認します。適切なパブリック IP アドレスに接続していることを確認します。インスタンスが Elastic IP に関連付けられていない場合、パブリック IP アドレスはインスタンスが停止/起動した後に変更されます。詳細については[リモートデスクトップからリモートコンピュータに接続できません](troubleshoot-connect-windows-instance.md#rdp-issues)を参照してください。 |
| VPC 設定 (ネットワーク ACL) | Amazon VPC のアクセスコントロールリスト (ACL) がアクセスをブロックしていないことを確認します。詳細についてはAmazon VPC ユーザーガイドの[「ネットワーク ACL」](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html)を参照してください。 |
| VPN の設定 | 仮想プライベートネットワーク (VPN) を使用して VPC に接続している場合、VPN トンネル接続を確認します。詳細については、「[Troubleshooting AWS Client VPN: Tunnel connectivity issues to a VPC](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/VPNTunnelConnectivityTroubleshooting.html)」を参照してください。 |
**Windows ネットワーク設定**
| 設定 | 検証 |
| --- | --- |
| Windows ファイアウォール | Windows ファイアウォールがインスタンスへの接続をブロックしていないことを確認します。リモートデスクトップのトラブルシューティングセクション「[リモートデスクトップからリモートコンピュータに接続できません](troubleshoot-connect-windows-instance.md#rdp-issues)」にある 7 番目の項目で説明されている手順に従って、Windows ファイアウォールを無効にします。 |
| 高度な TCP/IP の設定 (静的 IP を使用) | 静的 IP アドレスを設定したため、インスタンスが応答しない可能性があります。VPC の場合、[ネットワークインターフェイスを作成](create-network-interface.md)して、[インスタンスにアタッチ](network-interface-attachments.md#attach_eni)します。 |
**ローカルまたはオンプレミスのネットワーク設定**
ローカルネットワーク設定がアクセスをブロックしていないことを確認します。インスタンスが到達不可能なため、同じ VPC 内の別のインスタンスに接続を試みます。別のインスタンスにアクセスできない場合、ローカルポリシーでアクセスが制限されていないかどうかをローカルネットワーク管理者に確認してください。
### リモートデスクトップサービスの問題
ログイン時にインスタンスに接続できない場合はインスタンスのリモートデスクトップサービス (RDS) に問題が存在する可能性があります。
**ヒント**
`AWSSupport-TroubleshootRDP` Runbook を使用して、リモートデスクトッププロトコル (RDP) での接続に影響を与える可能性のある各種設定をチェックし、変更します。詳細についてはAWS Systems Manager「 自動 ランブックリファレンス」の[https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-troubleshootrdp.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-troubleshootrdp.html)を参照してください。
**リモートデスクトップサービスの設定**
| 設定 | 検証 |
| --- | --- |
| RDS が実行されている | インスタンスで RDS が実行中であることを確認します。Microsoft 管理コンソールの MMC) サービススナップイン (services.msc) を使用してインスタンスに接続します。サービスのリストで、[リモートデスクトップサービス] が [実行中] であることを確認します。そうでない場合はサービスを開始し、スタートアップの種類を [自動] に設定します。サービススナップインを使用してインスタンスに接続できない場合はルートボリュームをインスタンスからデタッチして、ボリュームのスナップショットを取得するか AMI を作成し、元のボリュームを同じアベイラビリティーゾーンの別のインスタンスにセカンダリボリュームとしてアタッチして、[Start](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc959920(v=technet.10)) レジストリキーを変更します。完了したら、元のインスタンスにルートボリュームを再アタッチします。 |
| RDS が有効である | サービスが開始された場合でも、無効になることがあります。ルートボリュームをインスタンスからデタッチして、ボリュームからスナップショットを取得するか AMI を作成し、元のボリュームを同じアベイラビリティーゾーンの別のインスタンスにセカンダリボリュームとしてアタッチして、「[リモートレジストリを使用して EC2 インスタンスでリモートデスクトップを有効にする](troubleshoot-connect-windows-instance.md#troubleshooting-windows-rdp-remote-registry)」で説明されているように [**Terminal サーバー (ターミナルサーバー)**] レジストリキーを変更してサービスを有効にします。 完了したら、元のインスタンスにルートボリュームを再アタッチします。 |
### 高い CPU 使用率
Amazon CloudWatch を使用して [**CPUUtilization (Maximum)**] メトリクスを確認します。[**CPUUtilization (Maximum)**] の数値が大きい場合、CPU 使用率が低下するまで待ってから再度接続してみてください。CPU 使用率が高い理由として考えられるものを以下に示します。
+ Windows 更新
+ セキュリティソフトウェアによるスキャン
+ カスタム起動スクリプト
+ タスクスケジューラ
詳細については*Amazon CloudWatch ユーザーガイド*の[「特定のリソースの統計を取得する」](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SingleMetricPerInstance.html)を参照してください。トラブルシューティングのヒントについては[Windows の起動直後に CPU 使用率が高い (Windows インスタンスのみ)](troubleshooting-launch.md#high-cpu-issue)を参照してください。
## リカバリコンソール画面
コンソールスクリーンショットサービスにより以下の内容が返されました。
![\[リカバリコンソールのスクリーンショット\]](http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/images/ts-cs-2.png)
`bootstatuspolicy` が `ignoreallfailures` に設定されていない場合、オペレーティングシステムがリカバリコンソールで起動し、この状態でスタックする可能性があります。`bootstatuspolicy` 設定を `ignoreallfailures` に変更するには次の手順を使用します。
デフォルトではAWS が提供するパブリック Windows AMI のポリシー設定は `ignoreallfailures` に設定されています。
1. 接続できないインスタンスを停止します。
1. ルートボリュームのスナップショットを作成します。ルートボリュームが `/dev/sda1` としてインスタンスにアタッチされます。
接続できないインスタンスからルートボリュームをデタッチして、ボリュームのスナップショットを取得するか AMI を作成し、同じアベイラビリティーゾーン内の別のインスタンスにセカンダリボリュームとしてアタッチします。
**警告**
一時インスタンスと元のインスタンスが同じ AMI を使用して起動された場合、追加の手順を完了する必要があります。この手順を実行しないと、ディスク署名の競合によって、ルートボリュームを復元した後、元のインスタンスを起動できなくなります。同じ AMI を使用して一時インスタンスを作成する必要がある場合はディスク署名の競合を回避するため、[ディスク署名の衝突](win-ts-common-issues.md#disk-signature-collision) の手順を完了します。
または一時インスタンスとして別の AMI を選択してください。例えば、元のインスタンスで Windows サーバー 2016 用の AMI を使用している場合、Windows サーバー 2019 用の AMI を使用して一時インスタンスを起動します。
1. インスタンスにログインし、コマンドプロンプトから次のコマンドを実行して `bootstatuspolicy` 設定を `ignoreallfailures` に変更します。
```
bcdedit /store Drive Letter:\boot\bcd /set {default} bootstatuspolicy ignoreallfailures
```
1. ボリュームを接続できないインスタンスに再アタッチし、インスタンスを再起動します。
## Windows Boot Manager 画面
コンソールスクリーンショットサービスにより以下の内容が返されました。
![\[Windows Boot Manager 画面\]](http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/images/ts-cs-3.png)
オペレーティングシステムのファイルシステムやレジストリで致命的な破損が発生しました。インスタンスがこの状態でスタックした場合、最新のバックアップ AMI からインスタンスを復旧するか、代わりのインスタンスを起動する必要があります。インスタンスのデータにアクセスする必要がある場合、接続できないインスタンスからルートボリュームをデタッチして、それらのボリュームからスナップショットを取得するか AMI を作成し、同じアベイラビリティーゾーン内の別のインスタンスにセカンダリボリュームとしてアタッチします。
## Sysprep 画面
コンソールスクリーンショットサービスにより以下の内容が返されました。
![\[Sysprep 画面\]](http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/images/ts-cs-4.png)
この画面はSysprep の呼び出しに EC2Config サービスを使用していない場合、または Sysprep の実行中にオペレーティングシステムでエラーが発生した場合に表示されることがあります。パスワードは[EC2Rescue](Windows-Server-EC2Rescue.md) を使用してリセットすることが可能です。・ それ以外の場合は[Windows Sysprep を使用して Amazon EC2 AMI を作成する](ami-create-win-sysprep.md)を参照してください。
## Getting Ready 画面
コンソールスクリーンショットサービスにより以下の内容が返されました。
![\[Getting Ready 画面\]](http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/images/ts-cs-5.png)
インスタンスコンソールスクリーンショットサービスを繰り返し更新し、進捗状況のリングが回っていることを確認します。リングが回っている場合、オペレーティングシステムが起動するまで待ちます。Amazon CloudWatch を使用してオペレーティングシステムがアクティブであるかどうかを確認することにより、インスタンスの [**CPUUtilization (Maximum)**] メトリクスも確認します。進行状況のリングが回っていない場合、インスタンスは起動プロセス中にスタックしている可能性があります。インスタンスを再起動します。再起動で問題を解決できない場合はインスタンスを最新のバックアップ AMI から復旧するか、代わりのインスタンスを起動します。インスタンス上のデータにアクセスする必要がある場合、ルートボリュームを接続できないインスタンスからデタッチし、ボリュームのスナップショットを取得するか、AMI を作成します。その後、同じアベイラビリティーゾーン内の別のインスタンスにセカンダリボリュームとしてアタッチします。
## Windows 更新 画面
コンソールスクリーンショットサービスにより以下の内容が返されました。
![\[Windows 更新 画面\]](http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/images/ts-cs-6.png)
Windows 更新 プロセスがレジストリを更新中です。更新が終了するまで待機してください。更新時にデータが破損する可能性があるため、インスタンスを再起動したり停止したりしないでください。
**注記**
Windows 更新 プロセスは更新中のサーバーのリソースを消費することがあります。この問題が頻繁に発生する場合、高速なインスタンスタイプと高速な EBS ボリュームを使用することを検討します。
## Chkdsk
コンソールスクリーンショットサービスにより以下の内容が返されました。
![\[Chkdsk 画面。\]](http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/images/ts-cs-7.png)
Windows がドライブで chkdsk ツールを実行し、ファイルシステムの完全性を確認し、論理的なファイルシステムのエラーを修正しています。プロセスが完了するまで待ちます。