App-V 5 – Virtual Shell subsystem failure 2A-00000002

Article
08/20/2016

Hi all,

I came across a really interesting error code recently and thought it was worth sharing why it occurs, the error message that’s presented to the user looks like this when launching an application.

App-V 5.0 SP3 Client - 0x9B50172A-0x2 / 0x9B50172A-0x00000002

App-V 5.1 Client - 0x9B501A2A-0x2 / 0x9B501A2A-0x00000002

You can see that the error codes are different but they are the same error code, its the changes in the client version that causes the difference. If you look in the event log you will see the following message:

 App-V 5.0 SP3 Client
Process 4564 failed to start due to Virtual Shell subsystem failure. Package ID {a3ee2888-fda4-43b8-8ca5-7c2b58a26893}. Version ID {37bdd39e-3760-47f0-b950-2b01e6827930}. Error: 0x9B50172A-0x2

App-V 5.1 Client
Process 4260 failed to start due to Virtual Shell subsystem failure. Package ID {a3ee2888-fda4-43b8-8ca5-7c2b58a26893}. Version ID {37bdd39e-3760-47f0-b950-2b01e6827930}. Error: 0x9B501A2A-0x2

Whenever we receive these messages you need to do a debug on what the error code translates to and which debug event log to enable.

Both error codes translate to the following:

 Code: 9B50172A-00000002 / 9B501A2A-00000002
Result: Error
Type: Windows
HRESULT: 0x00000002

# winerror.h selected.
# 2 matches found for "0x00000002"
# for hex 0x2 / decimal 2
  ERROR_FILE_NOT_FOUND                                           winerror.h
# The system cannot find the file specified.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x2
# for hex 0x2 / decimal 2
  ERROR_FILE_NOT_FOUND                                           winerror.h
# The system cannot find the file specified.

From a debug perspective you can enable the following logs dependent on the App-V Client version your using:

 App-V 5.0 SP3 - Microsoft-AppV-Subsystems-VShell/Debug 
App-V 5.1 - Microsoft-AppV-Client/Debug (ServiceLog)

In the debug event log, you will see the following message:

The question now is what are the Integration points with the App-V client?

Rules of integration

When App-V applications are published to a computer with the App-V Client, some specific actions take place as described in the list below:

Global Publishing: Shortcuts are stored in the All Users profile location and other extension points are stored in the registry in the HKLM hive.
User Publishing: Shortcuts are stored in the current user account profile and other extension points are stored in the registry in the HKCU hive.

https://technet.microsoft.com/en-us/itpro/mdop/appv-v5/application-publishing-and-client-interaction

If you check the registry for the user, you will see the integration points for the packages published to the user.

There are two keys:

 Integration Location: The integration location is the path in the file system to the junction point of the package using the PackageID only
Staged Location: This is the real location within the App-V cache with both the PackageID and VersionID specified

If you check the junction point in explorer you will see that the integration location is pointing to the staged location without the version GUID.

To prove that this is the case you can run the following commands which will display the junction points from the Integration location:

 cd %LOCALAPPDATA%\Microsoft\AppV\Client\Integration
dir /AL

That’s the context of what the integration point is with App-V but what causes the error?

If you check the package that’s causing the error in my case, it’s the PackageID “A3EE2888-FDA4-43B8-8CA5-7C2B58A26893” which can be seen from the debug event log.

Note: This is important the Virtual Shell subsystem failure will return the PackageID of the package, if the package is in a connection group then the PackageID and VersionID will actually be the Connection Group GroupID and VersionID so make sure your using the debug event logs for finding which package is causing the issue. You can see below the IDs have changed as the package is now in a connection group.

 Process 600 failed to start due to Virtual Shell subsystem failure. Package ID {8d7a6c1a-0336-4a3f-a758-c3d7c4a2b225}. Version ID {735fa6ea-7ce8-4c85-b4f7-186fd97f26e6}. Error: 0x9B50172A-0x2

If you check the PackageID it returns the following and it shows something really interesting that the package is published globally and not to the user.

The package not being published to the user is the interesting point here as if you check the registry for the user you will see that the integration point is set in the users registry hive:

That’s the cause of this error code, the App-V client reads the integration point information in the registry to check where the integration location is, it then checks if the path is valid and if its not it causes the "sytem cannot find the file specified" hresult. If you delete the key “{A3EE2888-FDA4-43B8-8CA5-7C2B58A26893}” or remove the “Integration Location” and “Staged Location” entries then the application will launch successfully.

If you want to check if you have a mismatched integration point you can use the following script:

 <#
.DISCLAIMER The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
#>

########################################
# Function Test-RegistryValue
########################################

Function Test-RegistryValue($regkey, $name){

Get-ItemProperty $regkey $name -ErrorAction SilentlyContinue | 
Out-Null
$?

}

########################################
# Function Check-UserRegistryIntegrationPackages
########################################

Function Check-UserRegistryIntegrationPackages(){

$User = "CurrentUser"
$Integration = "SOFTWARE\Microsoft\AppV\Client\Integration\Packages"

# Opening Current User Registry
$registry = [microsoft.win32.registrykey]::OpenRemoteBaseKey("$User","localhost")

$i_CAVURIP = 1
$Results_CAVURIP = @()

$Packages = $registry.OpenSubKey($Integration)

$SubKeys = $Packages.GetSubKeyNames()
$SubkeysCount = $SubKeys.Count

    foreach($Subkey in $SubKeys){

        if((Test-RegistryValue "HKCU:\$Integration\$Subkey" "Integration Location") -eq $true){
        
        $SL = Get-ItemProperty "HKCU:\$Integration\$Subkey" -Name "Staged Location" | select -ExpandProperty "Staged Location"
        $IL = Get-ItemProperty "HKCU:\$Integration\$Subkey" -Name "Integration Location" | select -ExpandProperty "Integration Location"

        $IL_Expanded = [System.Environment]::ExpandEnvironmentVariables($IL)

        $Result_CAVURIP = New-Object System.Object
        $Result_CAVURIP | Add-Member -MemberType NoteProperty -Name ID -Value $i_CAVURIP
        $Result_CAVURIP | Add-Member -MemberType NoteProperty -Name RegKey -Value "HKCU:\$Integration\$Subkey"
        $Result_CAVURIP | Add-Member -MemberType NoteProperty -Name StagedLocation -Value $SL
        $Result_CAVURIP | Add-Member -MemberType NoteProperty -Name IntegrationLocation -Value $IL
        $Result_CAVURIP | Add-Member -MemberType NoteProperty -Name IntegrationLocationExpanded -Value $IL_Expanded
        
            if((test-path "$IL_Expanded") -eq $true){

            $Result_CAVURIP | Add-Member -MemberType NoteProperty -Name IntegrationLocationValid -Value $true

            }

            else {

            $Result_CAVURIP | Add-Member -MemberType NoteProperty -Name IntegrationLocationValid -Value $false

            }

        $Results_CAVURIP += $Result_CAVURIP
        $i_CAVURIP++

        }

    }

    return $Results_CAVURIP

}

Check-UserRegistryIntegrationPackages | ? { $_.IntegrationLocationValid -eq $false }

The main question which I’m sure your thinking about is what can cause this?

Generally, it’s caused by profile management solutions preserving the HKCU\Software\Microsoft\AppV registry key.

A scenario where this can be caused is a package has been published to the user, you then find that it’s an application that all users require it so you decide to publish it globally (To the machine) and remove the user publishing.

Because the profile management solution is preserving the entire HKCU\Software\Microsoft\AppV key the user integration is captured and not removed when the user logs back in even though it’s now published globally.

The fix is to remove the entry in the HKCU\Software\Microsoft\AppV location then the application will launch successfully.

SCRIPT DISCLAIMER
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

To conclude if you follow the process above you can find out which package is causing the application launch failure.

David Falkus | Senior Premier Field Engineer | Application Virtualization, PowerShell, Windows Shell

Partager via

App-V 5 – Virtual Shell subsystem failure 2A-00000002

Ressources supplémentaires