VMware Horizon Community

AppVolumes 2.18.4 Broke USB Redirection for Scanners

Well ..I already had this typed out for a stutus report for my boss so I though I would post here and see if anyone is seeing anything similar.

These are just some notes I have jotted down while I have worked on this today.  Hope they are meaningful for you.  Ha.   I already have a case open...just thought I'd reach out to the community.


Fujitsu scanners not being found Scandall Pro and Adobe Pro.  Horizon sees that they are redirected via both scanner redirection and USB redirection.   The Scanner is listed in the Device Manager of the VM.

Might scan one or two docs but fails shortly after with a bogus mini driver error.


This seems to have started occurring right after the App Volumes upgrade to 2.18.4 but not many reports of it since very few users are in the office and using their scanners.     I remember flipping back to  an image with the old 2.16 agent and the problem went away.   Rolling back to 2.16 is not an option as best practice is to have both the APP Volumes Manager and Agent running the same version.


Found that by follow this boot sequence, scanning works: 

  • Ensure scanner is powered off
  • Take a view session via the thin client
  • Once logged on, power scanner on.
  • Scan as much as you can stand

Well This worked for a while but now it is not.    HR scanned several documents by following this procedure one week but this week, the sequence makes no difference.   This was never going to be a solution.

Tested image with new 2.18.6 agent that was just released.   Did not fix.

Recaptured ScandAll pro in App volumes 2.18.  Did not fix

Installed and tested Scandall Pro on the master instead of an App Volume.   This did not work at first but then I had an “aha” moment.

  1. Scanning works as desired if Scandall Pro is installed on the master and NO other app stacks are attached.  Tested this at least 10 times.
  2. Scanning does not work if Scandall Pro is installed on the master and the user has App Stacks attached. Also tested this at least 10 times

To me..this screams that the App Volumes filter driver in the 2.18.4  version is causing this.

With this Knowledge, I believe I have proof that this is an App Volumes bug.   On 8.25.2020 I created and SR with the VMware App volumes team.   Explained what I found and demonstrated to VMware rep.    Grabbed the App Volumes logs and Procmon logs and uploaded to  the case.    Waiting for logs to be examined by engineers now.  

This is a very difficult issue to troubleshoot with users and myself being out of the office.  It is rare to find a user with a scanner in the office and the scanners hybernate overnight which means when I VNC into a TC, the scanner cannot be redirected for testing.

For additional confirmation that the 2.18 agent cause this issue, I am going to downgrade the app volumes agent to 2.16 as a test to see if the issue still exists.

Release notes for 2.18.6 just came out.   Many bugs addressed.   See here:  https://docs.vmware.com/en/VMware-App-Volumes/2.18.6/rn/VMware-App-Volumes-2186-Release-Notes.html

The Environment variable issue and memory leak issue are concerning.

0 Kudos
2 Replies
Hot Shot
Hot Shot

In 2.18.2 and 2.18.4 there is a memory leak. Basically it is a complete breaker, your VM will exhaust memory within a week and eventually the horizon view agent will die and become unreachable because there is no memory at all to be used by the VM.

0 Kudos

Hi jmatz135​ and thanks for replying.

I am aware of the memory leak in both versions you speak of.   I have been watching for this issue closely but since I am using instant clones that don't make it past 24 hours, I really don't experience the leak nor does the agent fail due to lack of RAM.   I am leaning more towards the SVDriver additions at this point.  There seem to be a lot of chances since moving to  2.18.4.  

Current Config for me:











*\svchost.exe||-k netsvcs*













I have also taken note of the Environment Variable issue in this release but I don't see that factoring in either.   I really don't seem the volumes over-writing necessary paths or variables.

I have not heard back from the Engineer at VMware regarding his diagnose of the logs but sure am looking forward to it.  I think?

0 Kudos