Microsoft Sculpt Ergonomic Keyboard (wireless) on Windows 10 x64 crashes VirtualHere driver. In less than 3 min the keyboard/mouse become unresponsive.
Windows 10 and Raspberry Pi 3 are connected via Ethernet on the same subnet.
Client Windows 10 x64
VirtualHere client x64 3.6.4
System logs
Critical 6/4/2016 2:26:43 PM Microsoft-Windows-DriverFrameworks-UserMode 10111 User-mode Driver problems. The device Wireless Device (location Keyboard Filter) is offline due to a user-mode driver crash. Windows will attempt to restart the device 5 more times. Please contact the device manufacturer for more information about this problem.
Critical 6/4/2016 2:26:43 PM Microsoft-Windows-DriverFrameworks-UserMode 10110 User-mode Driver problems. A problem has occurred with one or more user-mode drivers and the hosting process has been terminated. This may temporarily interrupt your ability to access the devices.
Server is a Raspberry Pi 3.
Server installed on 4/2
Logs on the server are clean.
Jun 4 14:26:45 raspberrypi vhusbdarm[449]: Callback: #027VirtualHere USB Sharing#006_vhusb#004_tcp#005local Name Registered
Jun 4 14:27:02 raspberrypi vhusbdarm[449]: Connection 1 successfully removed (reason:timeout)
Jun 4 14:27:59 raspberrypi kernel: [ 83.549299] usb 1-1.4: reset full-speed USB device number 4 using dwc_otg
Jun 4 14:27:59 raspberrypi vhusbdarm[449]: Device 114 [045e:07a5] BOUND to connection 2
Thanks for your help
Seth
Actually from the log, it
Actually from the log, it seems the microsoft driver that sits on top of the virtualhere driver is crashing. If the virtualhere driver was crashing, windows would get a blue screen. Im not sure if you have purchased virtualhere, but you might like to try the vhusbdarmpi2 binary instead because that is much faster on the pi3 and i think processor/network latency issues are causing this issue. Although the keyboard doesnt send much data, the actual wireless radio that the keyboard uses is virtualized and they generate quite heavy usb traffic. Can you do a
topand see what the cpu usage is when using the keyboard before it locks. If that shows 20-30% or more cpu when using the keyboard it might be worth trying the optimized virtualhere buildMicrosoft Sculpt Ergonomic Keyboard driver crash
I have not purchased yet as I'm doing a proof of concept. I checked load before submitting the initial problem to the forum and found it to be no more than 3% CPU. When I tired a webcam I saw 85% CPU with no issue. I've also noticed that I can prolong the crash as long as I have keyboard/moue activity. So it looks like a possible time out issue.
Thats interesting, im
Thats interesting, im wondering if the dongle is going to sleep? If possible can you change the settings in windows to prevent the dongle going to sleep. Perhaps its turning off and thats not getting back through from the server to client. VirtualHere doesnt support remote sleep.
Also 3% cpu is fine, no need for the optimized version
Microsoft Sculpt Ergonomic Keyboard and VirtualHere
I don't see a way to disable (if exists) a sleep capability for the dongle. The only thing I see is the ability to enable/disable the keyboard/mouse from waking the computer.
My best guess is the dongle
My best guess is the dongle is sleeping, so if it cannot be changed to stay awake, i dont think it will be compatible with virtualhere.
SOLVED - Microsoft Sculpt Ergonomic Keyboard and VirtualHere
I took another stab at it and found the following in Device Manager | Human Interface Devices:
USB Input Device | Properties | Power Management | uncheck "Allow the computer to turn off this device to save power"
I found two objects one fro the Keyboard and one for the Mouse. I left them alone.
I had to ID "USB Input Device", as my computer has three. I would suggest identifying which one is the culprit instead of disabling power management for all.
Thanks Michael.
-Seth
excellent, thanks for posting
excellent, thanks for posting feedback as it might be useful for others...