How do I troubleshoot instance status check failures on my Amazon EC2 Windows instance after an Application Migration Service cutover or test launch?

Short description

When a system or instance status check fails, EC2 instances become unreachable. After you use Application Migration Service for a cutover or test launch, instance status checks might fail because of the following issues:

• Failure to boot the operating system (OS)
• Network failure
• Exhausted CPU and memory
• Issues with the conversion process
• Instance types that aren't compatible with the OS

Note: The first boot of Windows machines might take up to 45 minutes as Windows adjusts to the AWS virtual hardware.

Resolution

Note: If you receive errors when you run AWS Command Line Interface (AWS CLI) commands, then see Troubleshooting errors for the AWS CLI. Also, make sure that you're using the most recent AWS CLI version.

Verify that the source machine is compatible with the instance type that you selected in the launch template

Connect to your source machine, and then use one of the following methods to verify your OS version:

Choose Control Panel, and then choose Systems Settings. Check the Windows Edition and System Type to check whether the OS is 32 bits or 64 bits.

Or, as an administrator, run the following command in a command prompt window:

systeminfo

The command output lists the OS Name and System Type.

If your source machine is 32 bit, then you must use one of the following instance types:

• t2.nano
• t2.micro
• t2.small
• t2.medium
• c3.large
• t1.micro
• m1.small
• m1.medium
• c1.medium

If your source machine is 64 bit and runs Windows Server 2008 R2 or later, then you can use any instance type.

If your source machine is 64 bit and runs one of the following Windows editions, then migrate to a XEN instance type:

• Windows Server 2003
• Windows Server 2003 R2
• Windows Server 2008

For a full list of XEN instance types, run the following describe-instance-types AWS CLI command:

aws ec2 describe-instance-types --filters Name=hypervisor,Values=xen --query InstanceTypes[].InstanceType

Deactivate or remove third-party antivirus on the source machine

Third-party antivirus software might interfere with the conversion process. Deactivate or remove the antivirus software, and then relaunch the instance.

Attach a secondary elastic network interface

A third-party firewall might block connectivity on the instance's primary network adapter. This causes the target instance to fail status checks. To avoid this issue, attach a secondary network interface to the target instance, and then connect to the instance.

Use different instance types

XEN instances use paravirtual drivers (PVs), and Nitro instances use Elastic Network Adapter (ENA) and AWS NVMe drivers. For a list of the drivers that each instance type uses, see Compatibility for changing the instance type.

If your source machine is compatible with both XEN and Nitro, then launch a XEN instance and a Nitro instance. If the target instance passes status checks as one instance type but not as the other, then resize the instance. Check whether the resized instance passes its status checks.

If the issue is related to the driver, then run the AWSSupport-UpgradeWindowsAWSDrivers automation runbook to force driver installation.

Check the instance logs

Important: Before you stop and start your instance, take the following actions:

• Create a snapshot of your Amazon Elastic Block Store (Amazon EBS) volume.
  Note: If your instance is instance store-backed or has instance store volumes that contain data, then Amazon EC2 deletes the data when you stop the instance.
• Temporarily remove the instance from its Amazon EC2 Auto Scaling group.
  Note: If you stop an instance that's in an Amazon EC2 Auto Scaling group, then you might terminate the instance based on your scale-in protection settings. Instances that you launch with Amazon EMR, AWS CloudFormation, or AWS Elastic Beanstalk might be in an Auto Scaling group.
• Set the instance shutdown behavior to Stop to make sure that the instances don't terminate when you stop them.

Note: When you stop and start an instance, the instance's public IP address changes. It's a best practice to use an Elastic IP address to route external traffic to your instance instead of a public IP address.

If your new instance never passes status checks, then check the following instance logs to determine a cause:

• C:\Program Files (x86)\AWS Replication Agent\migrate_script.log
• C:\Program Files (x86)\AWS Replication Agent\migrate_script.log.sent
• C:\Program Files (x86)\AWS Replication Agent\aws_nvme\awsnvme_dism.log
• C:\Program Files (x86)\AWS Replication Agent\ena_2012R2_2016\ena_dism.log
• C:\Program Files (x86)\AWS Replication Agent\PVinstall.log
• C:\Windows\inf\setupapi.dev.log
• C:\Windows\inf\setupapi.offline.log
• C:\Program Files (x86)\AWS Replication Agent\SSMInstall.log

To access the logs, complete the following steps:

1. Stop the target instance.
2. Detach the root EBS volume from the stopped instance.
3. Attach the EBS root volume to an instance that you can access as a secondary drive.
4. Make the EBS volume available to use.
5. Gather the logs from the preceding locations, and then review them for possible causes of the instance status check failure.
   Note: You might not have all of the preceding logs present on the target instance. When you use this method, the drive letter mapping might differ from the listed log locations because you use a secondary drive instead of C:\.

If the preceding troubleshooting steps don't resolve the issue, then create a support case.

Related information

systeminfo on the Microsoft website

Troubleshoot issues with Amazon EC2 instances