App-V 5: On Application Launch
In previous blog posts, I discussed what happens when a package is added/configured, published, and when streamed. But what happens when an application is double-clicked? App-V needs to determine if the application needs to be virtualized, and if so, which virtual environment. The Shortcut is launched. The Junction point is parsed to the right version location in the package cache. The executable’s process is created but there will be a process notify callback by the App-V Virtual Environment Manager (AppVVemgr.sys) to determine if the process should be virtualized or not. Now, I previously blogged about this part of the process last year and gave a convoluted diagram (https://blogs.technet.com/b/gladiatormsft/archive/2013/09/12/app-v-5-to-virtualize-or-not-to-virtualize-how-app-v-5-answers-that-question-when-you-launch-a-shortcut.aspx) which was met with entertaining emails.
Assuming the application is going to be virtualized, after that workflow has completed, then either the AppVEntSubsystems32.dll or the AppVEntSubsystems64.dll is injected into the virtual process depending on the bitness of the application. Of course, it will always be the 32-bit DLL if working exclusively on X86 platforms. You will notice that once an application is running, there are a few ways you can tell if an application is running virtualized or not. I’ve previously mentioned ListDlls.exe from Sysinternals but you can also use Process Explorer, but not for the reason you may think. The “Virtualized” tab within Process Explorer refers to whether the application is being run within WoW64 (for 32-bit applications) rather native x64. Nothing to do with App-V just as the “Package Name” field refers to the base AppX package and applies to modern applications.
But you can use other features of Process Explorer to determine if a process is virtualized with App-V. For example, you verify the path and command line as they will show launched from the location of the package cache.
That is not completely full proof because you could also have an application that is locally installed but has been configured to run inside a package’s virtual environment. This also means the application will have the AppVEntSusbsystemsXX.DLL injected as well. So just search for that. You can do it through the stack itself but that will require you to walk to the individual thread stacks.
Instead you could just simply do a search in Process Explorer for the DLL and you will get a response back of every process for which that DLL has been injected
Besides injecting this DLL into the process, several other events are taking place. The App-V Virtual Environment Manager will also create all of the elements needed for that virtual environment including the attaching of the VFS COW Filter driver to the appropriate volumes and send the COW registry and file mappings to the driver assuming they have been staged properly – otherwise, that must also take place. The Virtual subsystem controller must also establish the subsystems with the proper settings based on the packages catalog (COM, Objects, etc.) which is why it is mandatory that these settings match when you are creating and enabling Connection Groups as the settings for the entire Package Group Catalog would also have to be created should this be the first application that is launching in a published Connection Group.
Comments
- Anonymous
September 04, 2014
I've also noticed that AppV 5 applications have a small overhead when launching applications that appears to disappear after the ~15th launch.
http://trentent.blogspot.ca/2014/06/appv-5-shared-content-store-performance.html
Don't suppose any insight could be provided? - Anonymous
June 30, 2015
~ John Behneman | Senior Support Escalation Engineer Hello everyone, John Behneman here again. I’d like - Anonymous
June 30, 2015
~ John Behneman | Senior Support Escalation Engineer Hello everyone, John Behneman here again. I’d like