1. Must obtain parameters first — Instance ID and Region ID are required. Must ask user if missing.
2. Standard workflow cannot be skipped — Must execute in order: Maintenance Event Check → OSType Detection → System Log Check
3. Must check Cloud Assistant status before diagnostics — Before executing Step 3A/3B, must verify Cloud Assistant is running via

   DescribeCloudAssistantStatus

   . If not running, provide alternative diagnostic approaches.
4. All diagnostic conclusions must be based on actual data — No fabrication, speculation, or assumptions
5. Output format must be strictly followed — After diagnosis, must read the complete template in

   references/output-format.md

   , output strictly according to template structure. No free-form output, no omitted sections, no changed hierarchy. Every placeholder

   {...}

   in the template must be filled with actual data.

• aliyun-cli 3.3.3+ (required) — For calling Alibaba Cloud API
• Installation & configuration: see CLI Installation Guide

• Cloud Assistant client must be installed and running on the instance
  • Alibaba Cloud Linux: Pre-installed by default
  • Ubuntu/CentOS/Other: May require manual installation, check with

    DescribeCloudAssistantStatus

    API
  • Installation guide: https://help.aliyun.com/document_detail/64930.html
• Instance status must be Running
• Note: If Cloud Assistant is not running, diagnostic commands cannot be executed remotely. Must provide manual diagnostic steps to user.

aliyun ecs describe-instances \
  --biz-region-id <REGION_ID> \
  --region <REGION_ID> \
  --instance-ids '["<INSTANCE_ID>"]'

• RegionId

  — Region ID (matches user provided)

• Status

  — Instance status (Running/Stopped)

• InstanceName

  — Instance name

• OSType

  — Operating system type (windows / linux)

aliyun ecs describe-instance-history-events \
  --biz-region-id <REGION_ID> \
  --region <REGION_ID> \
  --instance-id <INSTANCE_ID> \
  --event-cycle-status Executed

SystemMaintenance.Reboot

SystemFailure.Reboot

InstanceFailure.Reboot

InstanceExpiration.Stop

• This event indicates the platform detected an instance-level anomaly and triggered automatic recovery
• Common causes: kernel panic, OOM, system hang, critical process failure
• Must execute Step 3 to check system logs for root cause
• Even if no obvious errors in logs, the instance may have been unresponsive at kernel level

• Clearly inform user of reboot cause (event type, time, reason)
• Provide handling suggestions
• End diagnosis flow

• Continue to Step 3, check internal system logs based on OSType

aliyun ecs describe-cloud-assistant-status \
  --biz-region-id <REGION_ID> \
  --region <REGION_ID> \
  --instance-id <INSTANCE_ID>

{
  "InstanceCloudAssistantStatusSet": {
    "InstanceCloudAssistantStatus": [
      {
        "InstanceId": "i-xxx",
        "RegionId": "cn-xxx",
        "CloudAssistantStatus": "true",
        "LastHeartbeatTime": "2026-04-09T07:26:58Z"
      }
    ]
  }
}

• CloudAssistantStatus

  is a string ("true"/"false"), not boolean
• Check

  LastHeartbeatTime

  to ensure it's recent (within last few minutes)
• Even if status is "true", RunCommand may still fail if service is unstable
• Always check RunCommand execution result and handle failures gracefully
• Ubuntu vs RHEL differences:
  • RHEL/CentOS/Alibaba Cloud Linux: Service name is

    kdump

    , crash files named

    vmcore-*

  • Ubuntu/Debian: Service name is

    kdump-tools

    , crash files named

    dump.*

    and

    dmesg.*

  • Diagnostic script now checks both service names and all crash file types

• Cloud Assistant is not installed or not running on the instance
• Cannot proceed with remote diagnostic commands
• Alternative approaches:
  1. Guide user to SSH into the instance and check logs manually
  2. Provide manual diagnostic commands for user to execute
  3. Suggest installing Cloud Assistant: Installation Guide
  4. Check instance monitoring data via CloudMonitor API

• Proceed to Step 3A.2

• System reboot records (

  last reboot

  ,

  /var/log/messages

  or

  /var/log/syslog

  )
• Kernel Panic records (

  dmesg

  )
• OOM records and

  vm.panic_on_oom

  configuration
• Kdump configuration and crash dump file status
• Crash dump files: vmcore (RHEL/CentOS) or dump./dmesg. (Ubuntu/Debian)

/proc/sysrq-trigger

aliyun ecs describe-cloud-assistant-status \
  --biz-region-id <REGION_ID> \
  --region <REGION_ID> \
  --instance-id <INSTANCE_ID>

• CloudAssistantStatus: true

  — Cloud Assistant is running, proceed to Step 3B.2

• CloudAssistantStatus: false

  — Cloud Assistant is not running
  • Cannot proceed with remote diagnostic commands
  • Guide user to SSH/RDP into instance and run diagnostics manually
  • Suggest reinstalling Cloud Assistant: Windows Installation Guide

• System uptime and unexpected shutdown events (Event ID 41, 1074, 6008, 6006)
• Memory dump configuration and pagefile settings
• MEMORY.DMP and minidump files existence
• BSOD events and application crashes

RunCommand

aliyun ecs describe-invocations \
  --biz-region-id <REGION_ID> \
  --region <REGION_ID> \
  --instance-id <INSTANCE_ID> \
  --invoke-id <INVOKE_ID>

• Use

  --instance-id

  (not

  --instance-id.1

  ) for describe-invocations API
• The

  InvokeId

  is returned by the

  RunCommand

  API call
• Decode the

  Output

  field from Base64 to get diagnostic results
• Check

  InvokeStatus

  to ensure command execution completed successfully

Important: If Linux vmcore files need deep analysis or Windows dump files (MEMORY.DMP/minidump) are found, recommend the user contact Alibaba Cloud technical support team for professional crash dump analysis assistance.

• Kernel panic records found in dmesg or system logs, but

  /var/crash

  has no vmcore files
• Kdump service status shows

  inactive

  or

  failed

• /proc/cmdline

  does not contain

  crashkernel=

  parameter

1. Why Kdump is needed: Without Kdump, kernel crashes will not generate vmcore files, making root cause analysis impossible.
2. Configuration requirements:
   • Reserve memory for crash kernel via

     crashkernel=

     kernel parameter
   • Enable and start the kdump (RHEL/CentOS) or kdump-tools (Ubuntu/Debian) service
   • Ensure sufficient disk space in

     /var/crash

     (or configured path)
3. Configuration reference: Provide guidance from diagnostic-commands.md

1. Install:

   yum install -y kexec-tools

2. Add

   crashkernel=auto

   to kernel parameters in

   /etc/default/grub

3. Run

   grub2-mkconfig -o /boot/grub2/grub.cfg

4. Reboot the instance
5. Enable:

   systemctl enable --now kdump

1. Install:

   apt-get install -y kdump-tools

2. Set

   USE_KDUMP=1

   in

   /etc/default/kdump-tools

3. Run

   update-grub

   (crashkernel parameter usually auto-added)
4. Reboot the instance
5. Verify:

   systemctl status kdump-tools

1. Verify pagefile is configured and has sufficient size
2. Enable memory dump: System Properties → Advanced → Startup and Recovery → Settings
3. Select "Automatic memory dump" or "Kernel memory dump"
4. Ensure

   CrashDumpEnabled

   registry value is not 0

1. Read

   references/output-format.md

   — Get complete output format template
2. Output strictly according to template structure — Choose corresponding template based on actual result

• Output Format — Diagnostic result output template
• Common Scenarios — Typical problem diagnosis examples
• Diagnostic Commands — Complete diagnostic scripts and analysis commands