Enabling (service) process access to App-V virtual environment



Back in the last November, Sebastian Gernert who works as a Microsoft’s Support Escalation Engineer wrote an article about fixing Volume Shadow Copy –related issue with the App-V Client in the German App-V blog (browse the site with Chrome and you get handy translation prompt if you don’t read German).

While the actual issue itself as outlined in the article is not terribly interesting unless you happen to do backups on your Windows 7 machine with VSS enabled and are concerned with such error condition, the most interesting tidbit found in the article concerns of one specific registry key of the App-V Client.

ServiceInclusions key

As Sebastian instructs, you can add to the HKLM\SOFTWARE\Wow6432Node\Microsoft\SoftGrid\4.5\Client\AppFS\ServiceInclusions –key a new string registry value “VSS”, with the value data of “swprv”. In the case of 64-bit Windows, that key is naturally in the 32-bit registry side so additional Wow6432Node applies to the path.

As one would expect, no further explanation or discussion is provided about this key or the meaning of the value that had to be entered to make VSS to play along with App-V. And, of course, Microsoft has not been documenting this particular registry key in the official documentation either. So what does it do?

Now, if you are smart and remember what has been said earlier (around 4.5 timeframe) about App-V Client granting a special access to certain processes to VE, and you can read between the lines of the Sebastian’s post and you are able to deduct information from the name of the key itself as well as the value data – the meaning of this key becomes pretty clear: its purpose is to allow certain Windows Service processes into App-V’s file system (aka. the Q: drive)!

To examine the thing further, I took a look at the machine with 4.6 SP1 Client installed and there’s already a couple of entries pre-populated for that key:

ServiceInclusions key in default 4.6 SP1 installation

The text data for the values suspiciously looks like service names, so after little bit of browsing through the services currently installed on the machine both of the listed services can be identified.

One of the entries is for a service called “Application Identity”, which has something to do with correct functioning of AppLocker –feature and which has an internal service name of “AppIDSvc” (matching the data in the value):

Application Identity service's settings

Another entry from the key matches “Microsoft Antimalware Service”, which is the Security Essentials/Forefront Client’s service and which has an internal service name of “MsMpSvc”:

Microsoft Antimalware Service's settings

Makes sense; App-V Client allows both AppLocker and AV an access to the virtual drive so that they can see all applications over there. In a way, this also makes the part of the explanation of “certain privileged processes” more transparent as you can actually see what gets the special treatment. The reason I say it’s only partially transparent is that there’s still some other processes (like, I think, lsass.exe and winlogon.exe) that doesn’t get listed in the key but still has the access to all virtual environments and/or virtual drive.

But does this mean that we could actually grant the same access to any process of our own?

Access to virtual drive for any service process

As the name of the key implies, the system is designed to allow access for the Windows service process executable and not just any random process running in the system, so adding new entries for things like cmd.exe will not fly.

For the purpose of testing a service process access using the ServiceInclusions -key, we would then need to have our own custom Windows service that tries to take a look at the Q: drive. Fortunately it’s very easy to create service executable with C# (there’s pre-built template project for it in Visual Studio as well) and as such, here’s a complete listing for it (Service1.cs, sorry if the code looks bad as I couldn’t figure out how to format it nicely):

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Diagnostics;
using System.IO;
using System.ServiceProcess;
using System.Text;

namespace ServiceTest {

public partial class Service1 : ServiceBase

public Service1()



protected override void OnStart(string[] args)


string[] dirs = Directory.GetDirectories(@”q:\”); foreach (string directory in dirs)

File.AppendAllText(@”c:\temp\appvdirlist.txt”, directory + Environment.NewLine);




File.AppendAllText(@”c:\temp\appvdirlist.txt”, “No access to Q” + Environment.NewLine);



protected override void OnStop() { }



This test service generates executable only 7KB in size, and it has been designed to dump list of directories in the root of the Q: drive to text file in c:\temp, and to handle possible error in enumeration, when it starts up. Nothing more, nothing less.

Compiled service executable

Now that we have our compiled executable, let’s install it to the system as service. For the purpose we can use excellent sc.exe which ships with Windows (sc create “ServiceName” binPath= “PathToExecutable”), running with elevated privileges of course:

Installing service using sc.exe

We now have an interestingly named service called “QDriveTest” in our Services –applet, which we can start and examine whether or not we get anything in the c:\temp\appvdirlist.txt file:

Starting test service

Sure enough, the text file is created and looking inside it shows that (as expected) our service does not have an access to the virtual drive:

Service has no access to Q: drive

As our purpose is to enable that access, let’s stop the service, remove the text file and make some modifications into our registry key. Remembering the naming format of that VSS key, we add a new string-type value into ServiceInclusions –key under AppFS –key and give freeform name for it. The important part is the value data, since that has to match our service’s name (“QDriveTest” in this case):

Adding custom inclusion for service

Since the setting we are modifying applies to the filesystem part of the App-V Client, we need to restart App-V Client’s own service (“Application Virtualization Client”) to make changes to take effect. After restart (remember that if you have virtual applications running, restarting this service makes them to disappear immediately!), we can start again our own service. And what is it that will be written to the log file now…?

Successful enumeration of package directories on Q drive

It’s success, that’s what it is! My test service was able to go to the Q: drive and list my (modest) list of virtual application packages mounted over there. I didn’t bother to test it, but I’m 100% sure it could have been possible to go into each of those directories and see and access all of the package files from my service’s code.

What this post demonstrated is that it is possible to have access to App-V’s virtual drive, if you are creating software that installs a Windows service. Naturally as long as you add that service of yours into App-V Client’s registry entries so it knows to allow access to it.

Btw, it’s worth noting that the registry key discussed exists only beginning of 4.6 RTM Client, so 4.5 and older clients do not have this key or are able to use it even if created to the registry manually.

, ,

About Kalle Saunamäki

As one of the first four Microsoft App-V MVP's, Kalle has been doing application virtualization since 2003 and virtualization in general from 2000, and is a recognized in-depth technological expert in Microsoft application virtualization community.

View all posts by Kalle Saunamäki


Subscribe to our RSS feed and social profiles to receive updates.

10 Comments on “Enabling (service) process access to App-V virtual environment”

  1. JRV Says:

    Thanks for this explanation! I had the Hyper-V/App-V/VSS problem and found the German article, but it was pretty light on details. While everything worked after I added the registry entry, understanding what it does reduces the risk of using it. I did a search to see if I could find out more, and your just-written article came up.

    This should be an MSKB article.


  2. Julian Says:

    This is great!
    Do you think this can be relied upon in the future?
    Do you think it will ever be documented?


    • Kalle Saunamäki Says:

      Well, it’s hard to say on behalf Microsoft but I’d guess this likely is one of those features which are not really meant to be exposed to “outsiders” so no, I don’t think it will be documented. The client registry is already poorly documented by MS anyways…


      • JRV Says:

        Since it makes Hyper-V VSS and App-V work together, and those two products are integral to many RDS implementations, I can’t think of a reason they’d want to keep it a secret. Unless it’s dangerous, in which case they probably need to document that now that the cat’s out of the bag.

        But it smells to me like nothing more or less than an oversight. I’m going to post a link to this blog on the Partner feedback group and suggest they turn it in to a KB article.

      • Kalle Saunamäki Says:

        It is probably an oversight, like in “oh crap, there’s that VSS thing we should have added to the default list as well”. Maybe they add it with some upcoming hotfix tho?

      • JRV Says:

        Amen…it needs to be a HF, and made an invisible part of running Setup.exe in App-V v.Next!

        My speculation is that it was supposed to implemented as part of 4.6 Hotfix 4, which claims to solve this very problem–but does not. It’s common for a HF to require adding a registry entry to activate…it just needs to be documented! Or else, like you say, it was supposed to be added automatically. Be interesting to see if the reg hack works with 4.6 pre-HF4, not that that is worth spending time on.

        Anyway, I’ve just submitted my partner feedback; I’ll just hope this will be the one time it actually does some good.

        Clever investigative work, by the way, Kalle.

  3. Terry Wing Says:

    I added new string registry value “VSS”, with the value data of “swprv as per instruction but still no luck in my Windows 7 x64 Home Premium. I’m still getting the VSS error relating to Q drive.


    • Kalle Saunamäki Says:

      Hello Terry,

      I have no idea what could be causing it if the values are indeed as they should be (most importantly the service’s actual name), but one possibility that comes to mind is that Home Premium is not supported OS for App-V Client for all I know?



  1. SC 2012 Orchestrator – Режим обслуживания SCOM по расписанию « ИТ Блог Алексея Максимова - 16.08.2012

    […] на заметки Deutscher App-V Blog – App-V und VSS–Backup oder kein Backup… и Gridmetric Blog – Enabling (service) process access to App-V virtual environment пришёл к выводу о том, что между VSS и виртуальным […]

  2. SC 2012 Orchestrator — Режим обслуживания SCOM по расписанию | Блог IT-KB - 07.09.2013

    […] на заметки Deutscher App-V Blog — App-V und VSS–Backup oder kein Backup… и Gridmetric Blog — Enabling (service) process access to App-V virtual environment пришёл к выводу о том, что между VSS и виртуальным […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: