Friday, March 08, 2013

Citrix HDX Engine has encountered a problem and needs to close we are sorry for the inconvenience.

The scourage of many a Citrix tech. 

Citrix HDX Engine has encountered a problem and needs to close we are sorry for the inconvenience.

Numerous forum posts that I've seen without a solution.  I have encountered this across two companies and have encountered the same solution both times.


1) When you click Debug you get this information
AppName: wifca32.exe
ModName: msvcr80.dll

2) Event viewer shows "Faulting application wfica32.exe..." "faulting module msvcr80.dll..."

3) The error dialog occurs after an application is launched (maybe between 10 seconds to 120 seconds afterwards).  The user can move the dialog out of the way and continue working without issue, however clicking the "Close" button will terminate the application.  Sometimes though, the error occurs before the application is fully launched.


The Citrix client opens virtual channels as it connects to the server.

Overview of client-server data exchange using a virtual channel.
1. The client connects to the XenApp Server. The client passes information about the virtual channels it supports to the server.
2. The server-side application starts, obtains a handle to the virtual channel, and optionally queries for additional information about the channel.
3. The client virtual driver and server-side application pass data using the following two methods:
If the server application has data to send to the client, the data is sent to the client immediately. When the data is received by the client, the WinStation driver de-multiplexes the virtual channel data from the ICA stream and immediately passes it to the client virtual driver.
If the client virtual driver has data to send to the server, the data is sent the next time the WinStation driver polls it. When the data is received by the server, it is queued until the virtual channel application reads it. There is no way to alert the server virtual channel application that data was received.
4. When the server virtual channel application is finished, it closes the virtual channel and frees any allocated resources.

If your application starts and the dialog box appears afterwards; we can conclude one of the virtual channels has crashed.  Usually, if this scenario appears it's because your application has "Don't wait for printers".  If your application does not have this checkbox then sometimes the application will crash before the application is loaded.  With this knowledge we have narrowed down our culprit.  Printers.  An example of a printer list with a client that was having this issue:

We have a Citrix policy to only map the default printer, but during the virtual channel creation, all printers become connected to the server.  I was able to verify this with procmon; watching as it iterated through the registry keys for each printer.

A simple test to determine if a bad printer is causing your issue is to disable the Print Spooler service:
Click Stop

After stopping the service and terminating any existing sessions, relaunch the application.  If you no longer get an error (as in my case) then the issue is during the virtual channel creation of one of the faulty printers.  I cleaned up the printers that the user had, removing all non-needed ones and they did not encounter the error message afterwards.  There issue was resolved.  I have seen that cleaning up a printer queue is sometimes not enough and the printers need to be deleted and recreated.  I've yet to encounter a printer that I've recreated that has caused the issue to persist, but I guess it's possible.

In the example above after deleting the users printers and restarting the print spooler the printers came back.  The user did not have permission to delete the printers from the HKLM so I needed to do so manually.

So ensure you test restarting the printer spooler and see if the printer comes back to the user to ensure the user has appropriate rights to remove the printer.

Tuesday, March 05, 2013

AppV 5 - Force a global refresh

To force a global refresh in AppV 5 you have to do the following:

1) Open a command prompt to "C:\Program Files\Microsoft Application Virtualization"

2) Execute the following:
cscript.exe SyncAppvPublishingServer.vbs 1 -Global -NetworkCostAware

The number "1" is the publishing server you want to sync to.

You can view the global refresh schedule set by AppV in the Task Scheduler:

Slow Group Policy Client Side Extensions login with Windows 7

We experienced an issue when we modified a GPO to include item-level filtering on an AD group.  The issue was that Windows 7 machines with this GPO applied to where suddenly taking minutes to login.  Windows XP machines, however, logged in almost instantly.

When going through the event logs for group policy on Windows 7 we were able to identify the CSE causing this issue.  For us it was the "File processing extension".

When we looked at the group policy we saw that the item-level filtering was filtering on a group with 11,000+ objects in it.  We had two tasks in the GPO that were filtering on that group.  When I attempted to open the group utilizing ActiveRoles Server (ARS) it was taking 40-50 seconds to populate each object in the group.  I theorized that it appeared Windows 7 was iterating through each object like ARS was.  To test this I installed Wireshark on the Windows 7 and XP machines and ran "GPUPDATE /FORCE".  This triggered the CSE to execute.  The following are the traces:

XP Capture.  It queries (highlighted) the group then continues on.

Windows 7 Capture.  It queries the group then all objects within the group.

Obviously, with 11,000+ objects in the AD group Windows 7 will have a significantly slower logon if it's querying every object within the group.  Fortunately, Microsoft has put out a fix for this:

You experience a long domain logon time in Windows Vista, Windows 7, Windows Server 2008 or Windows Server 2008 R2 after you deploy Group Policy preferences to the computer

So if you are experiencing slow login times with Windows 7 it maybe worth it to try this fix.