How do I troubleshoot instance status check failures on my 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 using Application Migration Service for a cutover or test launch, instance status checks might fail due to one or more of the following issues:

• Failure to boot the operating system (OS)
• Network failure
• Exhausted CPU and memory
• Issues with the conversion process
• The instance type isn't compatible with the OS

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

Resolution

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

1.    Connect to your source machine.

2.    Use one of the following methods to verify your OS version:

Choose Control Panel, Systems Settings, and then check the Windows Edition and System Type to verify if it's 32 bits or 64 bits.

or

As an Administrator, run the systeminfo command in a command prompt window. The command output lists the OS Name and System Type.

3.    Verify instance type compatibility.

32-bit source machines

If your source instance is a 32-bit machine, then 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

64-bit machines

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 AWS Command Line Interface (AWS CLI) command:

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

Note: If you receive errors when running AWS CLI commands, make sure that you’re using the most recent version of the AWS CLI.

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

Troubleshooting

Turn off or remove third-party antivirus on the source machine

Third-party antivirus software might interfere with the conversion process. Turn off or remove the antivirus software, and then try the target launch again.

Attach a secondary ENI

A third-party firewall might block connectivity on the instance's primary network adapter, causing the target instance to fail status checks. To avoid this issue, attach a secondary elastic 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 AWS Elastic Network Adapter (ENA) and AWS NVME drivers. For a list of which drivers each instance type uses, see  Summary of networking and storage features.

Using the instructions in the previous section, determine if your source machine is compatible with both of the listed Windows instance types. If your source machine is compatible with both, then try launching the target using 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 to see if it succeeds. If the issue is related to the driver, then run the AWS Systems Manager Automation runbook AWSSupport-UpgradeWindowsAWSDrivers to force driver installation.

Or, troubleshoot the target launch's half status checks as any other EC2 Windows instance. For more information, see Troubleshoot instances with failed status checks.

Check the instance logs

If your new instance never passes status checks, then review the instance logs to determine a cause. The logs help you troubleshoot possible causes for the instance status check failure. All the following logs might not be present in the target instance:

• 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.

Note: Some data is lost when stopping an instance. For more information, see What happens when you stop an instance.

2.    Detach the Amazon Elastic Block Storage (Amazon EBS) root volume from the stopped instance.

3.    Attach the EBS root volume to an instance that you can access as a secondary drive, and then make it available to use.

4.    Gather the logs in the locations from the preceding list. Review the logs for possible causes of the instance status check failure.

Note: When using this method, the drive letter mapping might differ from the listed log locations because you're using a secondary drive (not C:\).

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

Related information

Troubleshoot instances with failed status checks

Systeminfo (from the Microsoft website)