App-V 5: The Case of the Rogue App Path
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 (https://msdn.microsoft.com/en-us/library/windows/desktop/bb762154(v=vs.85).aspx) 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: https://msdn.microsoft.com/en-us/library/windows/desktop/ee872121(v=vs.85).aspx
When publishing the package to the user in App-V 5, the path to the application is registered in HKCU\ Software\Microsoft\Windows\CurrentVersion\App Paths. When the package is published globally, it will register in HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths