Upgrading from 4.6.0 to 4.7.0 - devices eject after a few seconds with surprise unbound

Submitted by gsor09 on #1

Hello,

I have a Windows 10 computer with vhusbdwin64.exe v4.6.0 installed via the Microsoft Store (big mistake as I now have learned).

Apparently vhusbdwin64 was upgraded automatically to v4.7.0 (or someone else manually upgraded without my knowledge).

Since then we have SUPRISE UNBOUND messages when we try to use most devices connected to the Windows computer.

Behaviour : right clic > "use this device" > the UI freezes a few seconds > The device is reserved (in bold in the UI) > then after around five seconds it disconnects. A few devices were unaffected but most were unusable on this version since the disconnect happens every single time on those devices.

I tried setting onReset.$VENDOR_ID$.$PRODUCT_ID$ to an empty value as suggested here without but it did not resolve the issue.

The devices are wibukeys from Wibu-System for CodeMeter licensing : https://www.wibu.com/products/wibukey.html
We are using the same powered USB hub since the beginning and never had any issue of this type on version 4.6.0 and before.
We have rolled back to v4.6.0 and reinstalled the service with the "-b" argument without Microsoft Store but won't be able to upgrade until this is fixed.

QUESTIONS :
- is there an archive page with all previous versions of vhusbdwin64.exe somewhere ? (We were lucky to have kept v4.6.0 or else we couldn't have rolled back)
- is this a known bug? Maybe related to "Added $NICKNAME$ to onUnbind event" in v4.6.3 ? (I would check if I had access to this binary)

Thank you for your time

Submitted by Michael on Thu, 2024/11/07 - 07:06

#2

Actually the windows store is a different version of the virtualhere server and i dont think its compatible with wibu. (Its definately not compatible with iLok)

 

You need to uninstall the windows store version and download the one from this website to update to 4.7.0

Submitted by gsor09 on Fri, 2024/11/08 - 23:30

#3

Hello,

As suggested, I tried v4.7.0 with the version on virtualhere.com and I have the same issue as before : right clic > "use this device" > the UI freezes a few seconds > The device is reserved (in bold in the UI) > then after around five seconds it disconnects

Rolled back to v4.6.0 : no issue whatsoever.

If you have a way for me to download all versions between 4.6.0 and 4.7.0, I can try them all and help you pinpoint exactly which minor version dropped support for wibukeys.

Submitted by Michael on Sat, 2024/11/09 - 09:07

#4

I tested both the windows store version 4.7.0 of the virtualhere server and the version 4.7.0 here and both work fine with my wibu-box/U+ key. 

Can you do this.

  1. In the virtualhere server click Settings->View Server Log->Clear Log
  2. Attempt to reproduce the problem on the client by trying to use the wibu key via virtualhere
  3. When it drops, on the server click Settings->View Server Log->Copy to clipboard and paste into this forum thread

Submitted by gsor09 on Fri, 2024/12/13 - 21:32

#5

Hello,

Sorry for the late answer.

SERVER 1 (old)

Here is the client log for a dongle that is not working:

2024-12-13 12:27:00 INFO  :VirtualHere Client 5.7.8 starting (Compiled: Oct 15 2024 15:45:46)
2024-12-13 12:27:00 INFO  :Client OS is Windows 10 (build 19045), 64-bit edition
2024-12-13 12:27:00 INFO  :Using config at C:\Users\username\AppData\Roaming\vhui.ini
2024-12-13 12:27:00 INFO  :IPC available at \\.\pipe\vhclient
2024-12-13 12:27:05 INFO  :Drivers are up-to-date
2024-12-13 12:27:05 INFO  :Connected to the VirtualHere Client Driver (Version 2)

On the server side (v4.7.2):

192.168.10.64 connected as connection 10 (Standard TCP)
Device 5 [064f:2af9] BOUND to connection 10 
Device 5 [064f:2af9] SURPRISE UNBOUND from connection 10
Unmanaging device 5 [064f:2af9]
Found Full speed device [064f:2af9] "WIBU-SYSTEMS AG, CodeMeter-Stick" at address 5 
Connection 1 successfully removed (reason:timeout)
Connection 10 remotely disconnected gracefully (rx msg size) 

(I'm guessing the last two messages are because I exited the client application)

With version 5.8 of the client:

2024-12-13 13:13:30 INFO  :VirtualHere Client 5.8.0 starting (Compiled: Nov 26 2024 16:39:51)
2024-12-13 13:13:30 INFO  :Client OS is Windows 10 (build 19045), 64-bit edition
2024-12-13 13:13:30 INFO  :Using config at C:\Users\username\AppData\Roaming\vhui.ini
2024-12-13 13:13:30 INFO  :IPC available at \\.\pipe\vhclient
2024-12-13 13:13:38 INFO  :Drivers are old, they will be upgraded
2024-12-13 13:13:41 INFO  :Connected to the VirtualHere Client Driver (Version 2)

And from the same server (v4.7.2) same dongle:

192.168.10.64 connected as connection 15 (Standard TCP)
Device 5 [064f:2af9] BOUND to connection 15 
Connection 13 successfully removed (reason:timeout)
Device 5 [064f:2af9] SURPRISE UNBOUND from connection 15
Unmanaging device 5 [064f:2af9]
Found Full speed device [064f:2af9] "WIBU-SYSTEMS AG, CodeMeter-Stick" at address 5 

 

EDIT 1: OK very weird. I installed v4.7.2 on a brand new server and I don't have the same issue I have on my other (old) servers...

SERVER 2 (new)

Client:

2024-12-13 13:25:37 INFO  :VirtualHere Client 5.8.0 starting (Compiled: Nov 26 2024 16:39:51)
2024-12-13 13:25:37 INFO  :Client OS is Windows 10 (build 19045), 64-bit edition
2024-12-13 13:25:37 INFO  :Using config at C:\Users\username\AppData\Roaming\vhui.ini
2024-12-13 13:25:37 INFO  :IPC available at \\.\pipe\vhclient
2024-12-13 13:25:46 INFO  :Drivers are up-to-date
2024-12-13 13:25:46 INFO  :Connected to the VirtualHere Client Driver (Version 2)

Server:

192.168.10.64 connected as connection 36 (Standard TCP) 
Connection 34 successfully removed (reason:timeout)
Device 3 [064f:2af9] BOUND to connection 36 

Both servers (1 and 2) are on the exact same hardware. No external USB hub. If check "show hubs" I can see on both servers two "Root Hub" with either one or two keys each.
Server 2 is directly in the same subnet as the client, server 1 is in a subnet accessible via a VPN tunnel but with which we have no issue whatsoever with our other applications.
I compared the two servers config files: as excepted they have different It, EasyFindId, EasyFindPin, ServerName, License, DeviceNicknames and DeviceIdMap but same PingInterval (40) and PingTimeout (90)

 

EDIT 2:

Again very weird. I have found one wibu key that is working on server 1 (device 7 - serial 000005579934). This dongle is on the same "Root Hub" as the dongle "device 5" (serial 000005236570) which wasn't working (and still isn't working) in my first logs. Here are the new logs:

2024-12-13 13:42:04 INFO  :VirtualHere Client 5.8.0 starting (Compiled: Nov 26 2024 16:39:51)
2024-12-13 13:42:04 INFO  :Client OS is Windows 10 (build 19045), 64-bit edition
2024-12-13 13:42:04 INFO  :Using config at C:\Users\username\AppData\Roaming\vhui.ini
2024-12-13 13:42:04 INFO  :IPC available at \\.\pipe\vhclient
2024-12-13 13:42:09 INFO  :Drivers are up-to-date
2024-12-13 13:42:09 INFO  :Connected to the VirtualHere Client Driver (Version 2)

Server 1:

192.168.10.64 connected as connection 22 (Standard TCP) 
Device 8 [064f:2af9] BOUND to connection 22 
Unmanaging device 7 [064f:2af9] 
Found Full speed device [064f:2af9] "WIBU-SYSTEMS AG, CodeMeter-Stick" at address 7 
Connection 17 successfully removed (reason:timeout)

I also found this in my client logs but not sure which key I was trying when this happened:

2024-12-13 13:25:37 INFO  :VirtualHere Client 5.8.0 starting (Compiled: Nov 26 2024 16:39:51)
2024-12-13 13:25:37 INFO  :Client OS is Windows 10 (build 19045), 64-bit edition
2024-12-13 13:25:37 INFO  :Using config at C:\Users\username\AppData\Roaming\vhui.ini
2024-12-13 13:25:37 INFO  :IPC available at \\.\pipe\vhclient
2024-12-13 13:25:46 INFO  :Drivers are up-to-date
2024-12-13 13:25:46 INFO  :Connected to the VirtualHere Client Driver (Version 2)
2024-12-13 13:35:51 INFO  :In file ../src/msw/treectrl.cpp at line 2228: 'TreeView_SortChildrenCB()' failed with error 0x000000b7 (Cannot create a file when that file already exists.).
2024-12-13 13:35:51 INFO  :In file ../src/msw/treectrl.cpp at line 2228: 'TreeView_SortChildrenCB()' failed with error 0x000000b7 (Cannot create a file when that file already exists.).
2024-12-13 13:35:51 INFO  :In file ../src/msw/treectrl.cpp at line 2228: 'TreeView_SortChildrenCB()' failed with error 0x000000b7 (Cannot create a file when that file already exists.).
2024-12-13 13:35:56 INFO  :In file ../src/msw/treectrl.cpp at line 2228: 'TreeView_SortChildrenCB()' failed with error 0x000000b7 (Cannot create a file when that file already exists.).
2024-12-13 13:35:56 INFO  :In file ../src/msw/treectrl.cpp at line 2228: 'TreeView_SortChildrenCB()' failed with error 0x000000b7 (Cannot create a file when that file already exists.).
2024-12-13 13:35:56 INFO  :In file ../src/msw/treectrl.cpp at line 2228: 'TreeView_SortChildrenCB()' failed with error 0x000000b7 (Cannot create a file when that file already exists.).
2024-12-13 13:35:59 INFO  :In file ../src/msw/treectrl.cpp at line 2228: 'TreeView_SortChildrenCB()' failed with error 0x000000b7 (Cannot create a file when that file already exists.).
2024-12-13 13:35:59 INFO  :In file ../src/msw/treectrl.cpp at line 2228: 'TreeView_SortChildrenCB()' failed with error 0x000000b7 (Cannot create a file when that file already exists.).
2024-12-13 13:35:59 INFO  :In file ../src/msw/treectrl.cpp at line 2228: 'TreeView_SortChildrenCB()' failed with error 0x000000b7 (Cannot create a file when that file already exists.).

EDIT 3:

And now device 7 on server 2, after working for a while, is not working anymore... Yet I haven't restarted neither the client nor the server...

Submitted by Michael on Mon, 2024/12/16 - 06:38

#6

The pings must be 3 and 10 not 40 and 90. 

Can you stop and exit the server then set the ping times back to those values.

The ping times are critical because that's how virtualhere knows if the connection is dropped or slow. Its impossible to know otherwise. TCP does not have the concept of a broken connetion (Allowing users to set this is actually problematic i think im removing this in the next build...)

This is a guess but your vpn or network connection might be really really slow (i.e ping times > 3 sec) which is not a supported scenario

 

Submitted by gsor09 on Mon, 2024/12/16 - 19:45

#7

Unfortunately with the default settings of 4 and 9 we kept getting very frequent disconnects on VirtualHere... (At least on older versions. I will trial the settings you just gave me with a limited set of users with v4.7.0 and keep you posted)
...and with each disconnects the software package we use VirtualHere for will display a warning telling the user that the license could not be found and proceed to crash. Losing all unsaved progress in the process. Which is of course something very frustrating for users and what I was trying to avoid with those very high ping settings.
If you have more documentation on how these two settings work internally and how I can tune them so that the connection are not dropped so often I'm very interested.

Do the clients also need to have their ping set to the same setting as the server? (3 and 10)

With these new settings on the server (PingInterval=3, PingTimeout=10) it unfortunately doesn't solve the issue described in my first post. Wether I use "Server Ping Period = 3, Server Ping Timeout = 10" or "Server Ping Period = 3, Server Ping Timeout = 90" in the client settings.

Do you have any other troubleshooting tips?

Submitted by Michael on Mon, 2024/12/16 - 20:48

#8

If you are getting disconnects something is wrong with your network. You need a stable network before using virtualhere. Do not change the defaults.

In the virtualhere client, right click on the server , select Properties, Latency. That should be <50ms

 

 

Submitted by gsor09 on Mon, 2024/12/16 - 21:25

#9

I didn't know about the statistics/latency panel. Very nice.

I have 1ms to 3ms with the servers directly on my subnet and 9ms to 12ms with the servers on the other side of the VPN tunnel.

In two minutes time I saw three spikes at 24ms max.

Any other suggestion or more logging I can do on the one server that won't let me connect to the wibu dongles?

Thank you

Submitted by gsor09 on Wed, 2024/12/18 - 23:00

#11

Hello,

Both 4.6.5 and 4.6.7 work without any issue on the three dongles/devices that weren't working on 4.7 :/

We will stay on 4.6.7 for now. Please keep me posted if I can help you pinpoint the issue on 4.7 in any way.

At least now I have more sane ping settings.

Thank you