After installing the latest Citrix Receiver 3.3, one of our techs began to experience crashes of their terminal sessions after about 1-2 minutes. I connected to my lab and installed the latest Citrix Receiver and was able to reproduce. In my case, the following error was generated: “WFICA32.EXE – Application Error. The exception Breakpoint. A breakpoint has been reached…”

An error may not always be produced, though, on the desktop. If you examine the Windows Event Viewer > Application logs you should see some type of error, either in the Visual C++ Runtime 2005 or in the actual Citrix module where the fault is being encountered in. For example:

After a little research, the most common culprit seems to be caused by printers that the workstation (XP SP3) cannot resolve to. These often have a status of “Unable to connect” and\or “Printer not found on server”:

After removing the offline printers on both the lab and the tech’s workstation, the issue went away. That being said, it might be more practical to downgrade to an earlier version of the Citrix Receiver. It’s not uncommon for network printers to be taken offline in large enterprises or decommissioned. Worse, imagine mobile users who will show all network printers as unable to connect when outside the network and trying to connect remotely to their virtual desktops. This seems specific to only Windows XP clients.

_______________________________________________________________________________________________________________

Update

I ran into this again today issue where this was happening on a user workstation even after the disconnected printers were removed. Crash dumps pointed to hpcui6dn.dll. Using the Windows local print server on the workstation, we could see that the print driver belonged to one the disconnected printers. Apparently, an “orphaned” print driver could cause the problem as well. Resolving was a simple matter of stopping and restarting the print spooler and from the local print server properties selecting Remove for the printer driver that was no longer connected.

It was reported by a local office technician that over the course of a few days several users were connecting to a site over the web that used Remote Desktop Connection to connect a remote desktop/terminal services session. Shortly after connecting, users complained the their session was being disconnected. The issue was initially troubleshot as possibly a local setting in the OS, such as the IE proxy or maybe the TMG firewall client, but switching to different proxy made no difference. It was then assumed that perhaps our network work was part of the problem. Port issue? Not likely, ports 443 and 3389 are too common and since the users were able to connect initially, this could be eliminated as the cause. Last, the remote site technical support was contacted and asked at what point inactive sessions were being dropped. The answer to that was 1 hour and so this, too, was eliminated as the cause.

Eventually, the issue made it my way, and the first thing I thought was that this was not specifically a “disconnect”. When I think disconnect, I’m thinking along the lines of excessive packet loss or corruption between the client and the server which results in a dropped connection. Another cause for a disconnected application could be that the client app or one of its components that handles the connection is crashing. To confirm my suspicion, I asked the local tech to provide me the name of one of the affected workstations. All the affected workstation were running Windows XP, which meant that if the RDP client was crashing, the post mortem debugger might be capturing this. I navigated across the network to \\computername\c$\Documents and Settings\All Users\Application Data\Microsoft\Dr Watson and saw a recent drwtsn32.log and user dump.

Read the rest of this entry »