A lightweight alternative to Process.GetCurrentProcess().ProcessName

Unfortunately, the following (seemingly harmless code) requires administrator rights (and on Windows 2003 you will need to be member of “Performance Monitor Users” group):

System.Diagnostics.Process.GetCurrentProcess().ProcessName

In most cases this is not appropriate and certainly not in a Citrix environment. If you call it without the correct permissions you the following stack dump:

Unhandled exception in EntryPoint: System.InvalidOperationException: Couldn't get process information from remote machine. ---> System.ComponentModel.Win32Exception: Access is denied    
 at System.Diagnostics.PerformanceMonitor.GetData(String item)    
 at System.Diagnostics.PerformanceCounterLib.GetPerformanceData(String item)    
 at System.Diagnostics.PerformanceCounterLib.get_CategoryTable()    
 at System.Diagnostics.PerformanceCounterLib.GetPerformanceData(String[] categories, Int32[] categoryIndexes)    
 at System.Diagnostics.NtProcessManager.GetProcessInfos(PerformanceCounterLib library)   
  --- End of inner exception stack trace ---    
 at System.Diagnostics.NtProcessManager.GetProcessInfos(PerformanceCounterLib library)    
 at System.Diagnostics.NtProcessManager.GetProcessInfos(String machineName, Boolean isRemoteMachine)    
 at System.Diagnostics.ProcessManager.GetProcessInfos(String machineName)    
 at System.Diagnostics.Process.EnsureState(State state)    
 at System.Diagnostics.Process.get_ProcessName()    

Below is a light weight alternative to System.Diagnostics.Process.GetCurrentProcess().ProcessName and does not require any special permissions:

/// <summary>
/// Returns the starting process name (same as System.Diagnostics.Process.GetCurrentProcess().ProcessName),
/// but doesn't require any admin rights.
/// </summary>
/// <returns>Returns the starting process name.</returns>
public static string GetCurrentProcessNameLite()
{
	string procName = new System.IO.FileInfo(System.Reflection.Assembly.GetEntryAssembly().Location).Name;
	if (procName.ToLower().IndexOf(".exe") > -1)
	{
		// Remove the ".exe" extension
		procName = procName.Substring(0, procName.Length - 4);
	}
	return procName;
}

Managing Terminal Services Sessions Remotely

I regularly administer Windows 2000 Server and Windows Server 2003 machine using Terminal Services. In W2K I use Terminal Services in Administration mode and in W2K3 I use Remote Desktop. Basically this is the same thing but it’s packaged a bit differently on the two OSes. In both situations there are only 2 users allowed for administration so occasionally both are used up and I can’t access the server. This may happen if two people are legitimately using the servers or if someone forgot to log off. Yes, I do have the settings set to automatically disconnect and/or log off a user after X minutes of inactivity but even with that there are times when I need to be able to manage this remotely.

You would think this would be as easy as connecting to the remote server by adding the Terminal Services Manager snap-in to a MMC console or remotely stopping and starting the service (in a pinch). Strangely, these obvious solutions aren’t available. Terminal Services Manager doesn’t exist as a snap-in to connect to a remote machine and because the TermService service is a core system service, you can’t even stop it on the local machine, let alone a remote one.

Fortunately there is an easy solution. Windows 2000+ (includes Windows XP and 2003) have two command-line tools called qwinsta and rwinsta that can query and reset a remote session.

For example, let’s say that I can’t gain access to a server using Terminal Services because both sessions are used up. I can use another server to check the status of the first one. As long as the logged in user has administrative rights on the non-accessible machine I would run this:

qwinsta /server:12.12.12.12

Where 12.12.12.12 is the IP address or name of the non-accessible machine.

This will display something like this:

   qwinsta /server:12.12.12.12
    SESSIONNAME       USERNAME                 ID  STATE   TYPE        DEVICE
    console                                     0  Conn    wdcon
    rdp-tcp                                 65536  Listen  rdpwd
    rdp-tcp#470       Bob                       1  Active  rdpwd
    rdp-tcp#471       Jane                      3  Active  rdpwd 

Now I know that Bob and Jane are the two that are logged in. Since Jane left the office 20 minutes ago I know that she forgot to log off. I don’t know where Bob is but I only need one session so I’ll ignore him for now.

To disconnect Jane’s session I would type this:

rwinsta /server:12.12.12.12 3

Notice the 3 which is the session ID I found from using qwinsta above.

Yet another option with W2K3 is a new feature that lets you connect to the desktop directly and gain a 3rd session.

If you’re like me, you probably noticed that rwinsta and qwinsta seems like strange names. This came from the Citrix Metaframe days which Terminal Services has descended from. It stands for:

qwinsta = Query WINdows STAtion
rwinsta = Reset WINdows STAtion

One final comment. Microsoft has replaced these two tools with Query but since qwinsta and rwinsta is fully compatible with W2K WinXP and W2K3 I choose to use it instead.

Note: In Windows Server 2003, you can right-click on the root in Terminal Services Manager and Connect to another server. Also, if you are in an Active Directory domain and using Windows 2000 Server, you can Connect to All Servers and access remote servers from the GUI. But, in a Windows 2000 Server not connected to a domain, you run into the limitations that prompted this blog.