Allowing Better Interaction to App-V Virtual Applications

Each time I work on a Windows deployment project, App-V figures more and more in the conversations that I have with customers.  It is, in my opinion, now a vital tool that is needed in order to successfully migrate an existing platform (or deploy a new one) to Windows 7.  The uses for App-V vary but two of the most common that I see are for eliminating side-by-side Application Compatibility issues and for abstracting applications from the base OS in order to “componentise” the desktop.  One of the caveats with using App-V is that sometimes these virtual applications “don’t play nice” with locally installed applications, creating all sorts of user-unhappiness.  Depending on the applications and their level of interaction, some or all application functionality can be lost because of the processes that are blocked by the SystemGuard feature of App-V.

This very issue came up in a project I have been working on recently.  The issue was that some locally installed accessibility programs that provide a text-to-speech service were unable to read information from virtual applications, so instead of the software saying “File Menu” when clicked, it simply said “Context Menu” for everything.  This was creating a serious problem for the App-V deployment because the IT department are obliged to provide full accessibility options for their users upon request.  The way to solve this issue is to allow better interaction between these locally installed applications and the virtual ones, and to do this there are two common options:

  • Use the LOCAL_INTERACTION_ALLOWED tag in the OSD file.  When this tag is enabled certain named objects and COM objects are created in the global namespace rather than isolated inside a particular virtual environment.  This can allow some locally installed applications the chance to interact better with the virtual application.  The downside to this solution is that potentially you could introduce new application conflicts unknowingly (see linked blog post for more info) as it is a global setting and App-V package specific.
  • Discover the exact objects that need to be allowed to pass through SystemGuard, and enable only these.  This is by far the better option as it is not a global setting and is object specific and per-application, thus limiting to a maximum the chances of any subsequent application conflicts.  The downside is that it can be a very tricky and time consuming task to complete.  However, a very important upside to this solution is that you get to play with the Sysinternals Process Explorer and can show off your skills with this tool!


In this post I am going to explain how to implement the second of the two options presented above.  You must be aware though that the process I describe requires a lot of trial and error and may not work for every single application.  In order to discover the objects that need excluding it is vital that you work through the steps in a very methodical manner and do not take shortcuts.  Although I only document how to do this with one specific application, the process should be the same for any application but your mileage may vary.

The steps to follow are:

  • Prepare a clean test machine that has your text-to-speech software and your virtual application installed only.  This machine should also have the Process Explorer executable already copied to it.  For the example in this post, I am testing the JAWS screen reader program.
  • Open Process Explorer and then run the locally installed text-to-speech application.
  • Locate in the Process column the executable for the application, and select it (in this example, jfw.exe).
  • Go to the View menu in Process Explorer and select “Handles” from the Lower Pane View sub menu.  You will also need to enable this lower pane from the same menu if it is not shown.
  • In the lower pane you will see a list of all the Handles that the process currently has open, click on the Name column heading in order to sort the list alphabetically by this column.  You can see an example of this in the below screenshot.


  • At (or near, the top) of this list of Headers you will see many objects that begin with the string “\BaseNamedObjects\”, amongst this list will be the object(s) that need excluding from SystemGuard in order to make the text-to-speech software read the virtual applications.
  • Click on the File menu and choose “Save As”, then specify a location to save all the process information into a text file for the selected process.  You can now close Process Explorer as you no longer need it.
  • The next part of the process is to clean out all the non-essential information from this recently saved text file.  Open the text file and delete every line that does not contain the string “BaseNamedObjects”.  Once complete, your text file should look similar to the one in the screenshot below.

You need to remove all the duplicate entries in the file (there may be many) so that each line of the text file is a unique object record.  Additionally, depending on your level of expertise, you can remove any entries that you know are not related to either application or the functionality that they use; do this with caution though and don’t remove anything you are unsure about.

This is now a list of potential objects that need to be excluded from SystemGuard, it is highly unlikely that all of them need excluding, and I wouldn’t recommend doing this anyway.  Next is the slow and laborious phase…!


  • Open the registry editor and navigate to the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\SystemGuard\ObjExclusions, you’ll see that there are already 93 excluded objects from SystemGuard by default.


  • Now, you need to add one-by-one each of the objects from your text file and then test the applications to see if they work after each addition. You should not need to restart the computer or the App-V services on the computer, but at the very least you will need to close and re-open the virtual application each time you make a registry change.  The format for each object is as shown in the screenshot below, you will need to manually increment the numbered name of the REG_SZ entry for each new object you add.

You should trim the text from each line until it only includes the object name, and nothing else before or after it. For example, the line “Mutex    \BaseNamedObjects\JAWSOBJHELPEREVENT” becomes “JAWSOBJHELPEREVENT”.


An alternative method, and one I recommend, is to add all of the objects at the start and test the applications.  The benefit of this approach is that, by adding all the objects at the start rather than one-by-one, you can verify whether or not the object that needs excluding is actually in the list in the first place and that the applications work together with this registry change.  If they do work after adding all the objects, you can then simply remove objects one-by-one until the applications stop working correctly; when they stop working correctly you know that they object you just removed is the one that needs excluding.  If you need to add a lot of objects I would suggest scripting this change in order to save time, as the manual addition of each one will take considerable time.


There are a couple of other things you need to understand before commencing.  The first is that it is likely that more than one object needs excluding from SystemGuard, and the only way to identify this is through trial-and-error until you find the right combination of objects.  The second is that if you have multiple objects that begin with the same name then you can use wildcards in the registry strings rather than specifying each full name.  However, I prefer to avoid wildcards wherever possible and name the objects explicitly.  An example of wildcard usage is: ConfigSettings_SectionList_*


Just in case you are wondering, the objects that I had to exclude from SystemGuard in order to allow JAWS to work correctly are the ones below:

  • JawsDdiData
  • JAWSMSAARefreshed
  • JAWSVD_CLIENT_RESET_EVENT_E9075180_85D8_42ea_967D_46F542B86E2E
  • JAWSVD_DATA_EVENT_0F9277D6_2CEE_41b5_A57C_5EBAC435A720
  • JAWSVD_FINISH_EVENT_53351F6B_E1B0_429f_B87E_4F2D671EFF47
  • JFWHodCaretMoved
  • jfwmacrokeys_jfw
  • jfwMSAAShare232640
  • JFWSendMsg
  • JFWSingleInstance


Finally, you should check with the application vendor to make sure that what you are doing with their applications will be supported by them.  The reason for this is that you could potentially only exclude some of the required objects from SystemGuard which might cause application issues internally within these applications further on down the line.


This post was contributed by Daniel Oxley, a Senior Consultant with Microsoft Services UK

Disclaimer: The information on this site is provided “AS IS” with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use


Comments (7)

  1. Anonymous says:

    @Jørn  –  the exclusions apply to the App-V SystemGuard which is local on the machine rather than to the App-V packages.  In the example i described above, JAWS is installed locally on computers and with the solution provided here it allows it to work with the applications virtualised with App-V.

    I have not tried Skype in App-V I'm afraid so don't have any help there.

  2. Anonymous says:


    I have done a "follow-up" post on my own on this very subject:…/working-with-named-object-virtualization-exclusions

  3. Anonymous says:

    @ Kalle

    That is right, you'll need to include the keys in the client's registry.  i prefer it this way because it allows you to make these settings only on the computers that require it, rather than at a package level which means that every computer running the app has these exclusions whether they need them or not.

    so, using the example from the post, these settings i only rolled out to the computers running the text-to-speech software rather than using LOCAL_INTERACTION_ALLOWED which would have meant that all users would have had this setting.


  4. Anonymous says:

    I put together a couple of Powershell commands to automaticaly parse the Process Explorer log and import it into the registry.…/f42f8092-1da0-4a50-a482-39f4ef548714

  5. Anonymous says:


    Very interesting article, thank you for it.

    One question however about the object exclusion method you are describing: although it is not explicitly said I assume from the advice for service restart that you are adding the exclusions into App-V _Client_'s registry? This hardly is a "better" option than LOCAL_INTERACTION_ALLOWED per se because you need to touch each and every App-V Client's registry 😉

    However, there is also a object exclusion in the Sequencer's registry which – if I have not been mistaken (not yet tested it) – actually affects a list of object exclusions stored inside the SFT package (inside the osguard.cp file). Have you tested if App-V Client honors this objects exclusion list as I cannot fathom any other reason why the App-V package would carry such information? If it does work like this, too bad that the Sequencer does not expose this information in the GUI anywhere for editing per package basis, you just have to do it into registry prior to launching Sequencer.



  6. Anonymous says:

    But if the app requires passthrough settings in the first place, why wouldn't you want to have them for all users? Note that I'm not referring to LOCA_INTERACTION_ALLOWED, but rather doing those exclusions in the Sequencer's  HKEY_LOCAL_MACHINESOFTWAREMicrosoftSoftGrid4.5SystemGuardObjExclusions -key, if it indeed propagates customized exclusions inside App-V package to all clients (and only for that app/package)..

  7. Jørn Grotnes says:

    I have the same challenge as Daniel, making Freedom Scientific JAWS and MAGic process events and objects from AppV packaged applications. Again, the registry solution is good as only some machines (XenApp 6.5 servers in my case) should run the accessibility software.

    From what I read here, the exclusions applied to the registry refers to the locally installed JAWS? Bur it would appear that the exclusions should refer to the AppV packaged application. This is to a large extent confirmed by Kalles very good Skype example.

    Is JAWS in your (Daniels) case packaged together with the AppV application so that it works with the Freedom Scientific DLL hook? That'd make for a very large package. Any help on understanding these two examples of exclusion (JAWS local and Skype as an AppV application) would help.