App-V 5 – Service failed to complete requested operation – 06-00000011

Hi all,

I've worked with a few customers and they were receiving the following error code when running the "Get-AppvClientPackage" PowerShell cmdlet.

Get-AppvClientPackage : Application Virtualization Service failed to complete requested operation.
Operation attempted: Get Packages.
AppV Error Code: 0600000011.
Error module: Catalog. Internal error detail: 86B09F0600000011.
Please consult AppV Client Event Log for more details.


If you translate the error code it translates to:

Code: 86B09F06-00000011
Result: Error
Type: App-V
Module: Catalog (06)
HRESULT: 0x00000011

Knowing how App-V 5 works ( ) we checked WMI functionality on the client to see if that was ok, but running a wbemtest and testing the "AppvClientPackage" instance caused the following error:


The 0x80004005 error translates to a WMI "Generic Failure" so that doesn't really help but there is obviously a problem.

For some general WMI troubleshooting check out the following post:

As its an App-V 5 client error its time to have a look at some of the debug logs, so we used a script that I wrote and posted here:

First look in the debug event log output was the following entry which is trying to give away the issue.

ERROR: Failed to load a manifest document from the Catalog for package 0db55a56-24ea-4918-9f7a-d7f3e75f6440, version 037ecc82-414c-46f9-b5bc-1022b5dfa79a because the manifest actually belongs to package 0db55a56-24ea-4918-9f7a-d7f3e75f6440, version 3f84e348-7378-44ca-9630-458fbc936c4e.


The error message is now telling us what to do "VerifyManifestDocument" but where should I look for this? Well the error code translated module is the Catalog and its failing on a "Get-AppvClientPackage" so lets check the machine catalog for all packages.


What you will see in the folder for the PackageID "0db55a56-24ea-4918-9f7a-d7f3e75f6440" is two folders which means that there have been two versions of the package added to the machine.


If you open up the folder with the VersionID "037ecc82-414c-46f9-b5bc-1022b5dfa79a" that's causing the issue from the event log entry and there should be two files:

  • DeploymentConfiguration.xml
  • Manifest.xml

If you open up the Manifest.xml you will actually see the problem, the VersionID specified in the Manifest.xml "3f84e348-7378-44ca-9630-458fbc936c4e" is for the other version of the package when it should be "037ecc82-414c-46f9-b5bc-1022b5dfa79a".


So firstly how do you fix it? And secondly what causes it to occur which is the most important piece.

To fix this you have to remove the package from the machine, but as you can't use "Get-AppvClientPackage" you have to use the "Remove-AppvClientPackage" directly as that still works in this situation.

Remove-AppvClientPackage [-PackageId] GUID [-VersionId] GUID

You can see below, the initial "Get-AppvClientPackage" fails, then I've removed the package using the PackageID and VersionID, which allows the "Get-AppvClientPackage" cmdlet and WMI query to function correctly.


As per my other posts there has to be some scripting automation to help you, so here is it a PowerShell script to check all package catalog entries. What the script is doing is:

  • Looping through all the Package Catalog entries in the Registry
  • For each package it opens up the Manifest.xml for PackageID and VersionID and checks if they are the same
  • If the Package Catalog VersionID matches the VersionID inside the manifest then its a "Pass", if not it sets the output as a "Fail".
# Function Check-AppVCatalogManifest

function Check-AppVCatalogManifest(){

$Catalog = "C:\Programdata\Microsoft\AppV\Client\Catalog\Packages"

$i_CAVCM = 1
$Results_CAVCM = @()

$AppVCatalogManifest = gci $Catalog

    foreach($CM in $AppVCatalogManifest){

        $AppVCatalogManifestID_Folder = $CM.Name

        $AppVCatalogManifestID = $AppVCatalogManifestID_Folder.Trim("{","}")

        $Version = gci $Catalog\$AppVCatalogManifestID_Folder

            Foreach($CM_v in $Version){

            $Result_CAVCM = New-Object System.Object
            $Result_CAVCM | Add-Member -MemberType NoteProperty -Name ID -Value $i_CAVCM

            $VersionId_Folder = $CM_v.Name

            $VersionID = $VersionId_Folder.Trim("{","}")

            $Manifest = "$Catalog\$AppVCatalogManifestID_Folder\$VersionId_Folder\Manifest.xml"

            [xml]$ManCon = gc $Manifest

            $DisplayName = $ManCon.Package.Properties.DisplayName
            $Man_PackageID = ($ManCon.Package.Identity.PackageId).toUpper()
            $Man_VersionID = ($ManCon.Package.Identity.VersionId).toUpper()
                if($Man_VersionID -eq $VersionID){

                $Result_CAVCM | Add-Member -MemberType NoteProperty -Name DisplayName -Value $DisplayName
                $Result_CAVCM | Add-Member -MemberType NoteProperty -Name PackageID -Value $AppVCatalogManifestID
                $Result_CAVCM | Add-Member -MemberType NoteProperty -Name VersionID -Value $VersionId
                $Result_CAVCM | Add-Member -MemberType NoteProperty -Name Manifest -Value $Manifest
                $Result_CAVCM | Add-Member -MemberType NoteProperty -Name Status -Value "Pass"


                else {

                $Result_CAVCM | Add-Member -MemberType NoteProperty -Name DisplayName -Value $DisplayName
                $Result_CAVCM | Add-Member -MemberType NoteProperty -Name PackageID -Value $AppVCatalogManifestID
                $Result_CAVCM | Add-Member -MemberType NoteProperty -Name VersionID -Value $VersionId
                $Result_CAVCM | Add-Member -MemberType NoteProperty -Name Manifest -Value $Manifest
                $Result_CAVCM | Add-Member -MemberType NoteProperty -Name Status -Value "Fail"


            $Results_CAVCM += $Result_CAVCM



    return $Results_CAVCM



Once this is ran it will return a status of "Pass" or "Fail", if a package fails that package would need to be removed following the steps above.


If you want to just check for failures then you can add the following to the script:

Check-AppVCatalogManifest | Where-Object { $_.Status -eq "Fail" }

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.

The next question is what causes this issue and how can you stop it occurring?

This error is related to "Append Package Version to Filename", which is an option on the App-V 5 Sequencer. Some customer don't like the .appv filename changing when you upgrade / edit a package.


If the box is checked you will see the following if the package is upgraded / edited and saved:

  1. PackageName.appv
  2. PackageName_2.appv
  3. PackageName_3.appv

If its unchecked then every time you save it the package name with stay the same i.e. PackageName.appv.

So how does this relate to the error? This comes down to how you manage your packages on your content share! You maybe thinking why does that matter? Here's the scenario:

  1. On the sequencer you create a package called PackageName.appv
  2. You then copy the package to your content share \\appvserver\contentshare\PackageName folder
  3. You then add that package to the App-V 5 Management Server and stream it to your App-V 5 client via the "Sync-AppvPublishingServer" cmdlet
  4. You then find there is something wrong with the package so you remove it from the Management Server and re-sync the App-V 5 Client which unpublishes the package but it doesn't remove the package from the machine (This is the important piece)
  5. You then copy the package to the sequencer and upgrade or edit it, once saved you copy it to the SAME folder \\appvserver\contentshare\PackageName 0verwritting the previous files
  6. Once copied you add the new package which has the same PackageID, same .appv filename, but a new VersionID and Version i.e. to the Management Server
  7. You then stream that package to your client and everything looks good, the upgraded package works, but remember there are two packages streamed from the same folder with the same filename for the .appv file i.e. PackageName.appv
  8. The machine is either rebooted or the App-V Client service is restarted
  9. Once restarted if you run "Get-AppvClientPackage" from PowerShell the error occurs and you have to follow the steps above to address it

The only way I can show this as you can't run a get "Get-AppvClientPackage" is to check the path set in the registry and you will see both Versions of the Package are using the same PackageURI.

\\appvserver\contentstore\Visual Studio Code 1.0.0 x64\Visual Studio Code 1.0.0 x64.appv



To conclude if you follow the process above to manage your packages you may get the above issue on the App-V 5 client, make sure your testing is done in a test environment not in production.

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

Comments (4)

  1. Trentent says:

    How did you translate the error?

    1. Dafalk says:

      Hi Trentent, error translation post coming soon…
      Thanks for the comment Vigneshwaran

  2. Benjamin Parziale says:

    What an awesome blog post ! Thank you very much – this solves our Problem we have already since many months with
    updated packages.
    Good Job.
    Best regards.

Skip to main content