Windows VM experiences unexpected shutdown and generates a memory dump
search cancel

Windows VM experiences unexpected shutdown and generates a memory dump

book

Article ID: 427508

calendar_today

Updated On:

Products

VMware vCenter Server

Issue/Introduction

  • A Windows virtual machine shuts down unexpectedly without administrator intervention
  • Windows displays a blue screen (BSOD) before restarting or shutting down
  • A memory dump file is generated in the guest OS (for example, MEMORY.DMP or a minidump in C:\Windows\Minidump)
  • In vCenter or the ESXi host client, you see an event similar to: 
    Guest operating system has crashed.
  • The VM may be found in a powered off or suspended state

Additional symptoms reported:

  • VM crashed unexpectedly
  • Windows Server experienced an unexpected shutdown
  • Guest OS crash detected in vCenter events

Environment

  • VMware vSphere ESXi 7.x
  • VMware vSphere ESXi 8.x
  • Windows guest operating system

Resolution

When a Windows VM crashes unexpectedly, the crash can originate from either the guest operating system or the virtualization layer. Use the following steps to identify the source and determine the appropriate resolution path.

Step 1: Collect diagnostic data

  1. Collect the Windows memory dump from the guest OS. The default location is C:\Windows\MEMORY.DMP or C:\Windows\Minidump\.
  2. Collect the VM's vmware.log file from the VM directory on the datastore.
  3. If hypervisor involvement is suspected, collect an ESXi support bundle from the host where the VM was running at the time of the crash.

Step 2: Determine the crash origin

Use the methodology in Windows VM crash investigation: How to use vmware.log to determine crash origin to determine whether the crash originated from the guest OS or the hypervisor.

Step 3: Follow the appropriate resolution path

If the crash originated within the guest OS:

  1. Engage Microsoft Support or use Windows debugging tools to analyze the memory dump.
  2. Review Windows Event Viewer for errors preceding the crash.
  3. Check for recently installed drivers, updates, or software changes.
  4. Verify the guest OS is fully patched and VMware Tools is up to date.

If the crash was triggered by the hypervisor or virtual hardware:

  1. Collect an ESXi support bundle if not already collected.
  2. Review vmkernel.log for errors related to storage, memory, or CPU near the crash time.
  3. Check for pending ESXi and server firmware updates.
  4. Open a case with Broadcom Support for further analysis.

If the crash was caused by a manual NMI injection:

  1. Identify who initiated the NMI and why. See Manual Crash Triggered by NMI on Virtual machine hosted on vCenter/ESXi.
  2. Review whether the NMI was sent intentionally to collect diagnostic data from a hung VM.
  3. If the NMI was unintentional, review administrative access and procedures.

Additional Information

Powered by Wolken Software