VMWare Workstation VMs does not work with Windows Server 2019 deduplicated volumes.

I have been running some of my home lab VMs on top of Windows Server 2012 R2 using VMware Workstation for years now. Over the holidays I decided to setup a test system with Windows Server 2019 and VMware Workstation 15. During the testing I discovered that some the VMs were randomly dying with a crash message in the eventlog.

Faulting application name: vmware-vmx.exe, version:, time stamp: 0x5bf5251a
Faulting module name: vmware-vmx.exe, version:, time stamp: 0x5bf5251a
Exception code: 0xc0000005
Fault offset: 0x000000000049db36
Faulting process id: 0x2a9c
Faulting application start time: 0x01d48a67966e2ea4
Faulting application path: C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe
Faulting module path: C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe
Report Id: 7dd5aa8c-2f51-471d-b9e4-e04d0caf099b
Faulting package full name:
Faulting package-relative application ID: 

All these VMs were located on disks with data deduplication enabled. One the disks was ReFS and other was NTFS file system. Deduplication settings on Windows Server 2019 and Windows Server 2012 R2 are the same. The issue does not occur on Windows Server 2012 R2.

I also tested other deduplication settings (General purpose file server and Virtualized Backup Server) and the result was the same. VMs on those deduplicated volumes crashed.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.