Workstation 15 - Win32 exception detected, exceptionCode 0xc0000006 (disk error while paging)

[COS]

Host OS is Server 2016 with 188GB RAM and 2 quad core Xeon.

File system: NTFS

NTFS Compression: None

Dedup: None

I have vm's running in Workstation 15 getting the below log segment error....

2019-03-13T08:44:34.449-07:00| vcpu-0| I125: DISKUTIL: scsi0:0 : capacity=125829120 logical sector size=512

2019-03-13T08:45:04.784-07:00| vmx| I125: scsi0:0: Command READ(10) took 1.011 seconds (ok)

2019-03-13T08:45:18.215-07:00| vmx| I125: DISKLIB-LIB   : numIOs = 50000 numMergedIOs = 12400 numSplitIOs = 1776

2019-03-13T08:49:42.546-07:00| vcpu-0| W115: ----Win32 exception detected, exceptionCode 0xc0000006 (disk error while paging)----

2019-03-13T08:49:42.547-07:00| vcpu-0| W115: ExceptionAddress 0x7ff7d55a6f5c eflags 0x00010206

2019-03-13T08:49:42.547-07:00| vcpu-0| W115: rwFlags 0 badAddr 0x1e8519fd000

2019-03-13T08:49:42.547-07:00| vcpu-0| W115: rax 0x1e857bff000 rbx 0x1e8462f2000 rcx 0x200

2019-03-13T08:49:42.547-07:00| vcpu-0| W115: rdx 0x1e857bff000 rsi 0x1e8519fd000 rdi 0x1e8462f2000

2019-03-13T08:49:42.547-07:00| vcpu-0| W115: r8 0x200 r9 0x10000 r10 0x1e845e9b0a8

2019-03-13T08:49:42.547-07:00| vcpu-0| W115: r11 0x1e8462f0000 r12 0x1e8462f0000 r13 0x1

2019-03-13T08:49:42.547-07:00| vcpu-0| W115: r14 0x2000 r15 0x10000

2019-03-13T08:49:42.547-07:00| vcpu-0| W115: rip 0x7ff7d55a6f5c rsp 0x29b3efec70 rbp 0xe

2019-03-13T08:49:42.547-07:00| vcpu-0| W115: LastBranchToRip 0 LastBranchFromRip 0

2019-03-13T08:49:42.547-07:00| vcpu-0| W115: LastExceptionToRip 0 LastExceptionFromRip 0

2019-03-13T08:49:42.547-07:00| vcpu-0| W115: The following data was delivered with the exception:

2019-03-13T08:49:42.547-07:00| vcpu-0| W115:  -- 0

2019-03-13T08:49:42.547-07:00| vcpu-0| W115:  -- 0x1e8519fd000

2019-03-13T08:49:42.548-07:00| vcpu-0| W115:  -- 0xc0000010

2019-03-13T08:49:42.549-07:00| vcpu-0| I125: CoreDump: Minidump file D:\virtualmachines_vmwks\lab-management\vmware-vmx.dmp exists. Rotating ...

2019-03-13T08:49:42.557-07:00| vcpu-0| W115: CoreDump: Writing minidump to D:\virtualmachines_vmwks\lab-management\vmware-vmx.dmp

2019-03-13T08:49:42.966-07:00| vcpu-0| I125: CoreDump: including module base 0x0x7ff7d5130000 size 0x0x0124d000

2019-03-13T08:49:42.966-07:00| vcpu-0| I125:   checksum 0x00f62ec3 timestamp 0x5ba2301c

2019-03-13T08:49:42.966-07:00| vcpu-0| I125:   image file C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe

2019-03-13T08:49:42.966-07:00| vcpu-0| I125:   file version 15.0.0.38213

I get this every morning randomly on some VM's but all VM's exhibit this same problem, just not all the same day.

I have run a chkdsk on the volume they are on and no errors found.

I moved a VM to my SAS SSD LUN and it get's the same thing.

I also for kicks moved it on a RAMDISK LUN and it still gets the same thing.

I remove the .vmem file after the crash and it seems to stay alive for the rest of the day.

Funny thing though, at the end of the day, I gracefully shutdown each VM so there is no .vmem file in the morning when I fire up my lab.

I even made a batch file to delete all the .vmem files in each VM's folder but this crash still occurs.

Any ideas?

[continuum]

I recommend to run
chkdsk /f /x /r /v 😧
If your host has open files on 😧 tell your host to do it after reboot.
Also run the same command against the drive where you store your pagefile.sys.
Looks like your host has lots of RAM.
Consider to use
mainmem.useNamedFile = "FALSE"
in the vmx-files of your guests.
This should have the result that your hostOS uses real RAM instead of a *.vmem file during normal use.
Of course it will create a vmem again as soon as you suspend the guests.

[COS]

I just made the following additions to the VM's .vmx files....

MemTrimRate = "0"

sched.mem.pshare.enable = "FALSE"

MemAllowAutoScaleDown = "FALSE"

mainMem.useNamedFile = "FALSE"

We'll see how it goes tomorrow morning.

[continuum]

Dont forget checkdisk !!!!

[COS]

Running th chkdsk /f /x /r /v 😧 right now.

I had to reboot to start the scan and it's scanning now.

EDIT:

Oh boy, I forgot the 😧 drive is 5TB (RAID5).........gunna take quite a while.

¯\_(ツ)_/¯

Thanks

[continuum]

Congratulations !
sounds like you will have a free afternoon now

[COS]

OK, here's the output of the finished run of the chkdsk...

C:\Windows\system32>chkdsk /f /x /r /v e:

The type of the file system is NTFS.

Volume dismounted.  All opened handles to this volume are now invalid.

Volume label is RAID5.

Stage 1: Examining basic file system structure ...

  10240 file records processed.

File verification completed.

  254 large file records processed.

  0 bad file records processed.

Stage 2: Examining file name linkage ...

  11020 index entries processed.

Index verification completed.

  0 unindexed files scanned.

  0 unindexed files recovered to lost and found.

Stage 3: Examining security descriptors ...

Security descriptor verification completed.

  391 data files processed.

CHKDSK is verifying Usn Journal...

  125540264 USN bytes processed.

Usn Journal verification completed.

Stage 4: Looking for bad clusters in user file data ...

  10224 files processed.

File data verification completed.

Stage 5: Looking for bad, free clusters ...

  1109708079 free clusters processed.

Free space verification is complete.

Windows has scanned the file system and found no problems.

No further action is required.

   5150577 MB total disk space.

834836956 KB in 9490 files.

      2876 KB in 392 indexes.

         0 KB in bad sectors.

    519475 KB in use by the system.

     65536 KB occupied by the log file.

   4334797 MB available on disk.

      4096 bytes in each allocation unit.

1318547905 total allocation units on disk.

1109708079 allocation units available on disk.

going to fire up the lab now and see if I still get the crashes from disk issues.....

[COS]

Looks like the settings below eliminates the problem....

MemTrimRate = "0"

sched.mem.pshare.enable = "FALSE"

MemAllowAutoScaleDown = "FALSE"

mainMem.useNamedFile = "FALSE"

I spun up a VM without those settings yesterday and fired up the VM this morning and it exhibited the same crashing problem. All the other VM's I put the settings in have yet to crash.

Thanks

[jefferson342]

Run this command chkdsk /f /x /r /v 😧 Tell your host to do it after reboot,open files on your host.