Zombie processes on an RDP server?

[Mercutio]

I have a Windows Server that a client is using for remote access to a particular application. Most of the time it's completely fine, but when they run certain reports, RAM utilization balloons by 700MB per report and that RAM is not released when they exit the app or when they disconnect/log off; they've been downing the server (which is also their file server/internet access) to release the RAM.

This is a 32-bit Server 2003 machine. The application vendor won't certify the app on 64-bit anything.

It's only happening in their one line of business app and it does not happen when that app is run on a standalone desktop, only via RDP.

Before I start yelling at that app's developers, has anyone run in to anything like this before?

And yes, putting stuff in a VM would probably help, but that's not the configuration they have.

 

[BingBangBop]

http://support.microsoft.com/kb/905888?

 

[Mercutio]

Yeah. That doesn't match up with my circumstances.

 

[ddrueding]

Does it happen when you log onto the TS and run the app locally? Does it happen for all users?

 

[Mercutio]

As near as I can tell, yes to both. Seems to happen if I VNC into the console rather than RDP in. So I don't think it's specifically the result of it being RDP. I'm just trying to make sure I've got my ass covered before I start pointing fingers at the developer.

 

[ddrueding]

Of course, the only way to be really certain it is an implementation issue is to recreate the environment and see if the problem also recurs. That is a lot of work, and pointing a finger at them is less work.

 

[Mercutio]

Of course, the only way to be really certain it is an implementation issue is to recreate the environment and see if the problem also recurs. That is a lot of work, and pointing a finger at them is less work.

I agree.

I wanted to implement their setup as XP VMs back when I set it up, but they have a quarter-IT guy on site (he's also their electrician, plumber and diesel mechanic, if that gives any indication what I'm dealing with) who was afraid he wouldn't be able to handle that setup.

 

[Howell]

As near as I can tell, yes to both. Seems to happen if I VNC into the console rather than RDP in. So I don't think it's specifically the result of it being RDP. I'm just trying to make sure I've got my ass covered before I start pointing fingers at the developer.

So the problem seems to be the OS the app is running on and not the access method?

I have worked around similar OS incompatibilities by virtualizing XP onto the server until a fully compatible version was released.

 

[Mercutio]

So the problem seems to be the OS the app is running on and not the access method?

I have worked around similar OS incompatibilities by virtualizing XP onto the server until a fully compatible version was released.

They say it should run fine on Server 2003 as long as it's 32 bit. I don't have another Server 2003 machine to test and they've got deeply obnoxious copy protection in place so I can't even set up a test environment (and in fact, the copy protection is the whole reason they need RDP to begin with).

On the plus side, I spent a productive hour on the phone with one of the actual developers and they're at least willing to concede that there may be a real issue since they certify their app with Server 2003 but hadn't bothered to check more than one RDP client at a time.

 

[time]

It sounds like some sort of middleware running as a system process. It isn't detecting that the clients have disconnected. Logging back in as the same user may well pick up the previous connection; if so you'd only notice if you had a bunch of different users.

My two cent guess ...