using vhserver on W11 22h2 diconnect/connect issues

Micheal:

 Greetings, I am a recent purchaser and user and have a few 'concerns' I have noted using the server and client software.

 1) I find that making a connection from client machine removes the device (HD) from the Host Explorer roles. I could not find documentation about this, so, is this normal?

        if the above is characteristic of the intended operation, this would mean that only 1 client can access the server at any time, and that the host will lose whatever device          was called for the sessions duration, is this correct?

 2) in windows 11 22h2, using the server, then disconnecting the client side, causes Windows to treat the process as disk error, and seeks to scan that disk! This is completely unacceptable as the windows system will keep logging the disk in error status, causing read/write errors.

Issue 1 makes the software useful only as a 'one shot' deal. Meaning it is useful only for specific transfer of data, one client at a time. Not what I had read in the product description page.

Issue two is even more serious as the host OS will continue to flag the used device(s) (HDs), thus degrading the drives metrics and performance each time it is use

 Please advise: I have not had the time to look into the software, its metrics, etc; so I could easily be missing things.

 

Thank you

 

JB

#2

1. Yes this is expected behaviour, you can only use a usb device one place at a time. Just like an extension lead.

2. This is some issue with your software i think. You can use HD easily between vh and the server and back again with no disk errors. What disk are you using?

#3

 on w1122h2, the drives are all affected, 2-Seagate Expansion (4 and 6Tbyte) and a WD (Western digital 3T).

 I seriously doubt it is either the Drives as 2 are New, and the WD is a year old with no performance or disk IO errors ever, all have worked flawlessly using both server software, Http server software, FTP and FTPS. I have used vh both on the 'farm', and with the server side shut down; the effect is the same.

 I have multiple test boxes and VH did not exhibit the anomaly (reporting io/drive error) in Linux Native, Linux on WSL2 [W10Ent], nor on W10 Pro... also, I did let W11 run the scan several times with no reported disk errors. This seems to point to the un-hook process in vh only while on W11. It is known that W11 has rebuilt much of their IO wrappers in this latest build.

 one last thing, I further tested the drives by disconnecting the drives and reconnecting vis USB with no similar anomaly.

 I like vh as it is perfect for my intended use (injecting changes in data, in configs, and other simple tasks from my remote base machine without all the fuss and overhead of other similar offerings out there.

#4

Ok thanks for the info.

" using the server, then disconnecting the client side, causes Windows to treat the process as disk error,"

Im wondering if its just taking a while to read all the directories and when its stopped being used on the client during this time it will cause this issue. 

If there are a lot of files/directories on the disk  it will take quite a bit longer for Windows on the client side(where the virtualhere client is running) to read the disk due to the network latency.

Regarding the statement above you are talking about the PC that is running the virtualhere client, the windows running there treats the process as a disk error?

 

#5

Micheal:

 Greetings, and much appreciation for the replies. No, it was not the client side; it was on the W11 server side that the error appears. I went through all the drive-drivers; ensured they were all updated then found WD had an issue patch. It appears they discovered the same io behaviour relating to NAS, and Server-side call handling. After applying the patch, it seems perhaps the issue is now resolved.

 The real puzzler was that it affected the other two drives (not WD's); so I contacted a dev associate of my days at redmond, and he informed that the behaviour was not only not unexpected (with WD, as their drivers often need retweeking after Win upgrades like 7to10to11); the issue is that the Hive records the drive io error in a master drive hive, thus they all were receiving the same flag for scanning.

 I will update you if the bad behaviour returns, but I don't expect it to do so. 

Thanks for the replies and info.... and let others know if they do encounter such issues; even though their drivers are showing latest releases to check with vendors for available issue patches as I did.

\

Jon B