Well, my theory about the VMware Horizon Client crashing the drivers hasn’t been completely disproved but, an hour so after my last post the crash did occur again (this was with the Horizon Client running on the two Intel Graphics Adapter connected monitors). This is what the failure looks like in Event Viewer:
!](https://d2r1vs3d9006ap.cloudfront.net/s3_images/1623716/2017-07-19_09h52_45_inline.png?1500472380)](https://d2r1vs3d9006ap.cloudfront.net/s3_images/1623716/2017-07-19_09h52_45.png?1500472380)
!](https://d2r1vs3d9006ap.cloudfront.net/s3_images/1623717/2017-07-19_09h53_19_inline.png?1500472425)](https://d2r1vs3d9006ap.cloudfront.net/s3_images/1623717/2017-07-19_09h53_19.png?1500472425)
Since it is the UMDF drivers that are crashing I targeted that angle in my troubleshooting. A few searches turned up some known problems with the Microsoft provided USB 3.0 drivers in Windows 8.1/10. Those drivers appear to be from 2013 and Windows Update does not offer any newer at present. Microsoft’s stance is that their USB 3.0 driver is ‘good enough for most folks’ so it would appear that especially the xHCI driver hasn’t had much additional development or testing done. However, Intel has continued to develop and test their first party USB 3.0 driver and releases updates semi-regularly for Windows 7 et al. that provide better device compatibility than the comparable Microsoft drivers.
With this in mind I found a source for the latest Intel USB 3.0 drivers that are re-signed/modified to install in Windows 10 and compatible for most intents and purposes:
http://www.win-raid.com/t834f25-USB-D…
However, these drivers did not seem to solve the crash by themselves as I experienced a crash after rebooting post-installation.
Along with the updated Intel USB 3.0 drivers I noticed there was a newer BIOS update for my laptop so I downloaded and flashed that to my machine as well. While performing a post-flash inspection of the BIOS options I noticed that there was a USB 3.0 port mode option which allowed the user to select whether the SuperSpeed USB 3.0 ports were presented to the OS as only USB 3.0 ports, only USB 2.0 ports, or ‘Auto’ which was a hybrid mode allowing the OS to set the mode based on the connected device.
This BIOS option seemed like a big clue to the issue as the ThinkPad dock seemed like it was hung/disconnected when the Plugable adapters would freeze (the dock would show a re-connection pop-up from its tray icon in Windows and would resume functionality while the Plugable adapters would remain frozen until reconnected). This USB 3.0 option for the SuperSpeed ports was set at ‘Auto’ so I set it to ‘Enabled’ instead (so as to try and eliminate the possibility of the dock trying to switch modes post-connection of a device which I theorize could easily cause a UMDF device driver to stop working).
Upon rebooting into Windows, the dock behaved quite strangely with the built-in audio adapter being detected but the Gigabit Ethernet adapter showing up as a non-enumerated USB device and thus not usable. Googling around in regards to NIC issue I found reports of this behavior when the USB 3.0 BIOS option was toggled on specific BIOS revisions. So I went back into the BIOS and reset the mode to ‘Auto’ then booted back into Windows. This allowed my dock behavior to return to ‘normal’ and the NIC returned and was usable again (I noticed Windows re-installed the driver). With the NIC restored, I did a final reboot into the BIOS and turned the option again back to ‘Enabled’ for the USB 3.0 ports. This time when Windows booted the NIC remained unmolested and was usable.
At this point I also had come across some troubleshooting advice for UMDF USB device driver crashing issues which recommended enabling the option for ‘Show Hidden Devices’ in device manager and then uninstalling *all* USB Hubs for *both* the USB 2.0 and USB 3.0 types and then allowing windows to re-detect and install their driver (in this case the modded Intel drivers). I performed this un-installation, rebooted Windows, and let the OS re-detect and re-install all USB Hub devices.
The last steps with clearing the USB Hubs was completed yesterday by close of business and today I’ve been docked and working on the 4 monitors without any visible issue since then. I say ‘visible’ because upon resuming from sleep I see in Event Viewer that the UMDF crashed as pictured again but it would appear windows was immediately able to reset the UMDF services and Plugable device drivers to a working state before any image came onto the monitors as I never noticed anything freeze/flicker or drop out. Hopefully I am on track to having the issue functionally resolved.
To summarize, at this point it doesn’t look like VMWare Horizon Client is the actual culprit as I have gone back to using that software spanned across the two Plugable-connected monitors and have not yet experienced a crash while working. The root cause is looking to be related specifically to my ThinkPad Yoga S1 with this BIOS option that allows the USB 3.0 port connection mode to be altered, and/or the cleanup of ‘ghost’ devices on the USB Hub devices in the OS. I believe either the toggling of the USB 3.0 BIOS option and/or the cleanup of the USB hubs has either helped with or eliminated the issue as things have been smooth so far today.
I will post back in a day or so to confirm if things appear to be resolved but for now it looks promising. I know my posts are novels but my hope is that someone with the same hardware may be assisted if they run into this or a similar issue