The Collection

A collection of useful information.

Filtering by Tag: error

App-V Error: 00000002

Quicky post on a common App-V error code.

If you've gotten to the point where you can view the sftlog (C:\ProgramData\Microsoft\Application Virtualization Client\sftlog.txt) and see this entry then most likely the problem is with the CODEBASE line, specifically the HREF element. Make sure it is set tot he right protocol (FILE, RTSP, RTSPS, HTTP or HTTPS), the right server (either %SFT_SOFTGRIDSERVER% or the hardcoded servername) and the correct port (80, 322, 554 etc.).

App-V: Error Code 0000C800 (Update)

I have a previous post about this particular error here, but a recent App-V Blog entry reminded me to post the other (though not nearly AS common if your DBA's aren't asleep) solution.

Catch that over here.


This can occur if TCP/IP is disabled in SQL Server Configuration Manager under SQL Server Network Configuration on the App-V Database SQL Server.


On the SQL Server where the App-V Database resides, launch SQL Server Configuration Manager, navigate and expand the SQL Server Network Configuration node and enable the TCP/IP protocol on the SQL instance that hosts the App-V Database.

Also, sorry for the lack of updates lately, been working on some other non-App-V, non-XenServer (though still mostly Xen) stuff.

App-V: Clear cache on Citrix.

Ran into a problem where I could NOT get app-v to clear the cache properly on a citrix server.

Set: HKLM\Software\Wow6432Node\Microsoft\SoftGrid\4.5\AppFS\State = 0

Delete all the OSD's in: C:\ProgramData\Microsoft\Application Virtualization Client\SoftGrid Client\OSD Cache

Stop the Application Virtualization Client Agent service (this is a dependant service to say Yes when it asks to shut down the parent service). Note that if you have the client console open at the time (or any apps) you will get a connection error, this is harmless, it's just telling you that, well, you stopped the service and it cannot connect.

Open the client console, refresh the publishing server. Problem should be solved.

A pretty common indicator that an application is stuck in the cache is Error #: 00001004

If you see that error, you probably have some OSD's hung up in the cache. If this STILL doesn't resolve it, make sure that in the user profile(s, if you aren't doing mandatory profiles) the OSD caches are cleared as well. That SHOULDN'T be an issue, it's usually the machine cache that fails to be cleaned up properly.

App-V: Excel 2010, DDE, and variations on installation type.

Here is a fun one.

If you  are like me you've had some VERY sketchy results with Office and DDE. There are several bits of information floating around about this and here is my updated current understanding of the issue.

During installation of App-V 4.6 (in this case SP1, not sure if the same applies to RTM) the following keys are written with different values based on, apparently, the type of method used to deploy the client.



When delivered via SCCM as part of a task sequence during an SD deployment DDELaunchCommand points to sfftray.exe and not sftdde.exe, and there is a different string for the MSI launch command as well.

Strangely, taking office 2010 as an example, word used to require ADDING DDE or it would present a "problem sending command to program" error, then at some point it stopped being broken.

Then, Excel stopped working with DDE, the most common search results provided a fruitless suggestion to disable the "Ignore other applications DDE" that doesn't appear to be checked by default in 2010 anymore.

The problem with this is that stripping DDE from the FTA's for excel fixes double clicking on a file locally or on a network share, but when launching a spreadsheet via SharePoint you get an error saying '%*.xslx" could not be found.

Uninstalling and reinstalling the client WILL fix this in almost every case (just make sure to reboot after the uninstall, even if it doesn't prompt you) but the idea is to fix the client for in-production machines.

The default values for SP1 for those two keys are as follows:

Windows Registry Editor Version 5.00
"DDELaunchMSICommand"="-0Ej4Sf'k=UZDv3uJ4{IRelease_Merge_Modules>OO5hSGuIH?xoVn&wQ(Ex \"<APP>\" <DDE>"
"DDELaunchCommand"="\"C:\\Program Files (x86)\\Microsoft Application Virtualization Client\\sftdde.exe\" \"<APP>\" <DDE>"
This is from a Win7x64 machine with App-V 4.6 SP1 (no HF's applied).

App-V: Unable To Import SFT, ERROR Code - 0000C81E

Since most of the old bugs are patched the most common cause I've seen for this is having a special character in the package name. For instance:

Notepad++ 4

C++ 2008 x86 SP1

etc. etc.

It is important to note that the sequencer will not save you from yourself. If it isn't a letter, number or period (.), don't use it. It will save you a lot of trouble in the long run.

App-V: Error Code 0000C800

Along with the other information floating around I have also found that if you install the App-V server on a different server than the SQL DB is hosted you need to ensure you have delegation enabled on that machine.

Failure to do so will result in the username/password that you connect to the server with being lost on the next hop to the SQL server. The resulting Access Denied will be a result of the SQL server, not the AVS, denying access to what is essentially an anonymous NT Authority account.

App-V Error: 4A-40000194

There are a few possible problems here but I find the most common is that the OSD is not pointing to either the right location, deployment method, or both.

Check the OSD's (or go in via the Sequencer if you wish, but that will typically generate a new version of the .sft, though I haven't tried in 4.6SP1, maybe that was one of the two things they got right) to ensure the correct method and location are specified.

Remember that typically speaking it will be something like:

And seldom if ever: