ExitVe – An escape hatch from the App-V virtual environment


App-V, Tools

Every now and then there might be a need to start processes outside the virtual “bubble”, from within the bubble; to effect changes to the real system or examine it without Virtual Environment (VE) being in a way. Since App-V does not natively offer such a capacity, I decided to write our own tool for doing just that: escaping the VE through a hatch!

The idea behind the tool is rather simple; you run it while operating inside the VE (such as during pre-launch script with PROTECT=”TRUE” set, or from your own application that is run as virtual application) and it takes another program as a command which it then starts outside the virtual environment. Or if omitting parameters from invocation completely, it starts the same process as the calling process which makes it handy as a quick way to launch e.g. another command prompt.

This actually makes it behave a little bit like the infamous sftlp.exe -program that App-V Client ships with and which John Sheehan used ingeniously in his blog article from few years ago; the only functional difference being that the started process escapes the confines of virtual environment.

So let’s imagine a situation where we have a command prompt operating inside VE (as illustrated with access to the Q: drive and pre-set environment variable pointing to it):

Command prompt inside the VE

From the registry editor launched from the command prompt we can see that there’s registry entries coming from our virtual registry (i.e. {ExtendedHistory} –key as used by packages saved from AVE, which stores extended package history information):

Registry editor inside the VE

Now, launching regedit.exe as a second instance but with the help of ExitVe –utility:

Registry editors both inside and outside VE looking at the same key/branch

As we can see, our second instance of registry editor does not see any of the virtual registry markings from the package so it has to be running outside the package’s VE. To test it further, let’s launch another copy of cmd.exe using the utility by simply starting ExitVe without any parameter (because our cmd.exe in the bubble is the parent process):

Command prompt running outside the VE

As we can see, there’s no environment variables set for SFT_MNT nor can we access the Q: drive anymore. And this command prompt was launched from the virtual process, so it has clearly “escaped” the virtual environment.

So how is all of this possible, you may ask at this point?

Glad you asked, let me explain!

In a little bit similar way of how the problematic issue of launching embedded objects (notably Microsoft Office’s) outside the virtual environment can happen – which was blogged about by Nicke just today – I chose to utilize the fact that if you can make somebody else outside the bubble to do the launch for you, the launched process will effectively escape the virtual environment through a “hole in a ground” of sorts.

Just by doing normal CreateProcess() for a process won’t help, since it will be confined to the same environment as the parent process, but luckily there exists an another method (besides that funky COM –related in-process-becoming-out-of-process activation described in Nicke’s interview, which is of no general use however for arbitrary process launches). And that method is called WMI!

You see, WMI contains not only readable properties but it can also be used to do all sort of stuff that change things and launching processes is just one of the many functions in it. There’s actually a ton of examples on a ‘Net for using WMI for process creation in all possible languages including scripting, but I decided to make a small executable to make it even easier.

What’s useful – or rather critical I’d say – for our escape-the-VE purposes, is the fact that like the COM activations, WMI –based process creation actually starts the process through already-running WMI host service. Which incidentally then makes the newly created process free of the individual App-V package’s bubble!

So there you go, a handy tool for starting another processes outside the bubble; to be used with scripting or whatever. It’s not up yet on our free tools page, but I will be publishing this tool in a couple of days (when I have the time to write short text about it on the site, basically) and you are free to download and use it however you please.

, , ,

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.

7 Comments on “ExitVe – An escape hatch from the App-V virtual environment”

  1. Dan Gough (@packageologist) Says:

    Interesting! Does this apply to all actions done through WMI or just creating processes? For example if what would happen if I ran a VBScript inside the bubble that used WMI to write to the registry?


    • Kalle Saunamäki Says:

      I think it should apply to all WMI-based actions, since WMI is running as a service. Then again, if the operation is performed against user profile -specific location (like HKCU in your example) it obviously must have some mechanism for doing the things in the context of that process..

      Maybe a good candidate for an another article perhaps..!


      • Dan Gough (@packageologist) Says:

        Hmm, will need to do some testing! There are many things that don’t work properly in App-V but WMI is rarely mentioned. As well as this problem, sequenced apps that rely upon their own custom WMI providers may be broken too.

  2. Pollonium Says:

    Good work. I wonder how an application running in the bubble can actually get the information that it IS RUNNING in the bubble. I know I can check the environment variable %APPV_VAPPNAME%. In my environment I do not see the registry key {ExtendedHistory} you have mentioned. Is there a more reliable way like a specific DLL / API CALL that can tell me more about the App-V environment I am running in?


    • Kalle Saunamäki Says:

      {ExtendedHistory} registry key is stored in the VE by our Application Virtualization Explorer -product (if extended history entries are enabled in the settings) when it saves modified package, it is not created and/or used by App-V itself.

      To my knowledge, pretty much the only way to check that process is inside VE is to check presence of %SFT_MNT% variable (%APPV_VAPPNAME% was introduced in 4.6 I think…), no specific API calls exists that I know of.



  1. ExitVe – An escape hatch from the App-V virtual environment | End User Computing | Scoop.it - 21.11.2011

    […] ExitVe – An escape hatch from the App-V virtual environment Every now and then there might be a need to start processes outside the virtual “bubble”, from within the bubble; to effect changes to the real system or examine it without Virtual Environment … Source: blog.gridmetric.com […]

  2. ExitVe now available for download | Gridmetric Blog - 23.11.2011

    […] the utility for starting processes outside App-V virtual environment, from within that environment, is now available for […]

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 )

Twitter picture

You are commenting using your Twitter 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: