ESXi Purple Screen (PSOD): Preserve the Evidence and Collect the Core Dump

Direct answer: a purple diagnostic screen (PSOD) means the VMkernel, the core of ESXi, hit an error it could not recover from. The host has stopped. vSphere HA may restart protected VMs on other hosts, if restart is enabled for them and compatible hosts with access to their storage and enough capacity are available; check that the VMs and their applications actually came back. Before anyone reboots the host, photograph the whole screen: the error message, the CPU and world line, the stack trace, the uptime and the "Starting coredump" line. Then check that a core dump was actually written. ESXi writes it to a dump file on a datastore, to a diagnostic partition, or to the ESXi Dump Collector on vCenter. After the host restarts, extract the dump to a VMkernel zdump file on a persistent datastore with esxcfg-dumppart. Collect a support bundle, search the error message and the top stack functions in the Broadcom knowledge base, and open a case with the evidence. Do not recreate, resize or delete the dump file before you have extracted it. Do not treat a single PSOD as "fixed" by a reboot.

Why it matters

A PSOD is a host crash. HA may restart the VMs that were running on the host, but they still lost power without a clean shutdown, and the cause is still there. Whether that cause is a driver, firmware, hardware or a known ESXi defect, the evidence that identifies it is largely the screen and the core dump. Broadcom KB 318862 states the consequence plainly. If the host fails and a complete core dump is not available, VMware Support might not be able to diagnose the failure.

There are two common ways to lose that evidence:

• No usable dump target. Broadcom KB 418314 describes the alert "No coredump target has been configured. Host core dumps cannot be saved." It typically appears when the dump file has been deleted or its datastore has been disconnected. KB 318862 covers targets that exist but are too small for a complete dump.
• Overwriting before extraction. A dump stays in the active dump file or partition until something replaces it. Recreating the dump file, or letting a second crash happen before collection, can cost you the first dump.

This article is about the evidence and the collection path. It is not about the different symptom of a host that shows "Not responding" in vCenter while it is still running. That case is covered in the ESXi Host Not Responding or Disconnected in vCenter: Narrow the Cause listed under Related articles.

How it works

What the screen shows

Broadcom KB 343033 breaks a PSOD into five parts:

The same KB lists common message types:

• "Spin count exceeded … possible deadlock"
• "Failed to ack TLB invalidate"
• Exceptions such as #GP Exception(13) (general protection fault)
• Exceptions such as #PF Exception type 14 (page fault)

Where the dump goes

ESXi can write the VMkernel core dump to three kinds of target:

• A dump file on a VMFS or VMFS-L datastore. Broadcom KB 314320 recommends this over a legacy partition. A diagnostic partition carried forward from an upgrade to 5.5 or later is limited to 100 MB, which is usually too small. ESXi 7.0 creates an ESX-OSData (VMFS-L) volume and puts a dump file on it when the volume is larger than 4 GB. KB 318862 says ESXi 7.0 sizes that file automatically from the host's CPU, memory and active subsystems, but the host may need more than that after boot. It then raises the event "Recommended core dump capacity is … MiB."
• A diagnostic (VMKCore) partition of type 0xFC on a local device (KB 343591).
• The ESXi Dump Collector (netdump), which is packaged with vCenter (KB 344063). The host sends the dump over UDP, port 6500 by default, through a chosen VMkernel interface. The vCenter appliance stores received dumps under /var/core/netdumps, with a default 2 GB limit. Its startup type is manual by default, so it must be started and kept running to be useful.

KB 314320 adds these constraints:

• Software iSCSI and software FCoE are not supported as dump locations.
• A host installed on USB or SD media also needs the boot option allowCoreDumpOnUsb=TRUE before a dump file can be created there.
• The datastore needs free space of twice the recommended dump size.

From dump to zdump

The raw dump has to be extracted into a VMkernel zdump file before it can go to support. KB 340004 covers extraction from a dump file and KB 343591 covers a diagnostic partition. Both use esxcfg-dumppart. A dump is typically 100 to 300 MB (KB 343591).

Read-only checks

None of these was run for this article. Unless noted otherwise, they run in the ESXi Shell or over SSH with root privileges. If your security baseline keeps SSH disabled, enabling it is itself a change: record it and disable it again afterwards (see the hardening article under Related articles).

Before any failure (dump target health, per host):

esxcli system coredump file list
esxcli system coredump file get
esxcli system coredump partition list
esxcli system coredump network get

• file list shows each dump file with its Path, Active, Configured and Size. For a host that dumps to a file, healthy means one file with Active true and Configured true (KB 418314); partition and network targets have their own checks below.
• file get shows the Active and Configured paths (KB 340004).
• partition list shows any diagnostic partition and whether it is active (KB 343591). The legacy equivalent is esxcfg-dumppart -t.
• network get shows whether network dump is enabled, and which interface, server and port it uses (KB 344063).

In the vSphere Client, check each host's Summary tab for the "No coredump target has been configured" alert. Check events for "The storage capacity of the core dump targets is insufficient … Recommended core dump capacity is … MiB" (KB 318862).

If network dump is configured, KB 344063 suggests checking the path from the named VMkernel interface with:

vmkping -I vmk0 <collector-ip>

vmkping only checks basic reachability. It does not prove that the collector service is running or listening on UDP 6500. Check that in the vCenter appliance management interface (VAMI, https://<vcenter>:5480, Services, "VMware vSphere ESXi Dump Collector").

At the time of the PSOD (before reboot):

• Photograph or capture the full screen through the server's out-of-band console (iLO, iDRAC, XCC or equivalent). Make sure the error line, the * CPU line, every stack frame, the uptime and the coredump line are legible.
• Write down the time, the host name, what was running (backup, vMotion, a firmware or driver change, heavy I/O), and whether the dump progress line completed.
• Capture the out-of-band management log (for example the IML or SEL) from the server's hardware management interface. Hardware events near the crash time matter for the interpretation below.

After the host restarts (collection):

Confirm which dump file holds the crash:

esxcli system coredump file get

Extract the active dump file to a persistent datastore rather than the default /scratch/core. KB 340004 warns that /scratch/core is not recommended unless scratch is on persistent storage, because you may run out of space:

esxcfg-dumppart --file --copy --devname active --zdumpname /vmfs/volumes/<datastore>/<hostname>-<date>-zdump

This command reads the dump and writes a new file on the datastore. It does not change the dump configuration. KB 343591 gives 100 to 300 MB as a typical dump size, but size the destination from the actual dump: check the Size column in file list (or the partition size) and make sure the datastore has at least that much free.

If a new dump file has since been created and activated, the crash may be in an older, non-active file. KB 340004 lists the candidates with esxcli system coredump file list and extracts from a specific path instead of active.

For a diagnostic partition (KB 343591), identify the device and copy it:

esxcli system coredump partition list
esxcfg-dumppart --copy --devname "/vmfs/devices/disks/<device-identifier>" --zdumpname /vmfs/volumes/<datastore>/<hostname>-<date>-zdump

For network dump, look for the received file in the collector directory on vCenter (default /var/core/netdumps, or whatever /etc/sysconfig/netdumper sets). Reading that directory needs a root shell on the appliance.

Retrieve the zdump with the Datastore Browser or scp, and generate a support bundle for the host as described in Broadcom's "Collecting diagnostic information" guidance (KB 367431, referenced from KB 343033). KB 343591 notes that from vSphere 6.5, support bundles can include encrypted information from the host. Handle the bundle as sensitive and transfer it only through the vendor's case upload.

Interpreting the results

KB 343033 itself calls these patterns inconclusive. A support engineer reading the dump is the decision-maker. Use the patterns to prioritise, not to close the case.

Decision guidance

1. Recovery comes first, then evidence, then cause

If HA restarted the VMs, check that they and their applications came back cleanly (see the vSphere HA did not restart some VMs: reading the event trail and checking admission control and isolation settings for why some might not). Keep the host in maintenance mode, or out of DRS placement, until you have at least the photo and the zdump. Putting a host straight back into service after an unexplained PSOD invites a second crash during production hours.

2. Search before you change anything

Search the Broadcom Support Portal for the exact error message and the first few meaningful stack function names, as KB 343033 advises. If you find a match, the article will name the fix: a patch, a driver or firmware update, or a configuration change. Apply it through your normal change process. For ESXi patching, see the Lifecycle Manager article under Related articles. If nothing matches, KB 343033 says to open a case with the diagnostic data.

3. Fix a missing or undersized dump target as a planned host change

Configuring the dump target changes the host's diagnostic setup, so do it one host at a time. Record the before state with esxcli system coredump file list and do the work during a maintenance window.

Missing target (KB 418314). Create a file and let ESXi pick a suitable target:

esxcli system coredump file add --auto
esxcli system coredump file set --smart --enable true

You can also choose the datastore yourself with esxcli storage filesystem list and then esxcli system coredump file add -d <datastore-UUID>.

• Verification: file list shows the new file with Active true and Configured true, and the alert clears.
• Rollback: re-point to the previous file with esxcli system coredump file set --path <previous-path> if it still exists, or remove the unused new file after confirming it is not active.

Undersized target (KB 318862). The documented sequence is to disable the active file, add a correctly sized file with --auto, and enable it with --smart. KB 318862 also describes esxcli system coredump file remove --force for when there is not enough space to create the new file first. That removes the old file and anything in it, so extract any crash it may hold before you consider it. Prefer a datastore with room for both files, so that removal is never needed.

Network dump (KB 344063) is worth considering when local storage is limited, or when the recommended capacity is below 4096 MiB (KB 318862).

• Start the Dump Collector service in VAMI and set it to automatic.
• On each host, set the interface and server with esxcli system coredump network set, then --enable true.
• Check with network get.
• It depends on vCenter being reachable at the moment of the crash, and on the collector's 2 GB default storage cap. Check the current Dump Collector documentation for your version for any other limits before relying on it.
• Rollback: esxcli system coredump network set --enable false.

4. Hardware indications go to the hardware vendor

When the message, the hardware logs or the PSOD pattern point at hardware, open the case with the server vendor and give them the photo, the IML/SEL and the zdump. Do not swap components on guesswork. A memory or CPU error usually names a DIMM slot or socket in the vendor's own logs.

What not to do

• Do not reboot before photographing the screen, unless HA or the business needs the host's resources back immediately, and even then capture it first through the out-of-band console.
• Do not run file add --auto, file set, or file remove on a host that has just crashed until the zdump has been extracted and copied off.
• Do not extract to /scratch/core on a host whose scratch is not persistent (KB 340004).
• Do not place a dump file on storage reached through software iSCSI or software FCoE (KB 314320).
• Do not read meaning into the register values. KB 343033 says they can only be used internally when debugging the dump.
• Do not upload the support bundle to public forums. It can contain encrypted host information and configuration details (KB 343591).
• Do not close the incident because "it came back after a reboot". An unexplained PSOD is open until it is matched to a known issue, a hardware fault or a support finding.

Limitations

• The commands are taken from Broadcom KBs scoped to ESXi 6.x to 8.x. ESXi 9.0 may differ in subcommands. The ESXCLI documentation page for the Dump Collector could not be read in full, so no 9.0-specific commands are given.
• Encrypted hosts and vSphere Native Key Provider or KMS environments add their own handling of dump contents. This article does not cover them.
• Exact out-of-band console and hardware log names differ by server vendor.
• Interpreting the stack beyond matching known articles is support work. This article does not attempt root cause analysis of a dump.

Acceptance checklist

• [ ] Every host has an active dump target of a known type (file Active and Configured true, an active diagnostic partition, or enabled network dump with the collector running), recorded in the host build sheet
• [ ] No host shows the "No coredump target" alert or a "Recommended core dump capacity" event
• [ ] If network dump is used, the collector service is set to automatic and each host's network get output is recorded
• [ ] The out-of-band console for every host is reachable, so a PSOD can be photographed
• [ ] The incident runbook says: photograph first, extract the zdump to a persistent datastore, collect the bundle, search, open a case
• [ ] After a PSOD: photo, zdump, support bundle and hardware log attached to the case, and host held out of placement until there is a finding

References

All accessed 2 November 2026. Broadcom knowledge base articles do not display a last-updated date.

• Broadcom KB 343033, Interpreting an ESX/ESXi host purple diagnostic screen (PSOD): https://knowledge.broadcom.com/external/article/343033/interpreting-an-esxesxi-host-purple-diag.html
• Broadcom KB 418314, "No coredump target has been configured. Host core dumps cannot be saved" alert: https://knowledge.broadcom.com/external/article/418314/no-coredump-target-has-been-configured-h.html
• Broadcom KB 314320, Configuring ESXi coredump to file instead of partition: https://knowledge.broadcom.com/external/article/314320/configuring-esxi-coredump-to-file-instea.html
• Broadcom KB 318862, Insufficient storage capacity for VMkernel core dumps: https://knowledge.broadcom.com/external/article/318862/insufficient-storage-capacity-for-vmkern.html
• Broadcom KB 340004, Generating a VMkernel zdump manually from a dump file in ESXi host: https://knowledge.broadcom.com/external/article/340004
• Broadcom KB 343591, Extracting a core dump file from the diagnostic partition following a purple diagnostic screen error: https://knowledge.broadcom.com/external/article/343591
• Broadcom KB 344063, Configuring the Network Dump Collector service in vSphere: https://knowledge.broadcom.com/external/article/344063/configuring-the-network-dump-collector-s.html

Related articles

• How to patch an ESXi cluster with vSphere Lifecycle Manager

• How to harden VMware without breaking operations or recovery

• ESXi Host Not Responding or Disconnected in vCenter: Narrow the Cause

• vSphere HA did not restart some VMs: reading the event trail and checking admission control and isolation settings

Learning notes

1. A PSOD is a VMkernel crash. The screen and the core dump are the evidence, so photograph the screen before rebooting.
2. Check dump targets before you need them, by the target type the host uses. For a dump file, esxcli system coredump file list should show one file with Active and Configured true. For a diagnostic partition, esxcli system coredump partition list should show an active partition. For network dump, esxcli system coredump network get should show it enabled, with the collector running. An empty file list on a host that dumps to a partition or the network is not a fault.
3. Extract with esxcfg-dumppart to a persistent datastore, never to non-persistent scratch, before touching the dump configuration.
4. Search the exact error message and the top stack functions. Repeating patterns are hints, not verdicts.
5. Treat a dump target fix as a per-host change with before and after file list output. Removing a dump file can destroy unextracted evidence.