Here's what I recently discovered : I disabled Dell Command on the underlying host system and it helped !
This is software loaded by default on new Dell Precision laptops that monitors hardware and also which checks for BIOS, firmware and driver updates. At first, I thought it was great at it handled all updates automatically for me. But...
Instantly after disabling Dell Command automated checks, almost all USB problems in VMware Workstation disappeared. Wow ! So how did I found out in the first place ?
On a couple of instances, I noticed that I lost the USB microphone during a Zoom meeting in a VM immediately after Dell Command indicated a new driver was available on the host. Please note it did not even install it; it merely checked for new driver availability (which implies it must have polled the system to some degree). I guess it did not do some clean "read" inspection of system resources...?
Further investigation revealed that Dell Command was constantly and silently checking the system for new drivers and also polling system health.
Consequently, one assumption is that it might behave as some kind of a hypervisor itself (or at the very least it might lock access to the hardware, kicking VMware Workstation out for a brief moment), which I am suspecting might interfere with the virtualization layer. Indeed, both might be for a fraction of a second in contention.
A conflict for USB bus reservation might then trigger the issue we're observing on the guest OS. The "good" news is that this is benign in that there is no crash; merely a temporary loss of USB.
However, even if it's just a few milli or micro-seconds, it's enough for Zoom (or I'm guessing Skype, etc...) to permanently lose the USB microphone until we manually re-assign it (a pain, especially if you are in the middle of a public speech).
That might also explain why, from VMware's perspective, it is difficult to identify the problem (we have had multiple support cases open regarding this, and although they admit they've had several customers report the issue, they were not able to reproduce it). That's simply because Dell Command and equivalent software from other vendors are additional variables which viciously interface between the hardware and the virtualization layer. And VMware might not even take that into account, perhaps reasoning that it is an external variable...? Not sure, but that appears like a plausible explanation.
The problem could be circumvented (or I would say "masked", and therefore hard to diagnose - so, not ideal) if software vendors (specifically Zoom or Skype) had a built-in mechanism to reconnect USB automatically; however this would not help anyone in pin-pointing the root cause of the issue. So that in itself is not a preferred solution.
Even though it is a tough issue to troubleshoot, I'm rather satisfied that the USB breaks (in some way), because at least it gives us something flagrant to work with.
Unfortunately, I personally do not have the tools to investigate the hardware or system (driver layer) and how all of this interacts. So we're for the most part left with our reliance on VMware to look further into this.
The question is, for those in the community who use different hardware (HP, IBM, Toshiba, etc...), if there are equivalent symptoms or behavior on your platform, then should you look into similar, equivalent software (or drivers) on the host, which might likewise potentially interfere with the virtualization layer from VMware Workstation (particularly as it relates to USB) ?
Try disabling any vendor software that is uninstalled on the host system and see if it helps. Also, be sure to have all the stable device drivers installed on the host system. This will make it easier for VMware Worstation to work with.
Just a thought... Please let us know how that goes !
