VMware 12.5.8 with WIndows 10 64-bit image crashes often

[inetbas]

Hello VMware support,

As I can't open a ticket with you to report any issues I experience I try to do it this way.

Since the upgrade to Vmware workstation 12.5.8 I experience frequent crashes with my Windows 10 Image I use myself for customer support.

i have log and dump file avialable to share with VMware support.

Brgds,

Bas

Cisco Systems.

Log starts with:

2017-11-24T08:30:01.389+01:00| vmx| I125: Log for VMware Workstation pid=21228 version=12.5.8 build=build-7098237 option=Release

2017-11-24T08:30:01.389+01:00| vmx| I125: The process is 64-bit.

2017-11-24T08:30:01.389+01:00| vmx| I125: Host codepage=windows-1252 encoding=windows-1252

2017-11-24T08:30:01.389+01:00| vmx| I125: Host is Windows 10, 64-bit  (Build 15063)

2017-11-24T08:30:01.331+01:00| vmx| I125: VTHREAD initialize main thread 0 "vmx" host id 10936

2017-11-24T08:30:01.333+01:00| vmx| I125: LOCALE windows-1252 -> NULL User=409 System=409

2017-11-24T08:30:01.333+01:00| vmx| I125: Msg_SetLocaleEx: HostLocale=windows-1252 UserLocale=NULL

2017-11-24T08:30:01.334+01:00| vmx| I125: FILE: FileCreateDirectoryRetry: Non-retriable error encountered (C:\ProgramData\VMware): Cannot create a file when that file already exists (183)

2017-11-24T08:30:01.335+01:00| vmx| I125: FILE: FileCreateDirectoryRetry: Non-retriable error encountered (C:\ProgramData\VMware\VMware Workstation): Cannot create a file when that file already exists (183)

2017-11-24T08:30:01.337+01:00| vmx| I125: FILE: FileCreateDirectoryRetry: Non-retriable error encountered (C:\ProgramData\VMware): Cannot create a file when that file already exists (183)

2017-11-24T08:30:01.337+01:00| vmx| I125: FILE: FileCreateDirectoryRetry: Non-retriable error encountered (C:\ProgramData\VMware\VMware Workstation): Cannot create a file when that file already exists (183)

2017-11-24T08:30:01.338+01:00| vmx| I125: FILE: FileCreateDirectoryRetry: Non-retriable error encountered (C:\ProgramData\VMware): Cannot create a file when that file already exists (183)

2017-11-24T08:30:01.338+01:00| vmx| I125: FILE: FileCreateDirectoryRetry: Non-retriable error encountered (C:\ProgramData\VMware\VMware Workstation): Cannot create a file when that file already exists (183)

2017-11-24T08:30:01.339+01:00| vmx| I125: DictionaryLoad: Cannot open file "C:\Users\bvdwiel\AppData\Roaming\VMware\config.ini": The system cannot find the file specified.

2017-11-24T08:30:01.339+01:00| vmx| I125: Msg_Reset:

2017-11-24T08:30:01.339+01:00| vmx| I125: [msg.dictionary.load.openFailed] Cannot open file "C:\Users\bvdwiel\AppData\Roaming\VMware\config.ini": The system cannot find the file specified.

2017-11-24T08:30:01.339+01:00| vmx| I125: ----------------------------------------

2017-11-24T08:30:01.339+01:00| vmx| I125: ConfigDB: Failed to load C:\Users\bvdwiel\AppData\Roaming\VMware\config.ini

2017-11-24T08:30:01.339+01:00| vmx| I125: OBJLIB-LIB: Objlib initialized.

[yanw]

Thanks for reporting the issue here, would you please attach the dump file and related log files here? (vmware.log and vmware-ui.log).

[inetbas]

Hello Yan,

Can I unicast these logs to you?

I wouldn't like to have those in the open forum due to some company security policy on my side.

Brgds,

Bas

Cisco Systems

[bluefirestorm]

If the build of the Windows 10 host is before 15063.502 (i.e. 15063.483 or earlier, the pasted partial log only shows 15063)

AND

the crashing looks like this threadVMware Workstation has stopped working!!

There is a high chance it is because of a bug within Windows 10 1703. A dump analysis of this crash was on a specific Microsoft DLL (ucrtbase.dll) and function within it (wcsnlen). This problem was resolved with Microsoft KB4032188 (build 15063.502).

So if the build number of the Windows 10 host is 15063.502 or later, it is likely a different cause to the crashing that you see.

[bonnie201110141]

Do you did not hit the crash with Workstation 12.5.7? Did you upgrade your host during this time?

[banackm]

The actual crash you're hitting there is a timeout in our code, where we think your session has hung.  But the mouse-thread that we're trying to reach is clearly still responding, because a few seconds into the Panic it prints into the log.

I also see a couple messages that GuestInfo collection took 10x longer than it was supposed to.  So I can only guess that your system is hitting some kind of a temporary stall/load, and you're just getting unlucky.  (The cause of which could be the Windows bug mentioned by bluefirestorm, so I'd recommend trying to update Windows past that fix?)

I'm not sure what the underlying cause of the stall is, but we have a config option you can set to make us wait longer before Panicing.

If you set the line:

mks.inputThreadRetries = 10

Into your config file (or vmx file), we'll wait twice as long before we'll give up trying to signal our thread.  The option measure the number of 5-second waits that we'll do trying to signal the thread, and it defaults to 5, so normally we'll wait a total of 25 seconds.  With mks.inputThreadRetries set to 10, we'll wait up to 50 seconds for a grab-request to complete before Panicing.  You can also set it higher if you need to, but the trade-off there is that if you're in the middle of trying to grab/ungrab, you might not be able to use the mouse/keyboard on your host for that long until it either completes successfully, or hits that timeout.  (That's why we were so strict on time-limits here.)

[inetbas]

Hello,

The previous version 12.5.7 was pretty stable didn't experience these sudden crash. Of course in the mean Windows 10 pushes update via our corporate policy. But still on release Windows 10 1703.

I experience some sudden crashes after I applied 12.5.8

Brgds,

Bas.

[inetbas]

Hello BM,

Thank you for the feedback. I will check and try this out and give feedback overtime.

Brgds,

Bas.