Re: USB Device Causing VM's to Freeze - Cannot Kil... - Page 2

MB1980 · ‎06-13-2019

Hi,

I'm having an intermittent issue when attaching Huawei mifi devices to my Windows 7 VM's
using Vmware Workstation 15.

Most of time it works fine and the mifi device appears and works with the vm, other times the vm
freezes and cannot be shutdown via the vmware workstation menu.

The only way I've been able to free up the vm again is to restart the host, which is a pain to do
several times a day as I have a host of apps and other vm's working fine.

I have several mifi devices and they all seem to work ok most of the time with the vm's, but
they've all caused the crash at some point. I've tried using different USB
Ports on the PC and a TPLINK USB hub - same intermittent issue.

What usually happens is thje mifi initially connects to the host pc, then I manually select the
connect to vm option. The driver starts installing in the vm, then it freezes.

After googling around it seems I just need to kill off the vmware-vmx.exe process. The
issue is I cannot seem to kill it! Nothing happens when using Task Manager -
just remains there. Tried elevated command prompt, trying to kill using PID an
name. Same with elevated powershell. I can end the Workstation tasks, but when
I relaunch the app, the vm is still running in
a frozen state.

So, I'd be really grateful if someone could help me troubleshoot and
resolve both or one of the following:

VM's are sometimes crashing when I attach the Huawei mifi devices
I cannot kill the vmware-vmx.exe without having to restart the host each time it happens

Host PC:

Windows 10 Pro

Asus ROG STRIX X299

I9-9980XE

64GB Corsair Vengeance
DDR4 3000MHZ

Many thanks!

hotvooboy · ‎02-01-2020

Thank you very much for reporting this issue and for your analysis!

Looks like the device you mentioned is not a common usb device and we will do investigation.

bevanweiss · ‎02-03-2020

I'm seeing exactly the same behaviour as @Eric1975when I run 15.5.1 build-15018445 under Windows 10 x64 (1909). I can plug the Siemens MPI Adapter into the computer and everything is fine, but if I assign it to a VM then that VM locks up, and is not able to be interacted with, including Guest Power Off / Restart.

This has been the case on two VMs, one a Windows 10 x64, and the other a Windows XP x86. Both have previously worked fine with this adaptor.

I have since uninstalled 15.5.1 build-15018445 and installed 15.1.0 build-13591040. Unfortunately the situation happened whilst I was on-site in front of a client... so not the nicest situation to be in.

I haven't yet tried to update to 15.5.0 to see if the issue is within this build also, but may try this tomorrow if I find time.

I did try to lower the USB Support version within the VM settings (setting it down to USB 1.1). This did not resolve the situation, and the lockups still occurred.

I did not try to remove the Enhanced Keyboard support, as I believe this requires a reinstall, so it was a more likely fix to revert versions at the time.

I'm a bit worried if there is special treatment for different USB devices within the VMware handling. That seems incredibly prone to these kind of 'weird' bugs, which would also only affect a limited population and so may not get the fix criticality that we would require of them. As it stands we will be unable to upgrade VMware versions until this issue is resolved.

hotvooboy · ‎02-03-2020

Hi,

Thank you for posting this issue in community.

Sorry for the inconvenience caused with WS 15.5.1. We have created internal bug to track it and will do more investigation.

ivivanov · ‎02-04-2020

Hi Eric,

Thanks for your report.

As there is nothing in the log file that gives a clue to what the problem might be, and since this issue is not reproducible in-house, can you please share some additional information in order to proceed further with the investigation?

1. Can you confirm the VMware Workstation build number that you are using, the Windows OS version and the guest OS version?

2. Can you try the workaround mentioned in https://communities.vmware.com/message/2882908#2882908 (uninstall and re-install VMware Workstation with unchecking Enhanced Keyboard Driver) and confirm whether this fixes the issue for you?

3. Can you collect a live dump from the vmx process? In order to do it there are several steps to perform:

a) close VMware Workstation and open the virtual machine .vmx file in a text editor and add the following line to it:

vmx.buildType = "debug"

b) open VMware Workstation, power on the VM and reproduce the hang

c) download the ProcDump utility from https://docs.microsoft.com/en-us/sysinternals/downloads/procdump and extract the archive to a temporary folder

d) open an Administrative Command Prompt, navigate to the temporary folder where ProcDump was extracted and run the following command:

procdump64 /ma vmware-vmx-debug

Wait for procdump to complete - it should generate a .dmp file in the current directory.

e) Compress the .dmp file and send it to me for further analysis (maybe as a private message).

Regards,

Ivan

__________
It is worse!

Matt_11 · ‎02-08-2020

Hi,

I have the exact same issue as you. Did you manage to find a solution?

Cheers

bevanweiss · ‎02-12-2020

Hi Ivan,

I've just reproduced the issue with the SIMATIC adapter (which is likely similar to other issues with USB devices).

It appears that the bug was introduced between 15.1.0 build-13591040 and 15.5.0 build-14665864.

It crashed when the keyboard driver was not installed, so this is not related.

I turned on USB Verbose debugging as the VM was starting up in the 15.1.0 release... and there is a lot more USBIO 'noise' in the logs of the 15.5.0 test. So I think perhaps the USB Verbose logging only activates when the VM is first started up. So I'll retest under 15.1.0 to get logging with the verbose USB definitely 'active'.

I've obtained the ProcDump also, with a dump file of 6686MB. I'll 7zip it down which should give us something more manageable.

I'll include some of the 15.5.0 log here, since it might be obvious from it..

2020-02-13T16:37:55.916+11:00| vmx| I125: VUsbUpdateVigorFieldsAndAutoconnect: New set of 7 USB devices

2020-02-13T16:37:55.916+11:00| vmx| I125: USB: Found device [name:Western\ Digital\ Elements\ 1048 vid:1058 pid:1048 path:1/0/1/1 speed:super family:storage,storage-bulk instanceId:USB\\VID_1058&PID_1048\\575834314139335330323030 serialnum:575834314139335330323030 arbRuntimeKey:5 version:3]

2020-02-13T16:37:55.916+11:00| vmx| I125: USB: Found device [name:Siemens\ SIMATIC\ PC\ Adapter\ USB vid:0908 pid:0004 path:1/0/0/2 speed:full family:vendor instanceId:USB\\VID_0E0F&PID_0001\\6ES7_972-0CB20-0XA0 serialnum:6ES7_972-0CB20-0XA0 arbRuntimeKey:7 version:3]

2020-02-13T16:37:55.916+11:00| vmx| I125: USB: Found device [name:Microdia\ Integrated_Webcam_HD vid:0c45 pid:6717 path:1/0/0/11 speed:high family:video instanceId:USB\\VID_0C45&PID_6717\\5&2C784537&0&11 arbRuntimeKey:3 version:3]

2020-02-13T16:37:55.917+11:00| vmx| I125: USB: Found device [name:Qualcomm\ QCA61x4A\ Bluetooth vid:0cf3 pid:e007 path:1/0/0/14 speed:full family:wireless,bluetooth instanceId:USB\\VID_0CF3&PID_E007\\5&2C784537&0&14 arbRuntimeKey:4 version:3]

2020-02-13T16:37:55.917+11:00| vmx| I125: USB: Found device [name:Action\ Star\ HID\ to\ SPI\ Device vid:0835 pid:2a06 path:1/0/0/4/1/0 speed:full family:hid instanceId:USB\\VID_0835&PID_2A06\\0123456789ABCDEF serialnum:0123456789ABCDEF arbRuntimeKey:2 version:3]

2020-02-13T16:37:55.917+11:00| vmx| I125: USB: Found device [name:DisplayLink\ USB-C\ Hybrid\ UHD\ Video\ Dock vid:17e9 pid:6000 path:1/0/1/5/2 speed:super family:vendor,other,audio,comm instanceId:USB\\VID_17E9&PID_6000\\000100117202082 serialnum:000100117202082 arbRuntimeKey:6 version:3]

2020-02-13T16:37:55.917+11:00| vmx| I125: USB: Found device [name:Virtual\ Bluetooth\ Adapter vid:0e0f pid:0008 speed:full family:wireless,bluetooth deviceType:virtual-bluetooth info:0000001 version:3]

2020-02-13T16:37:59.155+11:00| vmx| I125: USBGA: device 1000000709080004 arrived

2020-02-13T16:37:59.156+11:00| vmx| I125: USBGA: Autoconnecting new device

2020-02-13T16:37:59.156+11:00| vmx| I125: USB: Connecting device desc:name:Siemens\ SIMATIC\ PC\ Adapter\ USB vid:0908 pid:0004 path:1/0/0/2 speed:full family:vendor instanceId:USB\\VID_0E0F&PID_0001\\6ES7_972-0CB20-0XA0 serialnum:6ES7_972-0CB20-0XA0 arbRuntimeKey:7 version:3 id:0x1000000709080004

2020-02-13T16:37:59.156+11:00| vmx| I125: Policy_GetUSBDevAccess: checking usb devices at policy path: /vm/#_VMX/mvm/policyState/val/policySet/usbDevices/#

2020-02-13T16:37:59.156+11:00| vmx| I125: Policy_GetUSBDevAccess: allowConnect = YES

2020-02-13T16:37:59.156+11:00| vmx| I125: USBG: Created 1000000709080004

2020-02-13T16:37:59.156+11:00| vmx| I125: USBGW: Disabling USB 3.0 streams

2020-02-13T16:37:59.156+11:00| vmx| I125: USBIO: Up dev=2 'usb:1' endpt=81 stream=0 datalen=1 numPackets=0 status=0 0

2020-02-13T16:37:59.156+11:00| vmx| I125: USBIO: 000: 02 .

2020-02-13T16:37:59.156+11:00| vmx| I125: VUsbUpdateVigorFieldsAndAutoconnect: New set of 7 USB devices

2020-02-13T16:37:59.156+11:00| vmx| I125: USB: Found device [name:Western\ Digital\ Elements\ 1048 vid:1058 pid:1048 path:1/0/1/1 speed:super family:storage,storage-bulk instanceId:USB\\VID_1058&PID_1048\\575834314139335330323030 serialnum:575834314139335330323030 arbRuntimeKey:5 version:3]

2020-02-13T16:37:59.156+11:00| vmx| I125: USB: Found device [name:Siemens\ SIMATIC\ PC\ Adapter\ USB vid:0908 pid:0004 path:1/0/0/2 speed:full family:vendor virtPath:usb:2 instanceId:USB\\VID_0E0F&PID_0001\\6ES7_972-0CB20-0XA0 serialnum:6ES7_972-0CB20-0XA0 arbRuntimeKey:7 version:3], connected to usb:1 port 0.

2020-02-13T16:37:59.156+11:00| vmx| I125: USB: Found device [name:Microdia\ Integrated_Webcam_HD vid:0c45 pid:6717 path:1/0/0/11 speed:high family:video instanceId:USB\\VID_0C45&PID_6717\\5&2C784537&0&11 arbRuntimeKey:3 version:3]

2020-02-13T16:37:59.156+11:00| vmx| I125: USB: Found device [name:Qualcomm\ QCA61x4A\ Bluetooth vid:0cf3 pid:e007 path:1/0/0/14 speed:full family:wireless,bluetooth instanceId:USB\\VID_0CF3&PID_E007\\5&2C784537&0&14 arbRuntimeKey:4 version:3]

2020-02-13T16:37:59.156+11:00| vmx| I125: USB: Found device [name:Action\ Star\ HID\ to\ SPI\ Device vid:0835 pid:2a06 path:1/0/0/4/1/0 speed:full family:hid instanceId:USB\\VID_0835&PID_2A06\\0123456789ABCDEF serialnum:0123456789ABCDEF arbRuntimeKey:2 version:3]

2020-02-13T16:37:59.156+11:00| vmx| I125: USB: Found device [name:DisplayLink\ USB-C\ Hybrid\ UHD\ Video\ Dock vid:17e9 pid:6000 path:1/0/1/5/2 speed:super family:vendor,other,audio,comm instanceId:USB\\VID_17E9&PID_6000\\000100117202082 serialnum:000100117202082 arbRuntimeKey:6 version:3]

2020-02-13T16:37:59.156+11:00| vmx| I125: USB: Found device [name:Virtual\ Bluetooth\ Adapter vid:0e0f pid:0008 speed:full family:wireless,bluetooth deviceType:virtual-bluetooth info:0000001 version:3]

2020-02-13T16:37:59.157+11:00| vmx| I125: VUsbUpdateVigorFieldsAndAutoconnect: New set of 7 USB devices

2020-02-13T16:37:59.157+11:00| vmx| I125: USB: Found device [name:Western\ Digital\ Elements\ 1048 vid:1058 pid:1048 path:1/0/1/1 speed:super family:storage,storage-bulk instanceId:USB\\VID_1058&PID_1048\\575834314139335330323030 serialnum:575834314139335330323030 arbRuntimeKey:5 version:3]

2020-02-13T16:37:59.157+11:00| vmx| I125: USB: Found device [name:Siemens\ SIMATIC\ PC\ Adapter\ USB vid:0908 pid:0004 path:1/0/0/2 speed:full family:vendor virtPath:usb:2 instanceId:USB\\VID_0E0F&PID_0001\\6ES7_972-0CB20-0XA0 serialnum:6ES7_972-0CB20-0XA0 arbRuntimeKey:7 ownerdisplay:Siemens\ TIA ownertarget:vmware-vmx:C:\\VMWare\\VM_W10_Siemens\ V1.0\\Win\ 10\ x64.vmx version:3], connected to usb:1 port 0.

2020-02-13T16:37:59.157+11:00| vmx| I125: USB: Found device [name:Microdia\ Integrated_Webcam_HD vid:0c45 pid:6717 path:1/0/0/11 speed:high family:video instanceId:USB\\VID_0C45&PID_6717\\5&2C784537&0&11 arbRuntimeKey:3 version:3]

2020-02-13T16:37:59.157+11:00| vmx| I125: USB: Found device [name:Qualcomm\ QCA61x4A\ Bluetooth vid:0cf3 pid:e007 path:1/0/0/14 speed:full family:wireless,bluetooth instanceId:USB\\VID_0CF3&PID_E007\\5&2C784537&0&14 arbRuntimeKey:4 version:3]

2020-02-13T16:37:59.157+11:00| vmx| I125: USB: Found device [name:Action\ Star\ HID\ to\ SPI\ Device vid:0835 pid:2a06 path:1/0/0/4/1/0 speed:full family:hid instanceId:USB\\VID_0835&PID_2A06\\0123456789ABCDEF serialnum:0123456789ABCDEF arbRuntimeKey:2 version:3]

2020-02-13T16:37:59.157+11:00| vmx| I125: USB: Found device [name:DisplayLink\ USB-C\ Hybrid\ UHD\ Video\ Dock vid:17e9 pid:6000 path:1/0/1/5/2 speed:super family:vendor,other,audio,comm instanceId:USB\\VID_17E9&PID_6000\\000100117202082 serialnum:000100117202082 arbRuntimeKey:6 version:3]

2020-02-13T16:37:59.157+11:00| vmx| I125: USB: Found device [name:Virtual\ Bluetooth\ Adapter vid:0e0f pid:0008 speed:full family:wireless,bluetooth deviceType:virtual-bluetooth info:0000001 version:3]

2020-02-13T16:37:59.184+11:00| vmx| I125: USBIO: Up dev=1 'usb:0' endpt=81 stream=0 datalen=8 numPackets=0 status=0 0

2020-02-13T16:37:59.184+11:00| vmx| I125: USBIO: 000: 00 00 e1 32 28 54 00 00 ...2(T..

2020-02-13T16:37:59.188+11:00| vmx| I125: USBIO: Down dev=1 'usb:0' endpt=81 stream=0 datalen=8 numPackets=0 status=0 0

2020-02-13T16:37:59.189+11:00| vmx| I125: USBIO: Class 0x00(wValue=0x0000, wIndex=0x0001)

2020-02-13T16:37:59.189+11:00| vmx| I125: USBIO: Down dev=2 'usb:1' endpt=0 stream=0 datalen=4 numPackets=0 status=0 0

2020-02-13T16:37:59.189+11:00| vmx| I125: USBIO: 000: a3 00 00 00 01 00 04 00 ........

2020-02-13T16:37:59.189+11:00| vmx| I125: USBIO: Up dev=2 'usb:1' endpt=0 stream=0 datalen=4 numPackets=0 status=0 0

2020-02-13T16:37:59.189+11:00| vmx| I125: USBIO: 000: a3 00 00 00 01 00 04 00 ........

2020-02-13T16:37:59.189+11:00| vmx| I125: USBIO: 000: 01 01 01 00 ....

2020-02-13T16:37:59.190+11:00| vmx| I125: USBIO: Class 0x00(wValue=0x0000, wIndex=0x0002)

2020-02-13T16:37:59.190+11:00| vmx| I125: USBIO: Down dev=2 'usb:1' endpt=0 stream=0 datalen=4 numPackets=0 status=0 0

2020-02-13T16:37:59.190+11:00| vmx| I125: USBIO: 000: a3 00 00 00 02 00 04 00 ........

2020-02-13T16:37:59.190+11:00| vmx| I125: USBIO: Up dev=2 'usb:1' endpt=0 stream=0 datalen=4 numPackets=0 status=0 0

2020-02-13T16:37:59.190+11:00| vmx| I125: USBIO: 000: a3 00 00 00 02 00 04 00 ........

2020-02-13T16:37:59.190+11:00| vmx| I125: USBIO: 000: 00 01 00 00 ....

2020-02-13T16:37:59.192+11:00| vmx| I125: USBIO: Class 0x00(wValue=0x0000, wIndex=0x0003)

2020-02-13T16:37:59.192+11:00| vmx| I125: USBIO: Down dev=2 'usb:1' endpt=0 stream=0 datalen=4 numPackets=0 status=0 0

2020-02-13T16:37:59.192+11:00| vmx| I125: USBIO: 000: a3 00 00 00 03 00 04 00 ........

2020-02-13T16:37:59.192+11:00| vmx| I125: USBIO: Up dev=2 'usb:1' endpt=0 stream=0 datalen=4 numPackets=0 status=0 0

2020-02-13T16:37:59.192+11:00| vmx| I125: USBIO: 000: a3 00 00 00 03 00 04 00 ........

2020-02-13T16:37:59.192+11:00| vmx| I125: USBIO: 000: 00 01 00 00 ....

2020-02-13T16:37:59.193+11:00| vmx| I125: USBIO: ClearFeature(feature=1, device=0)

2020-02-13T16:37:59.193+11:00| vmx| I125: USBIO: Down dev=2 'usb:1' endpt=0 stream=0 datalen=0 numPackets=0 status=0 0

2020-02-13T16:37:59.193+11:00| vmx| I125: USBIO: 000: 00 01 01 00 00 00 00 00 ........

2020-02-13T16:37:59.193+11:00| vmx| I125: USBIO: Up dev=2 'usb:1' endpt=0 stream=0 datalen=0 numPackets=0 status=0 0

2020-02-13T16:37:59.193+11:00| vmx| I125: USBIO: 000: 00 01 01 00 00 00 00 00 ........

2020-02-13T16:37:59.195+11:00| vmx| I125: USBIO: Class 0x00(wValue=0x0000, wIndex=0x0004)

2020-02-13T16:37:59.195+11:00| vmx| I125: USBIO: Down dev=2 'usb:1' endpt=0 stream=0 datalen=4 numPackets=0 status=0 0

2020-02-13T16:37:59.195+11:00| vmx| I125: USBIO: 000: a3 00 00 00 04 00 04 00 ........

2020-02-13T16:37:59.195+11:00| vmx| I125: USBIO: Up dev=2 'usb:1' endpt=0 stream=0 datalen=4 numPackets=0 status=0 0

2020-02-13T16:37:59.195+11:00| vmx| I125: USBIO: 000: a3 00 00 00 04 00 04 00 ........

2020-02-13T16:37:59.195+11:00| vmx| I125: USBIO: 000: 00 01 00 00 ....

... lots more of these...

2020-02-13T16:37:59.796+11:00| vmx| I125: USBIO: Down dev=1 'usb:0' endpt=81 stream=0 datalen=8 numPackets=0 status=0 0

2020-02-13T16:37:59.796+11:00| vmx| I125: USBIO: GetDescriptor(config, 0)

2020-02-13T16:37:59.797+11:00| vmx| I125: USBIO: Down dev=3 'usb:2' endpt=0 stream=0 datalen=255 numPackets=0 status=0 0

2020-02-13T16:37:59.797+11:00| vmx| I125: USBIO: 000: 80 06 00 02 00 00 ff 00 ........

2020-02-13T16:38:19.714+11:00| mouse| W115: Poll timeout: Something may be hung... ungrabbing

2020-02-13T16:38:19.714+11:00| mouse| I125: MKS: Release starting (Poll timeout)

2020-02-13T16:38:19.714+11:00| mouse| I125: MKSGrab: Resetting grab...MKSGrab: MKS release: start, unlocked, nesting 0

2020-02-13T16:38:19.716+11:00| mouse| I125: MKSGrab: MKS release: end, unlocked, nesting 0

2020-02-13T16:38:19.716+11:00| mouse| I125: MKS: Release finished (Poll timeout)

bevanweiss · ‎02-13-2020

ivivanov I re-ran the USB verbose logging on the 15.1.0 release, and confirmed that it does indeed only become active if the VM itself is restarted. I think that there should perhaps be a simple message box that warns of this when ticking the box for Verbose USB Logging if the VM is already running that says something like 'Verbose USB logging will only take affect on the next start of the Virtual Machine, the current session will not have Verbose USB logging applied'.

I'll direct message you a link to the process dump.

bevanweiss · ‎02-13-2020

ivivanov ok it seems I can't send direct messages.

The process dump is 7zipped, and can be found at the link below

https://drive.google.com/open?id=1YM8A4DfXQcReVXAYyMc7BciMF3ewnohE

Hopefully that provides some additional information which can resolve the issue.

Logs are attached also. This shows the same VM, starting up from shutdown. Once it's started, then I plug in the USB, and attach it to the VM.

In 15.1.0 it didn't crash, so I then proceeded to remove the USB device before shutting down the VM again.

In 15.5.0 (without Enhanced keyboard driver installed), I plugged in the USB, things were still ok, then I assigned it to the VM, and things locked up.

Hopefully it helps.

hotvooboy · ‎02-13-2020

Thanks for your information. we've received the logs and dump files.

ivivanov · ‎02-28-2020

Hi Eric and bevanweiss,

Thanks for your support and for providing the additional details. Based on the new information I was able to root cause the issue - the code entered an endless loop while trying to process some unexpected data sent by the device. Yes, this issue is device-specific, but likely there are multiple devices that can expose this behavior.

I am currently investigating the potential options for a fix.

__________
It is worse!

bevanweiss · ‎02-29-2020

ivivanov is there any ETA for when this might be 'fixed'?

I would have thought a revert of the USB related code that caused the issue would have been relatively straight forward.

Depending on the severity of the bug that the original code change was related to of course.

Hopefully this kind of issue gets added into the automated integration tests, so that it doesn't become a regression and occur again in a future release.

ivivanov · ‎03-01-2020

Hi bevanweiss,

Unfortunately we are not allowed to make any commitments about future releases and fixes, so I cannot provide guidance when this fix would be released.

This bug is not a regression in 15.5, it has been there for ages (I checked the code back to something like 2015), only it has been "masked" in some cases by another bug that has been fixed in 15.5 (some devices were constantly reset while connecting to guest OS). Now that the reset bug is fixed, this one is exposed more often. You are not seeing it with 15.1 because you fall in one of the cases where it has been hidden. In this context reverting the code to the previous state is not correct, however we need to fix the real problem now that it is revealed.

Adding automated regression cases makes sense (thanks for the suggestion), however this is not that trivial. This issue happens only with specific devices (I would say "buggy" devices - they send more data than expected) and we don't have such devices in-house, so it is not easy to reproduce. We can in theory program such behavior in a USB tester device, but this would require some effort. I will discuss this with the team though.

Regards,

Ivan

__________
It is worse!

bevanweiss · ‎03-01-2020

ivivanov sorry, I didn't mean with the use of a USB device / tester.

But this is bad data input into the USB 'stack', it should be possible to test this USB 'stack' in isolation from actual hardware. It should have known inputs available to it from the driver subsystem, so it should be as simple as capturing the sequence of events leading up to this, and simulating this by creating an instance of the USB 'stack' and then sending the equivalent data to it (purely in software).

I'm surprised when you mention that this device was constantly being reset by the VMware system. I would have expected to see some symptoms from this, as the device likely has some amount of state within it also (it does have several modes that it can operate in, which the software configures.. not just baud rates, but also data framing, between Profibus DP, MPI or SPI protocols). It's used for real time monitoring of variables within a control system, so my expectation is that if the USB reset occurred, the connection with the remote device would have been severed, and the data retrieval would have failed. This wasn't seen.

If you need someone to test out a beta release which 'should' fix the issue don't hesitate to let me know.

I'd likely need a week or two of time to enable the testing, since it really can't disrupt the working day like it did the first time around

Regards,

Bevan

ivivanov · ‎03-01-2020

Hi bevanweiss,

I didn't mean that *this* specific device was reset in a loop, but the bug that was fixed for 15.5 was preventing some devices to connect to the guest OS because they were reset in a loop. After fixing the reset bug *for the other devices*, we started executing the problematic code with this specific device which exposed the hanging bug.

For the testing part - yes, we can go that route as well, but it has its own complications. As I said we will discuss this and see what the best approach would be.

Thanks for your help and for offering to verify the fix. Given that 15.1 is working as expected and that I have isolated the reason for the endless loop, I am would expect this is the only problem and the fix would work for this specific device without more surprises.

Regards,
Ivan

__________
It is worse!

bevanweiss · ‎03-13-2020

ivivanov Is there any information available as to whether this issue has been fixed in the recent 15.5.2 release?

I looked at the Release Notes and can find no evidence of this

https://docs.vmware.com/en/VMware-Workstation-Pro/15.5/rn/VMware-Workstation-1552-Pro-Release-Notes....

ivivanov · ‎03-14-2020

Hi bevanweiss,

15.5.2 is a security-only release so no other fixes were included in it.

The fix for the hang is currently being tested and should be included in the next official release (again, this is not an official commitment, but if there are no surprises this the "standard flow").

Hope this helps,

Ivan

__________
It is worse!

crok13 · ‎03-14-2020

2020-03-14

In my case using the Siemens USB/DP connection is a necessity and the current laptop (Windows 10 1809) running VMware Workstation 15.1.0 build-13591040 works. At the office is a newer desktop (Windows 10 1903) which ran Workstation 15.5.1 and updated to 15.5.2 build-15785246 today. The office computer is not used for online tasks and thus the problem never occurred. Through this thread I know not update the laptop to15.5. I also get the feeling the desktop needs to be downgraded to 15.1.

I have another issue which seems to be the same root cause. We use Autem PLC-Analyzer and I'm running version 5.7.2 in a Windows 7 VM. This program is supposed to be used on both computers and at the laptop it works but not at the desktop. The issue is the USB key, that needs to be installed for running the program. It does not connect. First I thought it may be a Windows 10 update problem but think differently at this point. I will downgrade and see if the PLC-Analyzer works with 15.1.

2020-03-15

I was going to do a downgrade but thought it might be good to check the USB/DP connection first. After trying some things with different VMs it worked. Then checking the USB key for the PLC-Analyzer, it also worked. Currently I do not know what happened but it all works now. Maybe a combination of different software and what is/was running at the time.

The laptop will still use Workstation 15.1.0 until there is a good option to test and possibly update to Windows 10 1903.

bevanweiss · ‎05-29-2020

Hi ivivanov,

Is there any update in regards to whether this issue is fixed in 15.5.5 which was released a few days ago?

I checked the release notes, and found mention of a USB fix, but that appeared to be for a specific device, and didn't make mention of the Siemens USB adaptor.

It would be great to get back onto the latest VMware release.

Regards,

Bevan

hotvooboy · ‎05-29-2020

Hi Bevan,

This issue should be fixed in latest release(15.5.5), could you pleas try it and let us know the result. Thanks a lot.

Thanks,

ivivanov · ‎05-30-2020

Hi Bevan,

Yes, the fix is included in 15.5.5, so it should be working now. I hope this was the last issue you would see with WS :-).

Regards,

Ivan

__________
It is worse!

All

USB Device Causing VM's to Freeze - Cannot Kill vmware-vmx.exe