Merge pull request #1842 from justingross-msft/patch-1

Update understand-vm-reboot.md

Author: AmandaAZ

support/azure/virtual-machines/windows/understand-vm-reboot.md

@@ -10,9 +10,9 @@ ms.service: azure-virtual-machines
 ms.topic: troubleshooting
 ms.tgt_pltfrm: na
 ms.workload: infrastructure-services
-ms.date: 10/14/2024
+ms.date: 05/26/2025
 ms.author: genli
-ms.reviewer: yutorigo, sinhamanisha, v-weizhu
+ms.reviewer: yutorigo, sinhamanisha, justingross, v-weizhu
 ms.custom: sap:VM restarted or stopped unexpectedly
 ---
 # Understand a system reboot for Azure VM
@@ -98,13 +98,13 @@ The VM is hosted on a physical server that is running inside an Azure datacenter
 
 Server faults are usually caused by hardware failure, such as the failure of a hard disk or solid-state drive. Azure continuously monitors these occurrences, identifies the underlying bugs, and rolls out updates after the mitigation has been implemented and tested.
 
-Because some host server faults can be specific to that server, a repeated VM reboot situation might be improved by manually redeploying the VM to another host server. This operation can be triggered by using the **redeploy** option on the details page of the VM, or by stopping and restarting the VM in the Azure portal.
+Because some host server faults can be specific to that server, a repeated VM reboot situation might be improved by manually redeploying the VM to another host server. This operation can be triggered by using the [redeploy](redeploy-to-new-node-windows.md#use-the-azure-portal) option on the details page of the VM, or by stopping and restarting the VM in the Azure portal.
 
 ### Auto-recovery
 
-The Azure platform is designed to handle host node issues with minimal impact on VM performance. When a host node encounters a problem, Azure first attempts the least disruptive recovery method, which is to reboot the host. If rebooting the host isn't possible or if the original issue is hardware-related, the platform service heals all VMs on the affected host to a healthy node. While rebooting a host generally has a lower impact, service healing VMs can be more complex and time-consuming, depending on the number of VMs, their deployment constraints, and local resource availability. Service healing is typically used as a last resort for hardware failures because it ensures that VMs continue to operate without significant downtime.
+The Azure platform is designed to handle host node issues with minimal impact on VM performance. When a host node encounters a problem, Azure first attempts the least disruptive recovery method, which is to reboot the host. If rebooting the host isn't possible or the issue is hardware-related, Azure initiates an automatic recovery action to take the faulty host out of rotation for further investigation. As part of this automatic recovery, a process known as service healing will automatically relocate all VMs on the faulty host to another healthy one. This process is usually completed within 15 minutes, although the recovery time can vary depending on factors such as the host's memory size and recovery methods used. Service healing is typically used as a last resort for hardware failures to ensure that VMs continue to operate without significant downtime.
 
-If a host server can't reboot, Azure initiates an automatic recovery action to take the faulty host out of rotation for further investigation. During this auto-recovery process, all VMs on the host are automatically relocated to another healthy host server. While this process usually completes within 15 minutes, the recovery time can vary based on factors such as the host's memory size and the recovery methods used. For more details about how Azure handles these scenarios, see [Service Healing – Auto-recovery of Virtual Machines](https://azure.microsoft.com/blog/service-healing-auto-recovery-of-virtual-machines/).
+For more details about how Azure handles these scenarios, see [Service Healing – Auto-recovery of Virtual Machines](https://azure.microsoft.com/blog/service-healing-auto-recovery-of-virtual-machines/).
 
 ### Unplanned maintenance
 
@@ -117,7 +117,12 @@ Unplanned maintenance include the following:
 
 ### VM crashes
 
-VMs might restart because of issues within the VM itself. The workload or role that's running on the VM might trigger a bug check within the guest operating system. For help determining the reason for the crash, view the system and application logs for Windows VMs, and the serial logs for Linux VMs.
+VMs might restart due to internal VM issues or hardware issues, such as an OS disk issue, as described earlier. The workload or role running on the VM might trigger a bug check in the guest OS. To find the reason for the crash, check the system and application logs for Windows VMs and the serial logs for Linux VMs. Collecting a memory dump is usually the best way to identify the root cause.
+
+For more information, see the following articles:
+
+- [Windows crash dump information](../../..//windows-server/performance/memory-dump-file-options.md)
+- [Linux crash dump information](../linux/serial-console-nmi-sysrq.md#distribution-specific-documentation)
 
 ### Storage-related forced shutdowns
 
@@ -127,8 +132,8 @@ VMs in Azure rely on virtual disks for operating system and data storage that is
 
 In rare circumstances, a widespread issue can affect multiple servers in an Azure datacenter. If this issue occurs, the Azure team sends email notifications to the affected subscriptions. You can check the [Azure Service Health dashboard](https://azure.microsoft.com/status/) and the Azure portal for the status of ongoing outages and past incidents.
 
-## Diagnose VM Restarts
+## Diagnose VM restarts
 
-You can use the Diagnose and Solve blade on the VM blade to run additional diagnostics. This may uncover more specific reasons for your recent VM restart. If there is any Guest OS issue, collect memory dump and contact support.
+You can use the **Diagnose and Solve** blade on the VM blade to run additional diagnostics. This may uncover more specific reasons for your recent VM restart. If there is any guest OS issue, collect a memory dump and contact support.
 
 [!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)]