How to fix this? The Virtual Machine is undergoing a reboot due to a guest OS crash

Dear Ruben,

Reboot Loop: Fixing a Virtual Machine Guest OS Crash

When your virtual machine is stuck in a reboot loop due to a guest OS crash and redeploying isn't working, the problem almost always lies within the guest operating system itself. This means you need to investigate the OS to find and fix the root cause. Here’s a straightforward guide to troubleshooting and resolving this issue.

Step 1: Analyze the Crash Information

The first step is to understand why the guest OS is crashing. This information is usually available through the virtual machine's boot diagnostics and the guest OS's own logging mechanisms.

Step 2: Common Causes and Fixes

Based on the information gathered, you can now address the likely cause.

Faulty Drivers: A recently installed or updated driver is a very common culprit. If the crash dump or BSOD points to a specific driver, you'll need to roll it back or disable it. You can often do this by booting the guest OS into Safe Mode.

Problematic Software or Updates: A recent software installation or a Windows update can sometimes cause system instability. In Safe Mode, you can try uninstalling recently added applications or Windows updates.

Corrupted System Files: System file corruption can also lead to crashes. From a command prompt in Safe Mode or a recovery environment, run the System File Checker tool: sfc /scannow. This will scan for and attempt to repair corrupt Windows system files.

Resource Exhaustion: While less common to cause a direct crash loop, insufficient CPU or memory can lead to instability. If your analysis doesn't point to a specific software issue, consider resizing the VM to a larger instance type to see if that resolves the problem.

Step 3: Advanced Recovery Options

If you can't get the VM to boot into Safe Mode or if the above steps don't work, you'll need to use more advanced recovery methods.

Use a Recovery/Installation Disk: You can often attach a Windows Server installation ISO to the virtual machine and boot from it. This will give you access to the Windows Recovery Environment, where you can access a command prompt, run startup repair, or use other recovery tools.

• Create a New VM with the Old Disk: As a last resort, you can create a new virtual machine and attach the operating system disk from the problematic VM to it. This can sometimes resolve issues related to the VM's configuration on the virtualization host. Step 2: Common Causes and Fixes Based on the information gathered, you can now address the likely cause.
  • Faulty Drivers: A recently installed or updated driver is a very common culprit. If the crash dump or BSOD points to a specific driver, you'll need to roll it back or disable it. You can often do this by booting the guest OS into Safe Mode.
  • Problematic Software or Updates: A recent software installation or a Windows update can sometimes cause system instability. In Safe Mode, you can try uninstalling recently added applications or Windows updates.
  • Corrupted System Files: System file corruption can also lead to crashes. From a command prompt in Safe Mode or a recovery environment, run the System File Checker tool: sfc /scannow. This will scan for and attempt to repair corrupt Windows system files.
  • Resource Exhaustion: While less common to cause a direct crash loop, insufficient CPU or memory can lead to instability. If your analysis doesn't point to a specific software issue, consider resizing the VM to a larger instance type to see if that resolves the problem.
  Step 3: Advanced Recovery Options If you can't get the VM to boot into Safe Mode or if the above steps don't work, you'll need to use more advanced recovery methods.
  • Use a Recovery/Installation Disk: You can often attach a Windows Server installation ISO to the virtual machine and boot from it. This will give you access to the Windows Recovery Environment, where you can access a command prompt, run startup repair, or use other recovery tools.
  • Create a New VM with the Old Disk: As a last resort, you can create a new virtual machine and attach the operating system disk from the problematic VM to it. This can sometimes resolve issues related to the VM's configuration on the virtualization host.

If you have any question feel free to ask me.

Best Regards,

---- The issue was a bug in Azure related to vTPM/VMs over some regions

Impact Statement: Starting at 04:00 UTC on 07 June 2025, you have been identified as a customer using v6 Virtual Machines (VMs) who may experience failures when attempting to start or reboot VMs with the Trusted Launch feature enabled.

The availability of your VM is affected due to a system issue with the virtual Trusted Platform Module (vTPM) attached to the VM. To restore availability, we will disable the vTPM on your impacted VM. When the vTPM is disabled for the VM, scenarios that rely on vTPM—such as attestation capabilities—will not function. Note: This disabling of vTPM will not impact secure boot operation or settings of the VM.

An investigation is underway to address the root cause affecting vTPMs, with the goal of re-enabling them for impacted VMs. We will provide further updates as more information becomes available.

---- The solution is a workaround which it is posted in Azure Portal

Alternative Workarounds:

Disable the vTPM on the VM: To resolve the issue at hand you need to disable vTPM in your Trusted Launch VM. Follow the steps below to programmatically disable vTPM in your TVM through PowerShell or CLI.

Prerequisites

• Install the Az PowerShell Module
• Log in using Connect-AzAccount
• Ensure sufficient permissions to modify VMs PowerShell Script

PowerShell Command

Set-AzContext -Subscription "your-subscription-guid"

$resourceGroupName = "your-resource-group"

$vmName = "your-vm-name"

$vm = Get-AzVM -ResourceGroupName $resourceGroupName -Name $vmName $vm.SecurityProfile = @{

UefiSettings = @{ SecureBootEnabled = $true VTpmEnabled = $false } SecurityType = "TrustedLaunch" }

Update-AzVM -ResourceGroupName $resourceGroupName -VM $vm

Azure CLI Command

az account set --subscription "your-subscription-guid"

az vm update --resource-group "your-resource-group" --name "your-vm-name" --set securityProfile.uefiSettings.vTpmEnabled=false

Azure Portal

• Sign in to the Azure portal.
• Navigate to the affected Virtual Machine resource.
• Expand Settings and go to Configuration.
• Under Security Type, uncheck the Enable vTPM checkbox.
• Click Save to apply the changes.

Notes 

Secure Boot ensures only trusted software is loaded during boot.Alternative Workarounds:

Disable the vTPM on the VM: To resolve the issue at hand you need to disable vTPM in your Trusted Launch VM. Follow the steps below to programmatically disable vTPM in your TVM through PowerShell or CLI.

Prerequisites

• Install the Az PowerShell Module
• Log in using Connect-AzAccount
• Ensure sufficient permissions to modify VMs PowerShell Script

PowerShell Command

Set-AzContext -Subscription "your-subscription-guid"

$resourceGroupName = "your-resource-group"

$vmName = "your-vm-name"

$vm = Get-AzVM -ResourceGroupName $resourceGroupName -Name $vmName $vm.SecurityProfile = @{

UefiSettings = @{ SecureBootEnabled = $true VTpmEnabled = $false } SecurityType = "TrustedLaunch" }

Update-AzVM -ResourceGroupName $resourceGroupName -VM $vm

Azure CLI Command

az account set --subscription "your-subscription-guid"

az vm update --resource-group "your-resource-group" --name "your-vm-name" --set securityProfile.uefiSettings.vTpmEnabled=false

Azure Portal

• Sign in to the Azure portal.
• Navigate to the affected Virtual Machine resource.
• Expand Settings and go to Configuration.
• Under Security Type, uncheck the Enable vTPM checkbox.
• Click Save to apply the changes.

Notes 

Secure Boot ensures only trusted software is loaded during boot.