For the last week my Azure Windows VM has unexpected shutdowns in the evenings

Question

For the last week my Azure Windows VM has unexpected shutdowns in the evenings

Lorenzo Capodiferro 0

This is the issue below. How can this be fixed?

VM Availability

The Azure monitoring and diagnostics systems have identified that your VM Exports became unavailable at 2026-07-23 09:00:00 (UTC). During this time, RDP and SSH connections to the VM, or requests to any other services running inside the VM, could have failed.

Root Cause

This unexpected occurrence was caused by a crash in the guest operating system of your VM. To prevent memory and disk data corruption, the guest operating system stops execution when it detects a serious error condition. This condition can occur for many reasons, including the following:

A memory address that causes an access violation

An unexpected exception or trap

A faulty kernel mode driver

VarunTha 15,090 Reputation points Microsoft External Staff Moderator

2026-07-23T23:46:44.5933333+00:00
Hey Lorenzo Capodiferro — sorry you’re seeing this. Based on what you pasted (“unexpected occurrence was caused by a crash in the guest operating system… [to] prevent memory and disk data corruption, the guest OS stops execution…”), the reboot/shutdown is coming from inside the VM (a Windows guest crash), not necessarily from an Azure host issue.

Here are the most effective things to check and what you can do next.

1) Confirm Azure didn’t trigger the downtime (host/maintenance/user action)

Even though the message points to a guest crash, it’s still worth validating the platform side first:

In the Azure portal, review Activity Log for the subscription around the shutdown time to see if there were any events like maintenance, host failure, or other platform/user actions.

Also check Resource Health (and the diagnostics/VM availability view if available) to confirm whether Azure reported an availability event for the VM at that time.

2) Use the built-in RCA / diagnostics for unexpected VM reboots

Microsoft provides a portal workflow specifically for this scenario:

Go to the affected VM in the Azure portal

Select Diagnose and solve problems → Common problems → VM restarted or stopped unexpectedly

Run the VM restarted or stopped unexpectedly diagnostics and review the Root Cause Analysis (RCA) and suggested actions.

This is the fastest way to correlate the downtime with platform vs guest signals.

3) Investigate the Windows guest crash (this is likely the real root cause)

Because your portal message explicitly says it was a guest OS crash, you should collect Windows crash evidence:

Check Windows Event Viewer logs on the VM for shutdown/restart/crash indicators around the time it happens.

If crash dumps are available (or can be generated), analyze them to find the failing component (commonly a kernel-mode driver or other system component).

The “Unexpected VM reboot - root cause analysis” documentation walks through the steps and recommended data collection for unexpected reboots.

4) If the problem repeats: collect dumps and verify storage/driver health

The guest crash can be triggered by many items (for example: a faulty kernel-mode driver, access violation, unexpected exceptions). For recurring incidents:

Collect memory/OS crash dump evidence (if available)

Check for related driver/software errors preceding the crash

Also review anything affecting stability (storage drivers, critical updates, etc.) and ensure system components are healthy

If you want a “do-this-now” baseline, start with RCA in the portal, then Event Viewer + dump analysis on the guest.

5) If the VM is being impacted by Azure host faults (fallback)

If the diagnostics/RCA shows it was an Azure host/auto-recovery style issue, then the common remediation is to redeploy the VM onto a healthy node (Azure has an explicit redeploy/recovery workflow).

That said: your current text is more aligned with a guest crash, so I’d treat that as primary until the RCA says otherwise.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

3 answers

Your answer

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Answer 1

Hello @Lorenzo Capodiferro,

Thank you for using Q & A forum.

vTPM is configured as part of Trusted Launch.

Trusted Launch overview: https://learn.microsoft.com/azure/virtual-machines/trusted-launch

Deploy a VM with Trusted Launch enabled: https://learn.microsoft.com/azure/virtual-machines/trusted-launch-portal

Enable vTPM on an existing Azure VM

Stop/deallocate the VM.

Open the VM in the Azure portal.

Go to Security.

Set Security type to Trusted Launch.

Enable:

vTPM

Secure Boot (if supported by your OS/workload)

Save and start the VM.

If this answers your query, do click Accept Answer and Up-Vote for the same. And, if you have any further query do let us know.

Answer 2

Lorenzo Capodiferro 0

I found the problem. vTPM had an error and crashed the VM. I have disabled it for now.

Where can I find instructions to set vTPM up ?

VarunTha 15,090 Reputation points Microsoft External Staff Moderator

2026-07-26T23:49:13.73+00:00
Hello Lorenzo,

Thank you for the update. I’m glad you were able to stabilise the VM by temporarily disabling vTPM.

vTPM is configured as part of Azure Trusted Launch. For an existing supported Generation 2 VM, stop the VM, open Configuration, select Trusted launch as the security type, enable vTPM, save the changes, and then start the VM. Microsoft recommends confirming that the VM size, operating system, image, and backup configuration support Trusted Launch before making the change.

Please refer to the following official Microsoft documentation:

Enable Trusted Launch on an existing Gen2 VM

Trusted Launch overview

Deploy a VM with Trusted Launch

As this is a production VM and the crashes stopped after disabling vTPM, I recommend creating a restore point and testing the change during a maintenance window. If the VM crashes again after vTPM is enabled, please collect the exact UTC timestamp, relevant Windows event logs, and the memory dump so the failing guest component can be identified. Microsoft also recommends validating Trusted Launch on a test VM and creating restore points before enabling it on production workloads.

Answer 3

Azure’s diagnosis identifies a guest operating-system crash, so the next step is to capture evidence inside the VM rather than treating this as a host outage. Check Boot Diagnostics and Resource Health for each incident time, then review the Windows System event log for BugCheck, WHEA, disk, storage-filter, and unexpected-shutdown events. Confirm that Windows is configured to write a kernel or complete memory dump and that the page file and dump destination have sufficient space. Install supported Windows, VM-agent, storage, network, and security-driver updates, prioritizing anything introduced shortly before the crashes. Avoid repeated redeployments until a dump is collected, because they can restore availability without identifying the faulty driver or component. If another crash occurs, preserve the dump and exact UTC timestamp. Escalate to Microsoft support with the dump, Resource Health history, Boot Diagnostics, and recent-change timeline if the cause is not evident.

For the last week my Azure Windows VM has unexpected shutdowns in the evenings

Root Cause

1) Confirm Azure didn’t trigger the downtime (host/maintenance/user action)

2) Use the built-in RCA / diagnostics for unexpected VM reboots

3) Investigate the Windows guest crash (this is likely the real root cause)

4) If the problem repeats: collect dumps and verify storage/driver health

5) If the VM is being impacted by Azure host faults (fallback)

3 answers

Your answer