Azure Resource Health reports “Host server crashed/reboot” with cause Platform Initiated.

Question

Azure Resource Health reports “Host server crashed/reboot” with cause Platform Initiated.

Geoff HACK 0

We are experiencing repeated Azure platform‑initiated host failures on an Azure Virtual Desktop session host. Azure Resource Health reports “Host server crashed/reboot” with cause Platform Initiated. After these events the VM becomes unreachable; in some cases it cannot be restarted and requires deletion, in others it requires recovery via Serial Console. This has occurred multiple times during off‑hours on Standard DC4ds v3 VMs.

Failure occured:

14/04 - 15/04

21/04 - 22/04

Region : UK South

VM Type: Standard DC4ds v3

We need support from Microsoft because:

Resource Health event
Cause = Platform Initiated
Host crash explicitly stated
Repeated occurrences
Evidence of partial vs failed recovery

Activity Log JSON

Activity Log 2026/04/23 21:10

{

"channels": "Operation",

"correlationId": "2e07d9bc-8154-400b-b84c-a0570c4d6af5",

"description": "",

"eventDataId": "5136c7b9-8e55-6e51-6fd5-f11ef87273e0",

"eventName": {

"value": "",

"localizedValue": ""

},

"category": {

"value": "ResourceHealth",

"localizedValue": "Resource Health"

},

"eventTimestamp": "2026-04-23T19:10:51Z",

"id": "/SUBSCRIPTIONS/046E117E-20B2-4C60-94F5-A6C6D4DDE5F0/RESOURCEGROUPS/LI-AZURE-RESOURCE-GROUP/PROVIDERS/MICROSOFT.COMPUTE/VIRTUALMACHINES/BE009-PRD-1/events/5136c7b9-8e55-6e51-6fd5-f11ef87273e0/ticks/639125682510000000",

"level": "Informational",

"operationId": "",

"operationName": {

"value": "Microsoft.Resourcehealth/healthevent/Updated/action",

"localizedValue": "Health Event Updated"

},

"resourceGroupName": "LI-AZURE-RESOURCE-GROUP",

"resourceProviderName": {

"value": "MICROSOFT.COMPUTE",

"localizedValue": "MICROSOFT.COMPUTE"

},

"resourceType": {

"value": "MICROSOFT.COMPUTE/virtualmachines",

"localizedValue": "MICROSOFT.COMPUTE/virtualmachines"

},

"resourceId": "/SUBSCRIPTIONS/046E117E-20B2-4C60-94F5-A6C6D4DDE5F0/RESOURCEGROUPS/LI-AZURE-RESOURCE-GROUP/PROVIDERS/MICROSOFT.COMPUTE/VIRTUALMACHINES/BE009-PRD-1",

"status": {

"value": "Updated",

"localizedValue": "Updated"

},

"subStatus": {

"value": "",

"localizedValue": ""

},

"submissionTimestamp": "2026-04-23T19:10:51Z",

"subscriptionId": "046E117E-20B2-4C60-94F5-A6C6D4DDE5F0",

"tenantId": "",

"properties": {

"title": "Host server crashed/reboot",

"details": "The Virtual Machine has unexpectedly crashed due to the underlying host server experiencing software failure or due to a failed hardware component. While the Virtual Machine is rebooting, the local data remains unaffected.",

"currentHealthStatus": "Available",

"previousHealthStatus": "Available",

"type": "Downtime",

"cause": "PlatformInitiated"

},

"relatedEvents": []

}

0 opmerkingen

1 antwoord

Uw antwoord

Answer 1

Hi Geoff HACK,

It's a severe underlying fault within the localized Azure fabric in the UK South region. Because these confidential compute virtual machines rely on specialized hardware with Intel SGX enclaves to protect data in use, a critical failure at the physical host or hypervisor level instantly severs the virtual machine state. This sudden termination is exactly why your instances are failing to start gracefully afterward and require serial console intervention, as the abrupt halt can leave the secure boot environment or virtual Trusted Platform Module in an inconsistent state. Once you manage to recover the operating system, inspecting the System event log located at C:\Windows\System32\winevt\Logs\System.evtx will likely reveal Event ID 41 or Event ID 6008, confirming the ungraceful power loss from the perspective of the guest operating system.

To mitigate this, you must initiate a Redeploy operation directly from the virtual machine blade in the Azure portal. This specific command forces the Azure control plane to deallocate your instance and provision it onto a completely different, healthy physical node within the datacenter. Moving the virtual machine away from the degraded hardware allows you to retain your existing managed disks and network configuration while bypassing the localized rack failure causing these off-hours disruptions.

While redeployment secures your immediate uptime, the frequency of these failures requires intervention from the Microsoft backend infrastructure team. You will need to open a high-severity technical support ticket from the Azure portal and provide the correlation ID 2e07d9bc-8154-400b-b84c-a0570c4d6af5 along with the event data ID 5136c7b9-8e55-6e51-6fd5-f11ef87273e0 from your activity log. These exact identifiers act as direct database keys that allow the support engineers to query the backend Service Fabric telemetry, confirm the hardware degradation, and quarantine the failing physical nodes to prevent further outages.

Hope this answer brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

VP