ColdFusion Muse

Terminal Services, Win3k SP1 and CF May Cause Memory Leak

Mark Kruger November 7, 2005 10:43 AM Coldfusion Optimization Comments (7)

Paul Vernon posted an interesting item on CF Talk regarding a memory leak on a Windows 2003 server running SP 1. His contention was that when you log on to a Win3k server that is running Coldfusion using terminal services, then log off again, the memory is not being released from the "winlogon" process. Over time the memory usage builds up into the hundreds of megabytes causing a resource utilization issue. We've seen this as well, although I do not think it has anything to do with Coldfusion. I imagine that other 3rd party server applications would cause the same behavior. In any case, I reviewed his fix and it seems to work splendidly. Here's some more information.

Until recently his fix had been a reboot. Then he discovered that logging onto the server from the console (instead of through Terminal services) cleared out the memory in winlogon.exe. This was still not ideal because he had to physically go to the server. Luckily he found another fix.

The Fix

The terminal services client is a program called mstsc.exe. Using the switch "/console" you can force the client to log you in as if you were on the console. Here's the "quick start" version of how to get this done. Open "start-->Run" and type in mstsc /console. You will see the usual dialog box that allows you to enter an IP address or host address. Enter the name of the server and log in as you usually would. You will see that the memory usage has been flushed back to the normal range of between 4 and 16 megs (depending on sessions). This seems to work splendidly.

Other Terminal Service Tips

If you are like me you save your settings in an "RDP file. You may be used to clicking directly on the RDP file instead of opening mstsc. An RDP file is really a text file and the save as dialog box just creates a shortcut mstsc using the file as an argument. If you open the file in notepad you will see something like this.

screen mode id:i:2
session bpp:i:16
full address:s:
autoreconnection enabled:i:1
alternate shell:s:
shell working directory:s:
disable wallpaper:i:1
disable full window drag:i:0
disable menu anims:i:0
disable themes:i:0
disable cursor setting:i:0
So you can create these files easily without using the "save as" dialog from the options menu of the mstsc client. If you want a particular file to be opened in "console" mode try the following. Create a short cut to the mstsc.exe file then go to "properties" of the shortcut and edit the target. Add the /console switch followed by the full path of your file (usually in quotes). Your target should now look something like this: %SystemRoot%\System32\mstsc.exe /console "C:\Documents and Settings\*username*\Desktop\rdps\someConnectionFile.rdp". Clicking on this new shortcut will send you to that server always in console mode. Make sure that is what you want.

One more thing. The console mode allows you to adjust the video resolution and it will affect the resolution of someone subsequently logging in at the monitor that is physically at the server. If you don't know the monitor setup don't change this item. Ostensibly you could make it difficult for someone to see the screen by making the settings incompatible.

Here's Paul Vernon's own take on this issue.

Winlogon.exe and CFMX

  • Share:


  • Julian's Gravatar
    Posted By
    Julian | 11/8/05 2:49 AM
    Thanks for the useful extra details Mark. Just "saving as..." the RDP connection that pops up from the mstsc /console command does seem to work as well - i.e. when you open the saved connection again it will log you in as "console".

    Been using this for a few weeks now and it seems to be an effective solution, but I'd still like to know what's causing the leak in the first place. Like you I'm not persuaded CF is to blame. Apart from Win2k3 SP1, the other common factor seems to be Dell. Perhaps you can rule that out - what hardware are ou running on?. There was some inconclusive discussion in the MM Server Admin Forum:
  • mkruger's Gravatar
    Posted By
    mkruger | 11/8/05 7:22 AM
    Funny you should say that about Dell. It just so happens that we have lots of Win2k hardware, but all of the servers with Win3k (ours and clients) that I have access to are Dells. So I can neither confirm or deny :)

    As for the "save as" running from console mode. I suspected that, but it doesn't give you any shortcut properties to work with... and I didn't have time to verify. Thanks for the update.
  • mkruger's Gravatar
    Posted By
    mkruger | 11/8/05 7:47 AM
    I have a feeling that this KB article is our problem.
  • Adrian Langley's Gravatar
    Posted By
    Adrian Langley | 11/24/05 5:08 AM
    I too have seen this problem. The cause appears to be the version of mstsc.exe being used to remotely access the servers.

    I had installed the Terminal Services Client originally released with Windows 2000 on my WinXP workstation. This uses mstsc.exe version 5.0.2195.6674. I had happily been connecting to Win2000 machines with it, but when I later started to connect to Win2003 servers I noticed that their winlogon processes started to swell to an alarming size.

    I had installed that particular TS client because I manage dozens of servers and this allowed me to save the various connections I needed to make.

    After the clues I gained from this article, I replaced the mstsc.exe file in my C:\Program Files\Terminal Services Client folder with the version that comes with WinXP in the system32 folder (5.1.2600.2180), and the problem went away.

    If you have installed the Terminal Services Client on a Win2000 workstation, I recommend checking the version of mstsc.exe it is using, and if it is less that 5.1.* then try copying that file off a WinXP machine.
  • Julian's Gravatar
    Posted By
    Julian | 11/24/05 5:39 AM
    Adrian, I think you've cracked it. That makes complete sense in my context: I was using a Win2000 laptop to connect to both Win2K Win2K3 servers and like you only had the problem with the Win2K3 boxes. Didn't think about the client end because my colleague was using XP, but in fact it must have been just *me* that was causing the leak to start.

    Fortunately I've just upgraded my PC to XP and can confirm that the problem has gone even without using the Console setting.

    Nice one. Thanks.
  • mkruger's Gravatar
    Posted By
    mkruger | 11/24/05 9:10 AM
    Adrian - thanks for the excellent tip. I'll check out our versions and see what's up. We "mostly" connect using XP clients, so I wonder.... but I'll check the version and repost.
  • kyawam's Gravatar
    Posted By
    kyawam | 9/8/06 12:59 AM
    It happens to me also. I was trying to find the cause of winlogon.exe using so much memory and very difficult to decrease. Finally I could make this decrease by the /console method. I think we should report to Microsoft.

    BTW, thanks for the tips