Posts Tagged ‘sysinternals’

App-V 5: Do you Still have to Run Process Monitor within the App-V Bubble when Troubleshooting Applications?

If – by that question you want to know if you must start an instance of Process Monitor within the virtual application like you did in 4.x – no. You could run process Monitor inside the virtual bubble, but it will not yield you much more results. The reason behind this is simple: unlike previous versions of App-V, the REAL registry as well as the native file system – NTFS – is used in App-V 5.

In App-V 4.6 and earlier, if you did not launch process Monitor in the virtual application’s environment (usually through a command prompt) all you would capture related to the virtual application would be operations to file and registry resources outside the virtual environment. In Version 5, running Process Monitor as normal will capture access to the actual locations including registry, package store, as well as VFS (Virtual File System) COW (Copy-on-Write) locations. Why just that? Because that’s where things “actually” are located. What you will have to understand is that once the operations to where the application “thinks” it is located has been hooked in the file system and/or registry every subsequent operation will continue as such to include operations only to the:

  • Package Store

  • Integration junction points to the Package Store

  • Actual package Store paths

  • VFS COW (Copy-on-Write) checks and locations

You can see examples of these in the following screenshots from Process Monitor:

Procmon and File Operations:

As you can see above, the query to the initial location of where the virtual applications thinks it is browsing (C:program Files (x86)Java) is clearly not natively where it thinks it is. The App-V engine picks up for this (through relationships in memory) and the operations are redirected to the appropriate converged locations in both the User VFS COW and Package Store.

Procmon and Registry Operations

You will see similar operations when tracing specific activities to registry entries. First, where the application thinks it is supposed to be located followed by subsequent operations to the actual state-separated locations in the actual registry.

Why does Process Monitor not show every Single Operation to “Virtual Paths”

The answer is quite simple – because the App-V Client takes care of all of this behind the scenes which is why you will need to have access to and understand the FileSystemMetadata.xml file as it contains all of the file system mappings for both non-tokenized paths and tokenized paths. The easiest and most automatic relationships are the KNOWNFOLDERID paths which automatically resolve to App-V tokenized paths in memory. For non-tokenized paths, it is handled differently on process creation.

Altitude Adjustment of ProcMon Driver

When you look at the altitudes of the App-V file system drivers and their relationship to the driver altitude, you can see that the Procmon driver sits at a lower altitude by default.

This might make you explore the possibility of raising the altitude to see if Process Monitor will capture more information. Please be careful doing this as this could create problems and system instability. Altitudes are managed and allocated by Microsoft  ( When developers want to register altitude locations for their filter driver, they fill out a special request form. That is how tightly controlled they are in order to prevent instability.


App-V 5: The Case of the Rogue App Path

September 30, 2014 Leave a comment

I have been working issues where it was difficult to determine why a specific application in a virtual application would not launch or trigger under certain circumstances. In particular, when another application called the application directly in order to pass data to that virtual application. Normally, when a native application is brought into the virtual environment through a package or a connection group, it can call other applications and virtual applications for the purposes of sharing data. In App-V 5, a native application, through the shell, can also call a virtual process and pass a file to it. In most cases, this will work with some exceptions – however – I have been able to overcome most of these issues through troubleshooting.

In this particular case the application being called is a virtual application. The application calling it was a home-grown line of business (LOB) application written by the customer to retrieve archival data from a secure portal. When the data was retrieved the data would open up within their preferred ZIP archival utility 7-Zip. 7-Zip was virtualized in this environment with App-V 5. While the virtual application would run would run fine when launched from a shortcut, when called from another virtual application within the same package or from another shell-based application as I later found, it would fail. Monitoring the customer’s custom application from Process Monitor yielded a 135 (hex 0xc0000135 or decimal 11073741515) exit code and the application yielded a pretty direct error message:

Now, before going down any deep troubleshooting, I did my due diligence and attempted reproduction on other machines including a machine as CLEAN as possible. On the clean machine and all but two machines, this issue was NOT reproducible. The plot thickens. Time to eliminate variables.

No, it wasn’t Bad Environment Variables

This was one of the first things I verified. In fact, neither the working or non-working setups had 7-Zip in their search path. Surely including it would fix the problem, and it did make the issue go away – but – while this is a fix – we had not found root cause. I don’t like not having root cause. Besides, the workaround was obviously not needed on the machines not experiencing the issue.

Time for Procmon

I took two different Procmon traces – one from a working machine and one from a non-working machine. I then created a simple filter with “7Zfm.exe” – the primary executable for 7-Zip – under the where “Path” “Contains” filter:


Once I looked at the non-working one through this filter, I had all of the answers in hand. I just needed confirmation from the customer’s developer. You will notice in the trace below, before any search of the path occurred, there was a query to the app paths key within the registry:

The app path returned a local path and not a virtual path. The path was also not existent on the machine. Once that failed, the search path was parsed and the subsequent searches failed. Upon confirming with the developer, the application was calling 7-Zip using the ShellExecuteEx function ( which can be interrupted easily by a “rogue” app path. Upon digging into the registry, we found that the working machines had the correct app path in HKCU . . .


And the Procmon trace showed it was quickly found in the app path:

. . . but the non-working machines had the wrong app path in HKCU:


Removing this rogue app path (which came from their roaming profile) resolved the issue.

More on App Paths

One of the reasons why a native application can call a virtual application is due to the support of app paths in App-V version 5. We did not have this luxury in previous versions of App-V. App Paths allow the shell to call the application by executable without having to use the PATH environment variable. Now with App-V 5, you can call a virtual application by typing in the application in the search dialog box or the “Run” menu or even through API’s (ShellExecuteEx.) App Paths are further documented here:

When publishing the package to the user in App-V 5, the path to the application is registered in HKCU SoftwareMicrosoftWindowsCurrentVersionApp Paths. When the package is published globally, it will register in HKLMSoftwareMicrosoftWindowsCurrentVersionApp Paths

App-V 5: On why the App-V 5 Sequencer *Really* Reboots

September 30, 2014 4 comments

Prior to version 5 of App-V, when you sequenced an application that required a reboot, the reboot was simulated in that the sequencer would process the reboot action including the Pending File Operations and the RunOnce registry keys (RunOnce, RunOnceEx, GuiRunOnce, etc.) when monitoring ceased. In most cases, the simulation would be fine and all of the necessary reboot tasks would be processed properly. There were some exceptions – notably the famous disappearing Google Chrome application famously mentioned  in “Stealth Puppy’s” [I love that handle] “Case of the Disappearing Application During Sequencing “ where after the reboot tasks processed and the monitoring of the installation of GoogleChrome completed, the Program Files directory simply disappeared.

In defense of the sequencer, this was not as much the fault of the App-V sequencing process, but also an issue with the mechanism of the installation. This was easy to prove by going through the sequencing process and verifying the contents prior to stopping the monitoring process. The files were indeed correctly located prior to the stopping of monitoring:

However, when we ran PENDMOVES.EXE (  from Sysinternals, we found this:

The operation pending was to DELETE the actual files. This would explain why the files got deleted after the monitoring process ended. The next logical step would be to see if this was a properly captured operation and not just some bug in the sequencer and install the application natively. Prior to rebooting the machine, run the PENDMOVES.exe utility again. Upon doing this, you will find the EXACT same pending file operation – DELETE C:Program FilesGoogleChrome.

So the native installation does indeed remove the files upon a reboot. The difference is after the reboot, the files are back where they need to be! How is this possible? Google triggers updates using the Google Update service which is set to start automatically. The missing files would force the Google Update service to pull down the most up to date version. Indeed a prime example of some of the exceptions to the rule that the 4.6 sequencer was not catching.

Going back to the original issue – and never passing up an opportunity to showcase a Sysinternals utility – I would recommend a workaround. Given the issue was a DELETE operation, you could leverage another Sysinternals tool to add in a recopy function as a workaround with 4.6. Before actually stopping the monitoring process, first copy the files in question to a safe area.

Then I used the MOVEFILES.EXE utility ( from Sysinternals to have them moved back during the simulated reboot.

Changes in the V5 Sequencer

So to ensure that the sequencer works better with installations that require reboots (or even multiple reboots) the sequencer was changed to actually reboot. When the sequencer detects that the application is requesting a reboot, all tasks are recorded and deleted (except for the PendingFileRenames key) to force resume only after the system is rebooted and the monitoring has resumed, otherwise, these tasks could occur prior to the sequencer resuming. This information is recorded to disk (although obfuscated) and the system will reboot as normal

After the reboot, the PendingFileNames key will be processed as it would in a normal reboot. Upon the user logon, the sequencer will be launched (as it registered itself to do that prior to reboot.) Upon relaunch of the sequencer, the sequencer reads its state from the registry and the file system and restarts monitoring. The first tasks that will be processed will be the RunOnce tasks that were captured prior to the reboot.

One Exception

While the Sequencer User Interface allows for the preservation of settings and a real system reboot, this is not the case for applications sequenced using the PowerShell Sequencer Cmdlets. Since this is mostly reserved for scripted MSI packages, those usually have suppressed reboots anyway.

App-V 5: On Application Launch

September 4, 2014 3 comments

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 ( 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.

App-V 5: On Streaming

June 26, 2014 2 comments

Now that Hotfix 4 for App-V 5.0 SP2 has been out now for several weeks, many of you have likely already seen our Updated Guidance for Performance Recommendations now available on Technet ( It almost goes without saying that the new stream-to-disk model of populating individual state-separated sparse files at the native NTFS level yielded an approach to streaming that came with some caveats and albeit, a few glitches, at first.

It was a big change and a lot of the move from an isolated virtual drive to a state separate immutable package cache directory meant that there would have to be some re-engineering and with that brought changes – including changes at the philosophical level.

The basic concepts remain the same. They are just implemented differently:

In addition, a switch to the use of standard protocols already deeply rooted into Windows occurred completing the change of the streaming landscape. Many customers have asked me to clarify some of the new performance recommendations and the rationale behind some of the choices.


Some concepts require us to rethink how we implement our packages. For example, intra-datacenter streaming, especially for Shared Content Store scenario will yield much better results with SMB or file-based streaming. HTTP, or web streaming, will be better suited for standard streaming especially to devices external to the data center. In the case of Internet-facing scenarios, especially where data would need to be encrypted, HTTPS would be the way to go.

Feature Block 1

When the package needs to stream content for a first launch, the StreamMap.xml file (which is already cached upon publishing) will be parsed.

Once all of the files listed in FB1 (the actual element is PrimaryFeatureBlock) are downloaded, the application can proceed to launch. Our updated guidance mentions the concept of automatic stream faulting upon first launch (which is what always happens in SCS) where if there is no FB1 (like in the example below) the file will be instantly pulled down to populate the sparse file and loaded into memory thus often resulting in a much quicker launch (especially in a scenario where HTTP streaming is being used.) This significant performance hit does not reveal its ugly head as drastic with SMB streaming as it is often going to be faster especially over higher speed LAN links.


Remember – this also not a simple file retrieval process. The files are inside a compressed package. So extraction also has to occur and that’s going to be somewhat less costly with SMB than with HTTP.

When the application launch succeeds, the PreviouslyUsed value in HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientStreamingPackages<GUID><GUID> wil be marked to 1. This also means that if you are using the default configuration, the Autoload settings mean that a background load task will be queued to begin. This will not happen in SCS mode. No Autoload, No FB1.


Removing/Updating Package Content with Opened Packages

We use metadata to govern version and package lineage from a streaming perspective and as a result, many administrators are choosing to forgo the appending of package files to include a version stamp. That is certainly an option but overwriting content on package stores may yield problems. Usually it relates to packages being in use. There are several tools at the ready to verify on your content servers what files may still be open for streaming by clients. You can use the Handle.exe tool for Sysinternals to view and close open packages although I would not advise closing packages, especially in Shared Content Store scenarios as that could create application crashes and lead to data loss.

Since Anonymous authentication is not supported and access is authenticated, you can use the handle command with the –u switch to get user information. You could also revert to the old fashioned NET FILE command if you are using SMB for streaming as well.

It will also reveal the user.

I’ve noticed, and you likely have as well that when working in stream-to-disk scenarios, the handles to the packages can remain open for quite a while – even after the file has been fully cached sometimes. That is actually by design. Each App-V Client will maintain a connection to the package file for each user on a per-package basis. Like the case with previous versions of App-V, this means that there will be a lot of sessions coming from RDS clients. BUT – unlike previous versions of App-V, we do NOT have to deal with limitations caused by ephemeral ports, individual connection on a per-application basis, constant re-authentication on each application launches. There will be one session per package/user combination for stream-to-disk scenarios. NOTE – In Shared Content Store mode you may see multiple sessions depending on stream faults.

With these improvements come some caveats. The client will keep an open handle to the file when using SMB streaming. This is because these sessions involve connect to compressed packages and that can be an expensive process if you need to consistently reconnect. As a result, the App-V Client will cache open sessions for up to 30 minutes past use. I my opinion, this is a small price to pay for the added benefits and scalability that come with the changes.


App-V 5: Application Troubleshooting: On the Origins of an Error Message

May 12, 2014 2 comments

Have you ever been testing a virtualized application and it fails with a bizarre application error that is either extremely vague (unknown error) or coupled with some random hex code? Your first reaction usually is “Where’d that error come from?” That is a good reaction to have as it is the first major hurdle in determining how to troubleshoot what has gone wrong. If you have not narrowed down the target of where the application error is coming from, you leave yourself open for spending a tremendous amount of wasted time down “troubleshooting rabbit-holes.”

Is it an App-V Operational Issue?

The first thing you will want to narrow down is whether or not it is an operational issue coming from the App-V Client itself, or is it related to the package (Application not functioning as expected.) I always recommend to first look at the source of the error window. If the error message is originating from a “Microsoft Application Virtualization” window, it is likely an operational issue tied to one of the client engine components or perhaps a streaming issue.

If it looks to be an operational issue, I would advise you leverage some scripts and tools written by Dave Falkus, one of my colleagues in the UK:

In addition, one of my previous articles will assist you in dissecting App-V error codes:

So I’ve determined it is an error that occurs within the virtualized application itself, now what?

Whether you are isolating an issue that may be caused by virtualization or by bad sequencing, if you have determined the error is coming from the virtual application then it is time to start doing a little reverse engineering with a couple of Sysinternals tools. The first thing I do for an application completely new to me is map out the EXE and DLL launch tree. You can do this by capturing the issue with Process Monitor ensuring that you start capturing at application launch.

You can then run a quick capture filter (I usually load a saved filter with these filter settings)

My filters contain these operation events:

  • Process Create

  • Process Start

  • Load Image

  • Process Exit

If the application is devirtualized on the sequencer, you will be looking to start from the shell process that initiated the Process Create operation (CMD.EXE or EXPLORER.EXE likely.) On a side note, svchost.exe will spawn modern apps, but that is out of scope here. J

If the application is running virtualized on the client, you will see that the AppVClient.exe process interjects spawning the mavinject32.exe or mavinject64.exe process depending on application bitness – followed by the shell creating the process. The example below using virtualized SongSmith displays this in Process Monitor:

Incidentally, if you want to know more about how the AppVClient.exe determines when to run the MAVInjector, read this previous article:

OK, I have identified the EXEs and DLLs, Now What?

You can do one of two things. You can search the Processes for strings using Process Explorer, or in the case of DLLs and EXE’s, you can simply leverage the Sysinternals STRINGS.EXE tool. The Process Explorer tool is great for finding error strings (by going to the properties of a process, selecting the “Strings” dialog box, clicking the “Find” button.)

The reason I do not use this is because it requires the process to still be active and it is not easy for searching DLL modules if they are not still in memory. I use instead the STRINGS.EXE utility ( as it allows for more search flexibility.

Case in point, this bizarre error in Notepad++:

I can confirm the error came from the EXE NOTEPAD++.EXE by using the following command:

Strings-o “C:Program FilesNotepad++Notepad++.exe” | findstr /I scintilla


Putting it All Together

When you get that unknown application error, you can then proceed to investigate towards a resolution using a clear path by:

  • Determining whether it *IS* an application error and not an operational error.
  • Determining if it is a sequencing or virtualization issue.
  • Collecting the Process/DLL load/execution order.
  • Identify which EXE or DLL is contains the error string.

 You can then proceed to continue troubleshooting by focusing around that EXE or DLL with Process Monitor, SpyStudio, APIMon, or whatever tool you prefer to further debug the issue.

App-V 5: The Case of the RunVirtual Collision

February 11, 2014 3 comments

I've discussed running native applications within virtual environments and the many ways we can bring applications like Internet Explorer into the bubble. One of the many reasons we would need to bring IE into the virtual environment is for web applications that use different versions of Java. When you virtualize different versions of Java, the shortcuts that are created will launch inside the bubble (and also through the /appvve switch.) For example, in the figure below, I have two specific Java packages deployed – each with its own Internet Explorer shortcut configured to run inside a separate Java bubble. I use the URL to verify the version.

I can also view the java processes from the sysinternals utility Process Explorer running successfully launched from their own respective immutable package directory locations.

I can use another Sysinternals utility ListDLLS.exe to show that the App-V hook DLL has been injected into the Internet Explorer and Java processes.

You will also notice that if you configure RDS RunVirtual (where you use the AppV RunVirtual registry key to allow Internet Explorer to run inside a virtual package) to load Java into Internet Explorer, that you can see the Java application spawned by the IEXPLORE.EXE process inside of Process Explorer.

Differences from Dynamic Virtualization in SP2

You may notice in SP2 (as I believed I also mentioned in my last blog post) that when you launch Explorer and Internet Explorer, you will find that these also contain the injected AppVEntSubsystems32.dll due to the default dynamic virtualization configuration – however – just because you see EXPLORER.EXE and IEXPLORE.EXE hooked with LISTDLLS does not mean they will automatically behave the same way as if the application where configured for Run Virtual. App-V 5.0 SP2 introduced this feature as response to the historical desire for the virtualization of shell extensions. Actually shell extension virtualization is just one of the side benefits of JITV (Just-in-Time Virtualization – or “Dynamic Virtualization” as it is officially called.) Beginning with Office 2013, there was the capability of virtualization within a process being dynamically activated and de-activated on a per-thread process.

With SP2, this feature was extended to shell extensions AND ActiveX controls implemented as an in-proc COM object. This is why you will see injections of the App-V Hook DLL into Explorer or Internet Explorer even when no virtualized package is in use. This leads to an important statement: Just because the application is hooked, doesn’t always mean it is running virtualized if it appears as a process under the ProcessesUsingVirtualComponents registry value. This will be done at the thread level.

When an ActiveX OCX or a DLL that implements a shell extension is loaded from a native process or a process from another virtual application, App-V generates an additional virtual environment on demand linking the package containing the OCX or DLL with the process. Then dynamic virtualization is turned on for that particular thread. Once the thread exits, dynamic virtualization is turned off. If the said thread with dynamic virtualization spawns another thread, that thread too will be virtualized. This also helps to prevent RunVirtual collisions.

RunVirtual Collisions

When a single native process attempts to launch within more than one primary virtual environment without connection groups, you have colliding virtual environments – and it is not pretty.

In the context of Internet Explorer, they look like this:

Often this will be accompanied by the illustrious “spinning donut!”

How to tell if you have a RunVirtual Collision:

  1. The native application is immediately unresponsive upon launch and it remains unresponsive.

  2. The launch of the native applications spawns multiple packages in use when no connection groups are configured. These are the collisions.

  3. The CPU will be completely pegged:

And the battle waging will be the native processes – usually at least one per package involved in the collision.


Finally, the smoking gun will be running LISTDLLS or Process Explorer against it looking for the actual executable for the virtual package. You will notice that while the native app is hooked, no virtual processes are able to start and get hooked (in this particular example, Java)

The Cause

The cause will most likely be launching the application through a run virtual command (ie Process.exe /appve:<GUID>_<GUID>) configured to run inside one particular virtual environment – while at the same time – that same native application is configured to run virtual inside another virtual application environment using the RDS RunVirtual registry key.

In the case of the above example, that was the exact cause. Internet Explorer was added as a process in the RunVirtual registry key and was configured to run in the Java 1.4 package. If you ran a normal instance of Internet Explorer, everything behaved properly. However, if you ran a shortcut to Internet Explorer configured to run inside a separate instance of Java using the /appvve switch, then the collision occurs.

App-V 5: On Run Virtual, RDS Run Virtual, Virtualizable Extensions, and Dynamic Virtualization

February 4, 2014 8 comments

Update 12/6/2014: With the release of App-V 5 Service Pack 3, there is a change that allows the RunVirtual key to be added to the user's profile (HKEY_CURRENT_USER) to affect user-targeted applications. More information on this improvement can be found here:

If you think that title is a handful, it simply a summary of most of the ways we allow local processes to interact with virtual environments in App-V 5. Whether or not you need to use these features will depend on factors such as targeting or if you want to take advantage of features introduced in App-V 5 SP2. Last year, I gave a primer in a blog on how to run a native process inside an App-V 5 package’s virtual environment. Well, recent question regarding internals as well as product developments have warranted a further discussion on the functionality of “running virtual: in App-V 5.

Run Virtual (RDS Run Virtual)

Designed really for RDS, I prefer to call this RDS Run Virtual as it was designed for RDSXenAppTerminal Servers. Why do I say that? Often application servers will be siloes for specific applications therefore they will likely be published globally. Through a simple registry key, you can have a local process interact with a specific virtual environment. As I mentioned in that blog from last year. You basically add process executable names as subkeys of the following key:


For example, if I have a locally installed application called MyApp.exe and I would like this application to run within the virtual environment, I would create a subkey called MyApp.exe (perhaps a helper application like Adobe Acrobat that may need to be called from a virtualized web application.) I would then put in as the default entry a REG_SZ value that contains the package GUID and the version GUID separated by an underscore (i.e. <GUID>_<GUID>)

If the package is also in a connection group, the native process will be launched into the virtual environment (connection group) where that package belongs. NOTE: The connection group obviously has to be published globally as well. If the GUID pair is invalid or not found, the application will launch natively.

Run Virtual on Demand (using switches /appvve)

I have received feedback on the fact that only global publishing is supported with the RunVirtual registry key. If the application is user targeted and you want a “Run Virtual” equivalent for a native process, you can use the /appvve switch. This is a nice option because it allows an application be brought into the virtual environment regardless of publishing target type. Unlike the RunVirtual key in the registry, you will have to manage this on a per-application basis. Thanks to the VirtualizableExtensions option in the registry, if you simply call the native process through a shortcut extension in the package’s dynamic deployment configuration file, it will run virtual automatically.

Virtualizable Extensions

Speaking of Virtualizable Extensions: This is a special registry value which determines which application extensions will be treated with “Run Virtual” if configured as an application extension point within an App-V application. The extensions are registered under the following registry key:


The value is VirtualizableExtensions and it consist of a REG_SZ data type where all of the supported extensions are listed separated by commas. For example, when you sequence an application like the IBM DB2 client, you may notice that some of the shortcuts are .BAT and .CMD files. In order for those applications to be treated as App-V applications that register properly as extension points, those extensions need to be registered under VirtualizableExtensions. The defaults are: exe, com, bat, cmd, vbs, ps1, cpl, jar, wsf, and wsh. You could add a .TXT extension, but given that a TXT file is not executable by FTA design in Windows, it would be pointless as the most it would do is open up Notepad in the bubble with this extension. But let's say your script interpreter of choice was something like Visual Cobol and you wanted to process a script using a .CBL file. You would have to add in this extension. If a Visual Cobol is locally installed when a CBL script is called through an extension point, it will run it virtually.

Dynamic Virtualization

This was introduced in App-V 5 SP2 in order to give us shell extension support and native interaction with virtualized ActiveX controls. The registry value that toggles this on or off is EnableDynamicVirtualization and it is located in HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientVirtualization

In addition, those processes that are specified for this feature are listed in the ProcessesUsingVirtualComponents registry value located in the same key. By default, Explorer.exe and Internet Explorer are listed there. You can see this in action by using a tool from SysInternals called LISTDLLS.EXE. For example, let’s say I’m on a client configured with the virtualization defaults for App-V 5 SP2 and I currently have one program launched: Notepad++ (yes, I admit it – I use it.)

When I run Get-AppVClientPackage from PowerShell, it shows I only have one application in use:

However, when I run the LISTDLLS.EXE command to find out which processes have the AppVEntSubsystems32.dll injected (or AppVEntSubsystems64.dll for 64-bit processes) you will see both notepad++ and Explorer have been hooked.

And if I were to launch Internet Explorer, I would see the same thing. Do not confuse this interaction with RunVirtual. Dynamic Virtualization has a limited scope of interaction designed for features introduced in App-V Service Pack 2.


Update: 2/7/2014

While I rarely update my blog posts (except for resource pages) it appears that I need to expand further based upon the feedback and comments I have received. When you are virtualizing an application that uses shortcuts that point to BAT or CMD files, you configure these shortcuts just as you would any other application. I’ll use the example of the DB2 client. It sets up a perfect example.

Notice in the figure below we have captured some applications that are executables and some that are scripts.


The shortcut to Command Line Processor Plus (CLPPLUS.BAT) appears as it normally does in the shortcut dialog box.


And the Command Line Processor (which calls a batch file as an argument) appears as normal as well.

Now both of these will be captured into the manifest and dynamic configuration as such:

 Upon the publishing/configuring of the package the shortcuts will then get applied as shortcuts that run inside the virtual bubble. The EXE’s are published with the respective scripts as arguments:


But while EXE’s launch from the integration path and get directly hooked, you will notice that script extensions (BAT, CMD’s) get /appvve applied to it to ensure it launches in the correct bubble:


 The publishing components knew to do this because the extension was listed under the VirtualizableExtensions value inside the App-V registry.

Update 12/6/2014: With the release of App-V 5 Service Pack 3, there is a change that allows the RunVirtual key to be added to the user's profile (HKEY_CURRENT_USER) to affect user-targeted applications. More information on this improvement can be found here:

Virtualize! But How? P2V? I thought you took that feature out of VMM!

January 17, 2014 2 comments

UPDATE: 10/21/2014: The MVMC 3.0 is now released with P2V functionality restored.

One of the most asked questions I have received regarding the latest release of VMM 2012 has been “Where is the P2V conversion feature? Did it go away?” Well yes, The P2V (Physical-to-Virtual) conversion process was deprecated from System Center Virtual Machine Manager 2012 R2. My colleague Mike Briggs wrote about this in an excellent blog:  which also outlines a very specific process with a very helpful architectural diagram to get around this for those who still need to get servers migrated.

What was the objective of P2V?

The primary reason for P2V was to bring legacy physical servers into private cloud. Now that many of the operating systems that were commonly virtualized (Windows 2000 Server, Windows Server 2003, Windows Server 2003, and Windows Server 2008) are either out of support or in extended support. Newer operating systems housing business workloads are more hypervisor-aware and more often than not these days, they are being deployed to private clouds and corporate data centers as provisioned virtual machines as opposed to being deployed directly to bare metal installations.


If you are planning to deploy Virtual Machine Manager 2012 R2 as part of your System Center hybrid/private cloud and are looking for a strategy to migrate all of your physical servers aboard, consider you have these options:

Use VMM 2012 SP1 in parallel: Setting up a parallel VMM server (just like specified in the above mentioned blog post) and a Hyper-V Host Running Windows Server 2012 can still serve as a viable staging environment as this will continue to be supported in the immediate future. Windows Server 2012 Hyper-V VM’s can be easily imported/migrated over to Windows Server 2012 R2. This will be especially important if you are looking to do on-line P2V’s with active servers and you want to minimize downtime. Documentation for performing P2V in VMM 2012 SP1 can be found here:

Disk2VHD: This free utility from the Sysinternals group ( can also perform online P2V’s completely originating from the source operating system creating a VHD or VHDX file ready for virtualization prime time. The latest version adds support for VHDX-formatted VHDs, WinRE volumes, removable media (for capturing,) and includes an option to capture live volumes instead of relying on volume shadow copy (VSS).

3rd-Party Solutions: There are P2V converters out there. Some are rudimentary and inexpensive while others integrate this feature into their enterprise backup and recovery solutions (such as Acronis.) These are also viable options to consider.

App-V: On Named Kernel Object Virtualization (a.k.a. the VObjects Subsystem)

November 5, 2013 Leave a comment

Virtual Objects: You have also possibly heard this referred to as virtual eventing. You have seen references to this in the context of troubleshooting. You may have possibly used this as a workaround when troubleshooting in 4.x:

Add an asterisk wildcard in the following registry path: HKEY_LOCAL_MACHINESOFTWAREMicrosoftSoftGrid4.5SystemGuardObjExclusions

Before you ever do the above again, please read this article.

The question is: what exactly are you doing when you do this and what are the ramifications? Well, first of all, this should NEVER be disabled ad-hominem unless you have a specific reason for doing so. This is especially important in versions prior to V5 where disabling this subsystem actually disabled it for the entire client. Second, if possible, only disable using specific markers for objects pertaining to the application in question. It is understandable to avoid this method as it can be a daunting and tedious task to track these down in the case of some applications. The concept of “disabling virtual objects” in App-V really refers to disabling eventing and essentially everything else under the App-V virtual object isolation subsystem by name or wildcard mask. To understand the function of the virtual object subsystem (or VOBJECT) it will help to have a good understanding of kernel objects in general.

When we speak of kernel objects we are talking about all of the object types that fall into this category, i.e. mutexes, semaphores, base named objects, events, file-mappings, etc. Applications work with objects through the use of handles. This is accomplished by calling a Win32 API that is specific to the kernel object being instantiated. If you want to know more about these individual object types and how they work within the operating system, I would suggest picking up the latest copy of Windows Internals.

When an object is instantiated it is often identified using a string. Because the object is managed by the kernel, this means this object can be leveraged by multiple applications. In the case of App-V, like COM, there is name obfuscation that serves as the isolating factor so it allows for the kernel to still manage these objects and the virtual object subsystem within App-V can allow multiple processes within the same virtual environment to share access to the object.

App1.exe —–> Handle —-> Named Object (ObjEvt1)

App2.exe —–> Handle —-> Named Object (ObjEvt1) (previously created)

Many kernel objects can be named using a string. Because the kernel manages the objects, the name can be used by multiple processes. In the case of the above, Both App1.exe and App2.exe have handles to the named object ObjEvt1. App1.exe can now wait for eventing from App2.exe.


Named Kernel objects are isolated by App-V intercepting calls made to create the kernel object and modifying the name in a manner that only the current virtual environment understands. So if you have multiple applications that need to communicate to each other this way, you will need to ensure they belong to the same virtual environment. If you have a virtual application and a local application that will need to communicate with each other in this way, then you will need to disable naming of these objects.

In the case of application conflict resolution, this isolation process allows the virtual applications running in different virtual environments to create the same kernel object, yet have these objects handled differently by the kernel because the names will be different as far as the kernel is concerned. To put it crudely, if two versions of an application called GROUCHOv1.EXE and GROUCHOv2.EXE respectively need to create and “use” the same object (we’ll call it “cigar”) – then virtualizing them separately under App-V will make this possible as one object will actually be called sg<16-hex digit random ID>_cigar and the other will be sg<16-hex digit different random ID>_cigar.

Now, a pre-populated list of exclusions will show up in the registry under both 4.x and 5.x in order for App-V to be happy in the world of Windows. Adding further exclusions and disabling objects as a whole can be done, however, do NOT remove any existing exclusions that are already populated in the client registry. There is absolutely no reason for you to REMOVE any existing exclusions that you did not put in to begin with. When you are troubleshooting the virtual object subsystem, you may want to add in a single “*” to disable eventing for all objects or add in a specific kernel object name or names (preferred.)

4.6 Object Exclusions

In version 4.6, the legacy list of excluded objects were listed here:


A quick way of troubleshooting would be to create a new string value (I’d usually use 1001001) and enter an asterisk (*) as the value. When the application started to work, I could now use Process Explorer or WinObj to help determine what objects were being created. If I weren’t lazy, I would go back and only enter those object names for exclusion. If I were lazy, I’d leave in the asterisk. This can be dangerous – especially if I were on RDS or Citrix servers where you may have multiple versions of applications/middleware.

One thing I want to drive home is that changes here were MACHINE WIDE. If you wanted to apply these changes to one package only, you would leverage the LOCAL_INTERACTION_ALLOWED policy in the application’s OSD file – however this would also disable some COM virtualization features which you may not want. Bear in mind this policy element in the OSD file still looks up the objects in the virtual environment, but if not found, it will fall back to the native and check there as well. This is why it was and still is a great troubleshooting AND workaround for App-V 4.x.

To enable local interaction, your OSD VIRTUALENV tag should look like the following:





App-V 5 and the VObjects Subsystem

There is not much new under the hood in V5 with regards to how isolation of kernel objects happens. There is more flexibility and granularity with configuration.

There is an element within the Deployment Configuration that you can use to turn on or off the VObjects subsystem for a package:




      <Objects Enabled=”true” />

What is great about this is that it will allow you to disable the VObjects subsystem for a package but still allow for COM to be virtualized. During the start of a virtual environment, the subsystem will read the manifest and Deployment Configuration file and combines them together. If there are multiple packages within a connection group, they will be combined as well.

You also still have the method of using the registry to exclude specific objects although I see no reason to use this as a means of disabling the entire object subsystem since you can do this through the XML on a per-package basis.

The exclusion locations in V5 are found in:


Tools to Isolate Objects

So, when you launch a virtual application, you can easily compare on a clean test machine whether this newly added virtual application package creates kernel objects. All you do is look for the objects that start with the name “sg” then remove that as well as the 16 character numeric identifier preceeding the underscore and everything else to the right of the underscore character is the actual name of the object which you can then use to create a mask for a custom object exclusion. There are two free tools that are great for this:

Process Explorer

When you run Process Explorer and turn on the bottom pane, there will be a view of objects. When you select the virtual processes, you can identify the objects that are virtualized. You will need to sort the object view by name in some cases to make this easier.



Winobj is another tool from the Sysinternals Toolkit that is great to use however, you need to ensure that you run it as an administrator in order to get the right session context since this does not view from a process context. It will allow you to catch any objects you may have missed with the above.