Slow Citrix Reconnects from Windows Embedded Thin Client

Thin clients, based on Windows 7 Embedded, which I could only access remotely via VNC, were experiencing very slow Citrix reconnect times (15 seconds)

The thin clients had a 3rd party single sign on component, Imprivata, that replaced the normal Windows logon screen.

Reconnections from Linux thin client, or a Windows 10 laptop was much faster.

To quickly identify if single sign on was having an impact I uninstalled it and used web interface to launch Citrix.

Reconnection was still very slow, even launching from web interface…

To get a high level view of what was happening during connection process I used a simple ProcMon filter:

  • Include Operation is Process Start
  • Include Operation is Process Create
  • Include Operation is Process Exit
  • Event Class is Network

From this simple test we could see it was nearly 10 seconds from launch of CDViewer.exe before it even started network communications with the Citrix server.

Because CDViewer.exe is a .NET application I profiled it with a .NET profiler – in this case I used NProfiler (https://www.nprofiler.com/)

With ICA file downloaded, I launched CDViewer from NProfiler

image

This showed a large amount of time spent on JIT compilation:

image

Running this PowerShell script reduced reconnect time from web interface by nearly 10 seconds:

Measure-Command {
    $programDir = "C:\Program Files\Citrix"
    $ngenPath = "C:\windows\Microsoft.NET\Framework\v2.0.50727\ngen.exe"
    Write-host "Obtaining executables from $programDir"
    $files = Get-ChildItem "$programDir\*" -Include *.exe,*.dll -Recurse
    ForEach ($file in $files)
    {
        Write-Host "Checking is $file is .NET assembly"
        try
        {
            #ngen'ing Dazzle.Config DLL caused crash
            if (!$file.Name.StartsWith("ms") -and !$file.Name.StartsWith("mfc") -and !$file.Name.Contains("DazzleConfig"))
            {
            [System.Reflection.AssemblyName]::GetAssemblyName($file.FullName)
            # .NET assembly... ngen it
            ".NET assembly detected, ngen'ing"
            $imagePath = '"' + $file.FullName + '"'                                                
            Start-Process -FilePath $ngenPath -ArgumentList "install", $imagePath  -Wait -NoNewWindow 
            }
        }
        catch
        {
            # not a .NET binary
        }
    }
}

However when single sign on software was re-added, reconnections were still slow.

To trace the logon process I used ProcMon and WPR in separate instances, remotely starting them via psexec  before logon started. The tools I copied into a folder C:\support on the thin client then ran these commands:

psexec \\<thin client ip>  -u username -p password cmd.exe
cd C:\support
procmon /backingfile:log.pml /accepteula /quiet
< reproduce issue >
procmon /terminate

wpr -start GeneralProfile -start CPU -start DiskIO -start FileIO -start Registry -start Network
<reproduce issue>
wpr -stop logon.etl "Slow Citrix Reconnect"

In many cases I like to have both the ProcMon and WPR trace as I find certain problems are more easily visualised in ProcMon, some better in Windows Performance Analyser.

From this we could identify several seconds were wasted during single sign on process. Imprivata provided a registry key which cut off about 2 seconds:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\SSOProvider\VDI]
"FastConnectBypass"=dword:00000001

Further analysis of traces in Windows Performance Analyzer identified high amount of activity with fbwf.sys (File Based Write Filter) during logon process.

Switching off the File Based Write Filter saved 3-5 seconds.

Uninstalling the File Based Write Filter then installing and enabling the Enhanced Write Filter the performance improvement was maintained.

Final optimisation was using AutoRuns (http://live.sysinternals.com/autoruns.exe) to review and disable any unnecessary start up items/services, which gained another second.

However there was still a 3 second delay from Citrix receiver launching before comms with Citrix service began.

From WPR traces this showed extensive registry activity during this period. This appeared to be caused by a number of things:

  • ConfMgr.dll (Citrix Receiver Configuration DLL) calling into msi.dll!GetProductInfoA and msi.dll!MsiEnumRelatedProductsA to identify installed software
  • vddvc0n.dll (Citrix Dynamic Virtual Channel Client) calling into mstscax.dll!RefreshDevicesToRedirect and mstscax.dll!GetDevicesToREdirect

About chentiangemalc

specializes in end-user computing technologies. disclaimer 1) use at your own risk. test any solution in your environment. if you do not understand the impact/consequences of what you're doing please stop, and ask advice from somebody who does. 2) views are my own at the time of posting and do not necessarily represent my current view or the view of my employer and family members/relatives. 3) over the years Microsoft/Citrix/VMWare have given me a few free shirts, pens, paper notebooks/etc. despite these gifts i will try to remain unbiased.
This entry was posted in Citrix and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s