Weird Crashing Issue with Signal 15

[SamTaggart]

I am running PopOS 21.04 as a host on a Dell XPS 13 9310.

I am running WS Pro 16.1.2 build-17966106

My guest is Win10 with whatever the latest updates are ( who can keep track anymore?)

I have this weird issue.

I was storing the VM on an external NVME drive in an enclosure. I noticed the Windows guest would start crashing. Like it would randomly just go away and I would get the VMware dialog about do you want to allow it to run in the background or not. Then Vmware just goes away. This would only happen when I was connected to a docking station (it's a Cable Matters USB-C Dock). So I thought maybe it's an issue with USB power to the external drive (it has a fan). I thought maybe the fan was kicking on and lowering the bus voltage and causing problems. 
Here is what the log was saying:

2021-07-16T16:28:30-06:00[+4.748]| vmx| W003: Caught signal 15 -- tid 50961 (eip 0x7f7808c6432e)

I moved the VM onto the laptop's internal NVME drive and it was working fine for a while with no crashes. Recently I started getting some weird video glitches switching from host to guest. And now it has started crashing again. Occurs while connected to the dock. Haven't tried it out not connected to the dock since latest round of crashing. Previous round did not seem to happen without the dock or running the VM from the portable nvme drive on another Ubuntu Workstation.

Thoughts?  It's got to the point where it's crashing frequently and I can't get any work done. 

[SamTaggart]

Also Pop OS and WS both appear to have the latest updates.

[bluefirestorm]

Is there any indication in the vmnware.log file what thread ID 50961 is in this particular instance? That might lead a clue what is crashing (e.g. virtual video, virtual disk, etc).

Considering that the host system is a laptop, does the crashing happen ever when the laptop is plugged in instead of running on battery power? Running on battery power could possibly lead to power saving situations and turning off host devices and essentially pulling the rug underneath the VM.

[SamTaggart]

Here is the most recent one. I ran it again so the thread ID changed, but here is what I got when I grepped the log.

2021-07-16T16:48:04.590-06:00| vmx| I005: Log for VMware Workstation pid=61607 version=16.1.2 build=build-17966106 option=BETA
2021-07-16T16:48:04.587-06:00| vmx| I005: VTHREAD 140190704733376 "vmx" tid 61607
2021-07-16T16:48:04.672-06:00| vmx| I005: /home/stagg54/PrimeTest-LV20x32/PrimeTest-LV20x32.vmx: Setup symlink /var/run/vmware/75a3ce55d48533c90c96c550f92addb0 -> /var/run/vmware/1000/9295880000_61607
2021-07-16T16:48:06.483-06:00| vmx| I005: deviceLock.tryLock.seed = 61607
2021-07-16T16:48:07.651-06:00| mks| I005: SOCKET creating new socket listening on /tmp/vmware-stagg54/mksctrl/mksctrl-0000061607-000-bebbf0bd
2021-07-16T16:52:07-06:00[+2.419]| vmx| W003: Caught signal 15 -- tid 61607 (eip 0x7f80b140532e)

does that help? 

As per power, right now it only appears to be crashing when connected to the docking station. I don't often run on battery power but the few times I have I don't remember any issues.

[bluefirestorm]

Looks like it is the main process thread (pid == tid). No idea why it would receive a kill signal (15).

Your suspicion on the dock is quite strong. You could try running VM(s) without it. Or perhaps try running with the dock connected but with the VM display on the laptop display instead of an external monitor connected to the dock, assuming there is(are) external display(s) attached to the dock.

[SamTaggart]

So just to make sure I understand, the signal 15 is coming from the host, not the guest?  That would explain why it works when i run it off a USB drive on another machine.

[bluefirestorm]

In this specific situation, I doubt that the signal is coming from the guest OS. This scenario can be replicated by issuing a kill from Terminal of the process ID of the vmware-vmx hosting the running VM.

Here I issued sudo kill 4178 from Terminal and the last line in the vmware.log
vmx| W003: Caught signal 15 -- tid 4178 (eip 0x7f966a591db6)

Again, I have no idea why the vmware-vmx process would receive signal 15. You could try using journalctl and look at the timeframes when these signals occurred and it might give a clue where the signal is coming from and possibly why.

[SamTaggart]

Thanks!

At least I have a place to start now. I'll do some more digging.

[SamTaggart]

Well it is definitely not the dock per se , since it just now crashed when I was not using the dock. Could be USB related because I did have a USB microphone plugged in at the time.

[bluefirestorm]

Was the USB microphone in-use by the VM or host during the crash? Was it connected to the VM (from the VM -> Removable Device menu)?

If I am not mistaken there will be microphone device in the VM (even if the USB microphone is connected to the host/disconnected from the VM) so long as the host has a microphone device.

Just wondering if the USB microphone is creating some sort of feedback loop between VM and host while the USB microphone is connected to the host AND in use inside the VM virtually.