New Citrix Utility – TSUserLog


Document ID: CTX114179   /   Created On: May 14, 2008   /   Updated On: May 15, 2008

TSUserLog is a simple Win32 logging utility that allows an administrator to capture Terminal Services user information, such as their session ID’s, states, and Winstation names. It also captures additional details regarding the Terminal Services session, and logs all this information to a CSV file at specified intervals (see the screen shot below).


Windows XP Professional, Windows 2000 Server, or Windows Server 2003.

Terminal Services enabled

Installing TSUserLog

Download and unzip the attached file. There is no additional installation process.

How To Use TSUserLog

1. To configure the log file name and location, click the File menu, then click Set Log Path.

If you don’t configure a log file name and path here, then the log file is placed in the current directory in which the application is running, named TSUserLog.csv.

2. Enter a desired interval (in minutes) of when you want to query for the session information and have its results logged to the file. The default setting is 5 minutes.

Note: The minimum interval allowed is 1 minute.

3. Click Start to begin. (Notice that it becomes disabled and a progress control indicates that it is currently running.)

To hide this application but still allow the application to capture the session information, click Hide.

The following informational message appears:

After clicking OK, the application disappear. As the message indicates, pressing the [SHIFT + UP ARROW] on the keyboard causes the application to appear again.

To stop logging, click Stop on the application. Notice that the Start button becomes active again, ready for the next logging session.

What Gets Logged:

SESSION NAME ID STATE Published Application Client Name User Name Domain Initial Application Client Address Client Build Number Client Directory Working Directory Client Display TIME:

Use Case:

This application was inspired by troubleshooting a deadlocked server, where the normal cause of the deadlock was a session going into a Down state. Typically, analyzing the full memory dump of the server can indicate which session is responsible for this; however, in most cases the memory dumps were corrupted to the point that it did not allow for this in-depth analysis. Knowing the problematic session ID beforehand allows for a more direct approach when analyzing the memory dump because it allows you to delve directly into the problem session memory space for analysis.

Download @