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):
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):
Now, launching regedit.exe as a second instance but with the help of ExitVe –utility:
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):
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.
21.11.2011 at 17:17
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?
21.11.2011 at 17:24
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..!
21.11.2011 at 17:32
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.
14.03.2012 at 11:50
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?
16.03.2012 at 15:58
{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.