How do I troubleshoot an EC2 instance stuck in a reboot loop after installing Windows updates?
Last updated: 2021-07-22
I installed Windows updates on my Amazon Elastic Compute Cloud (Amazon EC2) instance. Now my instance is stuck in a reboot loop. How can I fix this?
To correct this issue, revert the pending actions, such as Windows updates, that are scheduled to be applied during the OS boot process. Use a rescue instance that is in the same Availability Zone as the original instance to do this.
Note: It's a best practice to maintain backups of your instances and data. Before you perform the steps in the Resolution section, consider creating an AMI or creating snapshots of your Amazon EBS volumes.
This procedure requires a stop and start of the instance. Be aware of the following:
- If your instance is instance store-backed or has instance store volumes containing data, then the data is lost when the instance is stopped. For more information, see Determine the root device type of your instance.
- If your instance is part of an Amazon EC2 Auto Scaling group, then stopping the instance might terminate it. Instances launched with Amazon EMR, AWS CloudFormation, AWS Elastic Beanstalk might be part of an AWS Auto Scaling group. Instance termination in this scenario depends on the instance scale-in protection settings for your Auto Scaling group. If your instance is part of an Auto Scaling group, temporarily remove it from the Auto Scaling group before starting the resolution steps.
- Stopping and starting the instance changes the public IP address of your instance. It's a best practice to use an Elastic IP address instead of a public IP address when routing external traffic to your instance.
For more information, see Overview: Stop and start your instance.
1. Open the Amazon EC2 console.
2. Select Instances, and then select the instance that is in a reboot loop.
4. Detach the root volume from the instance. The device name for a root volume on Windows instances is /dev/sda1.
5. Launch a new EC2 instance in same Availability Zone as the impaired instance. The new instance becomes your rescue instance. You can also use an existing instance that is in the same Availability Zone as the rescue instance.
Note: Rescue instances based on the same AMI as the original instance might encounter disk signature collision issues. It's a best practice to select a different AMI for the rescue instance. For example, if the original instance uses an AMI for Windows Server 2012 R2, then launch the rescue instance using an AMI for Windows Server 2016. If you must create the rescue instance from the same AMI as the original instance, then you must perform additional steps to avoid a disk signature collision. For more information, see Step 6 in the Manual steps section of Remote Desktop can't connect to the remote computer.
6. Attach the root volume you detached in step 4 to the rescue instance as a secondary volume. The device name of the volume is auto-completed as secondary volume naming when attaching it to the instance.
7. Connect to the rescue instance using Remote Desktop Protocol (RDP). Then bring the newly attached volume online from Disk Management or using the DiskPart Command line tool. If you don't see the newly attached volume, see Why isn't my attached EBS volume showing in my OS or in Disk Management on my EC2 Windows instance?
Note: Note the drive letter of the secondary volume. In the following example, the drive letter is E.
8. Open Command Prompt or PowerShell as an Administrator and run the following command:
DISM /image:E:\ /cleanup-image /revertpendingactions
Note: Replace the drive letter E: with the drive letter noted from Step 7.
10. Attach the volume back to original instance as a root volume (/dev/sda1).