Is it the “System” that’s really too busy to complete the request or is it App-V?

Chances are, if you have deployed App-V in a large-scale TS/RDS environment, you may have come across this intermittent error message:

Application Virtualization Error – The System is too busy to complete the request.  If the problem persists, please report it to your system administrator

Sometimes it is followed by a specific error code.

Error code 1690140A-200001CD

The error may even follow another error such as:

The Application Virtualization client could not be started. The Application Virtualization Service is not running. Report the following error code to your System Administrator: Error Code: 4602847-0FA10612-00006003.

Normally, when we get messages about the “System” being too busy to complete the request it is misleading. What is really too busy to complete the request is the App-V front end component.

When The SFTTRAY command launches, if it sees another instance of itself running, it tries to pass off whatever it was supposed to do to the existing sfttray process. If it sees that other instance but the handoff times out because the other instance isn’t responsive, it will return with this message. The error message really is telling you that SFTTRAY (or another front end component such as VAPPLAUNCHER or SFTDDE) is unable to complete the request because an App-V client component is too busy to complete the request.

There could be many underlying causes to this resulting from the SFTLIST.EXE (client service) being too busy or even the desktop configuration controller component (SFTDCC.EXE) not being responsive. If this is tied to a global DC refresh, or periodic DC refresh we could have a known issue with SFTDCC not releasing handles.

The 6th Hotfix for 4.6.0 addresses this and is available:
http://support.microsoft.com/kb/2517187

RTSPS Channels

We recently also came across another cause of this issue and it is outlined here:
http://blogs.technet.com/b/appv/archive/2011/07/28/clients-encounter-error-code-xxxxxx0a-200001cd-when-streaming-rtsps-in-microsoft-app-v.aspx

In this case, the RTSPS protocol was the culprit. RTSPS (RTSP over SSL) is limited to 255 channels and each package takes two channels.  If the total number of channels exceeds this value then the error above is generated. To resolve the issue, decrease the maximum number of channels in use at any given time by scaling out the number of RTSPS servers.

RTSP Scaling

Along that line, even if you are using RTSP, this could also be tied to scaling issues. If your DC/publishing refresh intervals are set to frequently (especially for terminal servers) you may be putting too much of a load on the SFTDCC process. Try reducing the frequency of periodic refreshes and/or increase the number of App-V Management servers for load-balancing purposes.

If you are running Citrix XenApp on a Terminal Server/RDS Server, you could be waiting on another seamless session to logoff. A good thing to verify is that the Citrix WFSHELL process releases SFTDCC properly:

• On the Citrix server, start Registry Editor.
• Locate and then click the following registry key:
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Citrix\wfshell\TWI
• Right-click LogoffCheckSysModules, and then click Modify.
• In the Value data box, type sftdcc.exe, and then click OK.
  Note If multiple values exist, separate the values by using a comma. For example, use the following format:
  ctfmon.exe,sftdcc.exe
• Exit Registry Editor.

And finally, as always, try to follow the guidelines as recommended in the following KB article (if you are running Windows 2003 x86 – all of them.)
http://support.microsoft.com/kb/973366
Under the section, “General Terminal Server Recommendations when running the App-V client” some applicability varies depending on the operating system platform and version.

• “Pre-cache all applications 100%. “(Applies to all operating systems and platforms.)
• “If you use Windows Server 2003 or older, implement a reboot cycle of the Terminal Servers . . .” (Should not need to do this on Windows Server 2008 and later.)
• “Implement UPHClean on the Terminal servers.” (not needed on Windows Server 2008 and later.)
• “Implement the following registry changes and reboot the servers” (Page Pool Memory settings not needed on Server 2008 X64 and later)
• “Verify that none of the App-V Application packages have following Virtual services if so remove them or set them to disabled.” (Still a good idea for all TS/RDS servers.)

What about the 00006003 error?

Ah yes, I alluded to that earlier. Often when this is happening, a third part filter driver is preventing the App-V Client service (SFTLIST.EXE) from starting. Check for encryption, or storage security-related applications.

Steve Thomas