vmss2core: Where to Download It and How to Convert VM Snapshots (.vmsn/.vmss + .vmem) into Windows and Linux Memory Dumps

vmss2core in 2026: where to download it, which .vmsn/.vmss/.vmem files it needs, -W/-W8/-N commands, WinDbg analysis and common errors.

Short answer: vmss2core converts a VM checkpoint (a snapshot with memory, .vmsn + .vmem, or a suspend file, .vmss + .vmem) into a memory dump for WinDbg or the Linux crash utility. Get the current build from VMware Workstation Pro or Fusion; the standalone Fling in Broadcom’s Free Downloads is older (build 8456865) and does not support Windows 11, Server 2019 or Server 2025. Run vmss2core.exe -W8 vm.vmsn vm.vmem for modern Windows, -N for Linux.

vmss2core converting a VMware VM snapshot (.vmsn and .vmem) into a memory dump

What the vmss2core tool does and which files it needs

vmss2core reads VMware checkpoint state and writes a core or memory dump that standard debuggers understand: memory.dmp for Windows (WinDbg) or vmss.core for Linux (crash, GDB). It is useful when a guest hangs and you cannot force a crash dump from inside the OS.

MethodFiles to copyNotes
Snapshot with memory<name>-SnapshotN.vmsn + <name>-SnapshotN.vmemVM keeps running. Pick the newest pair by timestamp.
Suspend<name>.vmss + <name>.vmemHardware version 11 or newer, or VMs on vVols, write a separate .vmem. Hardware version 10 or lower keeps everything in the .vmss.

The .vmem file is the guest memory image. The .vmsn/.vmss file holds the device and CPU state. You always pass the state file first and the .vmem second.

vmss2core download: where to get it now

The old Flings site and vmwa.re/flings links are gone. Flings now live in the Free Downloads section of the Broadcom Support Portal, which needs a free Broadcom account (personal email addresses are accepted).

SourceVersionUse it for
Broadcom Support Portal > Free Downloads > Flings > VMSS2CoreLegacy standalone build 8456865 (Windows and Linux binaries)Older guests only. Not for Windows 11, Server 2019 or Server 2025.
VMware Workstation Pro (Free Downloads)Current, bundledAny supported guest, including Windows 11 and Server 2025
VMware Fusion Pro (Free Downloads)Current, bundledSame, on macOS

Once Workstation or Fusion is installed, the binary is here:

  • Windows 64-bit: C:\Program Files (x86)\VMware\VMware Workstation\vmss2core.exe
  • Windows 32-bit: C:\Program Files\VMware\VMware Workstation\
  • Linux: /usr/bin/ (Broadcom’s KB calls the Linux binary vmss2core-Linux64; same syntax)
  • macOS (Fusion): /Library/Application Support/VMware Fusion/

Get the latest vmss2core.exe without installing Workstation

  1. Download the VMware Workstation Pro installer from Free Downloads (Broadcom’s example: VMware-Workstation-Full-25H2u1-25219725.exe).
  2. Open the installer with 7-Zip, then open Workstation.cab inside it.
  3. Copy vmss2core.exe and _zlib1.dll to one folder, for example C:\Temp\vmss2core.
  4. Rename _zlib1.dll to zlib1.dll. Without this you get “The code execution cannot proceed because zlib1.dll was not found.”

Get the snapshot or suspend files from ESXi

vSphere Client datastore browser showing the .vmsn and .vmem snapshot files to download for vmss2core
  1. Reproduce the problem so the guest is in the state you want to capture. The guest kernel must be loaded; a VM stuck in BIOS/POST or before the OS boots gives no usable data.
  2. In the vSphere Client, right-click the VM and take a snapshot with the VM’s memory included, or suspend it (Power > Suspend). From the ESXi Shell you can suspend with vim-cmd vmsvc/getallvms and vim-cmd vmsvc/power.suspend <VMID>.
  3. Browse the datastore to the VM folder (/vmfs/volumes/<datastore>/<vm_name>/) and download the .vmsn or .vmss file and the matching .vmem.
  4. Copy them to the folder that contains vmss2core.

On vSAN the .vmem is an object; Broadcom KB 326327 describes reading its object ID and exposing it with objtool before copying. For Horizon desktops, put full clones in maintenance mode before suspending; for instant clones, use a memory snapshot instead. The Broadcom KBs are written for ESXi 8.x; memory snapshots and suspend work the same way in vSphere 9.

vmss2core for Windows: -W or -W8

OptionGuest OS (Broadcom KB 323788)
-WWindows 7, Windows 10, Windows Server 2008, 2008 R2
-W8Windows 8, 8.1, Windows 11, Windows Server 2012, 2016, 2019, 2025
-NLinux
vmss2core.exe -W8 test-vm.vmsn test-vm.vmem
vmss2core.exe -W8 test-vm.vmss test-vm.vmem
vmss2core.exe -W  old-vm.vmsn old-vm.vmem

KB 181598 phrases it slightly differently: -W8 for Windows 8 / Server 2012 and later, -W for older Windows. The two KBs disagree on Windows 10. Success produces memory.dmp in the current folder.

vmss2core for Linux guests: -N

./vmss2core-Linux64 -N vm-Snapshot1.vmsn vm-Snapshot1.vmem
vmss2core.exe -N vm-Snapshot1.vmsn vm-Snapshot1.vmem

The result is vmss.core, a Red Hat crash-format core. The tool’s help says -N uses kernel structure offsets passed with -l, generated by getlinuxoffsets. Here is my own -N run from the original version of this post (vmss2core build 20800274, about 2,000 MB written, progress lines shortened):

vmss2core.exe -N VM-Snapshot1.vmsn VM-Snapshot1.vmem
vmss2core version 20800274 Copyright (C) 1998-2022 VMware, Inc. All rights reserved.
Started core writing.
Writing note section header.
Writing 1 memory section headers.
Writing notes.
... 100 MBs written.
... 200 MBs written.
...
... 1900 MBs written.
... 2000 MBs written.
Finished writing core.

Analyze the VMware memory dump

  • Windows, WinDbg: windbg -y <SymbolPath> -z memory.dmp, or File > Open Crash Dump (Ctrl+D). Start with !analyze -v, then .bugcheck, lm and !process 0 0.
  • Linux, crash: crash vmlinux vmss.core. crash needs two arguments for a dump file: the uncompressed kernel (vmlinux with debug info matching the guest kernel) and the dump.

vmss2core errors and fixes

SymptomCause and fix
Unrecognized .vmss file (magic 4f434e45), 0 KB memory.dmpVM files are encrypted (Windows 11 / Server 2025 with vTPM). Suspend the VM, decrypt on ESXi with crypto-util (below), convert the decrypted files with the current vmss2core.
Error parsing Windows data. Cannot create memory.dmpWindows kernel was not loaded yet (stuck in POST, no boot device, boot failure). Capture again after the OS is up.
0 KB dump, or a .core file instead of memory.dmpVBS or Hyper-V is enabled in the guest. Check vhv.enable = "TRUE" in the .vmx; the KB says to set it to "FALSE". Also update old Windows builds.
Access is DeniedUse the latest vmss2core from Workstation Pro.
EFI VM freezes on a black screen, Cannot translate linear addressEFI SMM deadlock on hardware version below 14 (ESXi 7.0). Fixed in ESXi 8.0; workaround is hardware version 14 or later (KB 318382).
crypto-util encobj decrypt --related vm-###.vmx vm-###.vmem vm-###-decrypted.vmem
crypto-util encobj decrypt --related vm-###.vmx vm-###.vmss vm-###-decrypted.vmss
vmss2core.exe -W8 vm-###-decrypted.vmss vm-###-decrypted.vmem

Do not remove the vTPM to get around encryption: Broadcom warns that this makes encrypted data unrecoverable and stops Windows 11 from booting.

vmss2core options reference

Output of vmss2core.exe without arguments on my machine (build 20800274, abridged):

Usage:
GENERAL:  vmss2core [[options] | [-l linuxoffsets options]] \
          <vmss file> [<vmem file>]

Without options one vmss.core<N> per vCPU with linear view of
memory is generated.
-q      Quiet(er) operation.
-M      Create core file with physical memory view (vmss.core).
-l str  Offset stringset expressed as 0xHEXNUM,0xHEXNUM,... .
-N      Red Hat crash core file for arbitrary Linux version
        described by the "-l" option (vmss.core).
-N4     Red Hat crash core file for Linux 2.4 (vmss.core).
-N6     Red Hat crash core file for Linux 2.6 (vmss.core).
-O <x>  Use <x> as the offset of the entrypoint.
-U <i>  Create linear core file for vCPU <i> only.
-P      Print list of processes in Linux VM.
-P<pid> Create core file for Linux process <pid> (core.<pid>).
-S      Create core for 64-bit Solaris (vmcore.0, unix.0).
-S32    Create core for 32-bit Solaris (vmcore.0, unix.0).
-W      Create WinDbg file (memory.dmp) with commonly used
        build numbers ("2195" for Win32, "6000" for Win64).
-W<num> Create WinDbg file (memory.dmp), with <num> as the
        build number (for example: "-W2600").
-WK     Create a Windows kernel memory only dump file (memory.dmp).
-WDDB<num> or -W8DDB<num>
        Create WinDbg file (memory.dmp), with <num> as the
        debugger data block address in hex.
-WSCAN  Scan all of memory for Windows debugger data blocks
        (instead of just low 256 MB).
-W8     Generate a memory dump file from a suspended Windows 8 VM.
-X32    <mach_kernel> Create core for 32-bit Mac OS.
-X64    <mach_kernel> Create core for 64-bit Mac OS.
-F      Create core for an EFI firmware exception.

Sources

Related on vdan.cz

How to Rebuild a VMX File from vmware.log on an ESXi 8 Host via SSH

Lost or corrupted .vmx? Rebuild it from vmware.log on ESXi 8 with a short shell script over SSH (KB 1023880), including the #!/bin/ash fix for ESXi 8.

Introduction

Short answer: if a VM’s .vmx file is lost or corrupted, you can rebuild it from the configuration that ESXi writes into the VM’s vmware.log. SSH to the host, change to the VM’s folder, and run the small shell script below. On ESXi 8 the script needs #!/bin/ash as its first line, otherwise it fails with Operation not permitted. Back up the VM folder first.

Rebuilding a VMX file from vmware.log in VMware ESXi can be crucial for restoring a virtual machine’s configuration. This guide will walk you through the process using SSH according KB 1023880, but with update for ESXi 8.0. It was necessary add #!/bin/ash because of error “Operation not permitted”.

Step 1: SSH into Your ESXi Host

First, ensure SSH is enabled on your ESXi host. Then, use an SSH client to connect to the host.

Step 2: Navigate to the Virtual Machine’s Directory

Change to the directory where your VM resides. This is usually under /vmfs/volumes/.

cd /vmfs/volumes/name-volume/name-vm

Step 3: Create and Prepare the Script File

Create a new file named vmxrebuild.sh and make it executable:

touch vmxrebuild.sh && chmod +x vmxrebuild.sh

Step 4: Edit the Script File for ESXi 8

Edit the vmxrebuild.sh file using the vi editor:

  1. Run vi vmxrebuild.sh.
  2. Press i to enter insert mode.
  3. Copy and paste the following script (adjust for your ESXi host version).
  4. Press ESC, then type :wq! to save and exit.

Script Content for ESXi 8.0:

#!/bin/ash
VMXFILENAME=$(sed -n 's/^.*Config file: .*\/\(.\+\)$/\1/p' vmware.log)
echo -e "#\041/usr/bin/vmware" > ${VMXFILENAME}
echo '.encoding = "UTF-8"' >> ${VMXFILENAME}
sed -n '/DICT --- CONFIGURATION/,/DICT ---/ s/^.*DICT \+\(.\+\) = \(.\+\)$/\1 = \2/p' vmware.log >> ${VMXFILENAME}

Step 5: Run the Script

Execute the script to rebuild the VMX file:

./vmxrebuild.sh

Conclusion

This process extracts the necessary configuration details from the vmware.log file and recreates the VMX file, which is vital for VM configuration. Always back up your VM files before performing such operations.

Optimizing NSX Performance Based on Workload…

Optimizing NSX Performance Based on Workload…

Optimizing NSX Performance Based on Workload Overview Performance tuning, in general, requires a holistic view of the application traffic profiles, features leveraged and the criteria for performance from the application perspective. In this blog, we will take a look at some of the factors to […]


VMware Social Media Advocacy

Raspberry Pi 5 PCIe Gen 3: Enable 8 GT/s on the External PCIe Connector and Verify the Link Speed

Raspberry Pi 5 runs its external PCIe x1 link at Gen 2 by default. Enable Gen 3 with dtparam=pciex1_gen=3, verify with lspci LnkSta, know the risks.

Short answer: The external PCIe connector on the Raspberry Pi 5 runs PCIe Gen 2.0 x1 (5 GT/s) by default. To switch it to PCIe Gen 3.0 (8 GT/s), add dtparam=pciex1_gen=3 to /boot/firmware/config.txt, or use raspi-config → Advanced Options → PCIe Speed, then reboot. Raspberry Pi states that the Pi 5 is not certified for Gen 3.0, so the link may be unstable. Check the negotiated speed with sudo lspci -vv (the LnkSta line).

Illustration of a Raspberry Pi 5 board with high-speed PCIe signal traces

Raspberry Pi 5 PCIe lanes: what runs at which speed

The BCM2712 SoC on the Raspberry Pi 5 drives two PCIe links. One goes to RP1, Raspberry Pi’s own I/O controller. RP1 handles USB, Gigabit Ethernet, the MIPI camera/display transceivers and GPIO. The other goes to the new 16-pin, 0.5 mm pitch FPC connector on the left edge of the board, which is meant for fast peripherals such as NVMe drives on an M.2 HAT+.

LinkLanesDefaultGen 3.0 option
BCM2712 → RP1 (USB, Ethernet, MIPI, GPIO)x4, PCIe 2.0 (16 Gb/s)Gen 2.0Not affected by pciex1_gen
External FPC connector (M.2 HAT+, NVMe, other PCIe devices)x1Gen 2.0, 5 GT/s (~500 MB/s peak)dtparam=pciex1_gen=3, 8 GT/s, not certified

Only the external x1 link changes. Gen 3.0 roughly doubles its raw signalling rate, from 5 GT/s to 8 GT/s. That is why NVMe benchmarks on the Pi 5 improve noticeably when the drive and the adapter can handle it.

How to enable PCIe Gen 3 on the Raspberry Pi 5

Current Raspberry Pi OS keeps config.txt in the boot partition at /boot/firmware/config.txt. The original version of this post used /boot/config.txt, which was the path on older images. Edit whichever file your image actually boots from.

Option 1: config.txt

  1. If the device is not a HAT+ board, turn on the connector first. HAT+ devices are detected automatically, so they don’t need this line. nvme is an alias for pciex1.
  2. Add the Gen 3 line and reboot with sudo reboot.
# /boot/firmware/config.txt
dtparam=pciex1
dtparam=pciex1_gen=3

The Raspberry Pi kernel overlay README describes both parameters. pciex1 “enable[s] the external PCIe link” (default off), and pciex1_gen sets the GEN/speed of that link (default 2).

Option 2: raspi-config

  1. Run sudo raspi-config.
  2. Select Advanced Options → PCIe Speed.
  3. Choose Yes to enable PCIe Gen 3 mode, then Finish.
  4. Reboot with sudo reboot.

Check the PCIe link speed with lspci

After the reboot, look at the link capability and status of the PCIe devices. You need lspci from the pciutils package.

sudo lspci -vv | grep -E "^[0-9a-f]|LnkCap:|LnkSta:"
  • LnkCap shows what the device or port supports.
  • LnkSta shows what was actually negotiated. For the external connector and the device behind it, Speed 8GT/s with Width x1 means Gen 3.0 is active. 5GT/s means the link is still at Gen 2.0.
  • The output also lists the RP1 link. That one stays at Gen 2.0, which is expected.

Is PCIe Gen 3 on the Raspberry Pi 5 safe?

Raspberry Pi’s documentation says the Raspberry Pi 5 isn’t certified for Gen 3.0 speeds and that Gen 3.0 connections might be unstable. Whether it works depends on the ribbon cable, the adapter board and the device. If the drive doesn’t enumerate, disappears, or logs PCIe/NVMe errors in dmesg, go back to the default: remove the pciex1_gen=3 line (or set it to 2) and reboot. Don’t enable Gen 3 on a system you can’t afford to debug, especially if you boot from the NVMe drive.

Booting the Raspberry Pi 5 from NVMe

In most homelab builds, the reason to care about PCIe speed is an NVMe boot drive. Boot from PCIe is not enabled by default. Edit the bootloader configuration with sudo rpi-eeprom-config --edit and set:

BOOT_ORDER=0xf416
# only for a non-HAT+ adapter:
PCIE_PROBE=1

Save and reboot to write the EEPROM. The official M.2 HAT+ (2230/2242) and M.2 HAT+ Compact (2230) are specified as single-lane PCIe 2.0 adapters with up to 3 A for the M.2 device. Anything above Gen 2.0 on them falls under the same “not certified” caveat.

Sources

Further reading (benchmarks): Jeff Geerling: Forcing PCI Express Gen 3.0 speeds on the Pi 5 and Testing PCIe on the Raspberry Pi 5.

Related on vdan.cz