Winlogon Memory Leak

[Greg M]

Several of our production servers (all running Windows Server 2003 SP1 -
Standard x64 and Web Edition) are experiencing memory leaks in one of the
Winlogon processes. The Winlogon process that leaks is always the one
associated with session 0. If I look at the process list using Task Manager,
I'll see large values (up to hundreds of megabytes) in the "Mem Usage" and
"VM Size" columns. I've attached a screen dump. Most of the affected servers
have all the latest Windows patches.

Any idea what might be causing this? I couldn't find anything in the
Knowledge Base. Thanks,

[Rich]

Use the Process Explorer from Sysinternals.com and it will show you
everything running under the winlogon.exe. Most likely its going to be a 3rd
party service.

When in the Process Explorer you can right click the columns and add in
various Process Performance columns that will show where the memory is
going.

Private Bytes, Virtual Size, Start Time are good ones to look at.

Taking a closer look at your screen shot I see that w3wp.exe is using up
about the same amount of memory. I bet you find w3wp.exe running under
winlogon.exe - services.exe - svchost with process explorer. I have a web
farm that winlogon.exe takes up about 500meg of memory also but it runs
there normally because of several w3wp.exe worker processes from the web
sites we run. Does the memory usuage keep climbing until things break?

[Greg M]

We run a very active web site. The high memory usage by w3wp.exe is normal
as we cache a lot of data for performance reasons. We recycle the IIS worker
process every morning and that has no effect on memory usage by
winlogon.exe.

The memory usage seems to keep climbing until the machine is rebooted.

Same deal here. Our servers are in our data center and we use Remote Desktop
to access them.

[Justin]

We are having the exact same issue on our windows 2003 servers w/latest
service packs applied. We have run procexp on several of them and it is
really isn't one single process causing the issue. It seems like there is a
problem with winlogon.exe in general to me.

I doubt that it matters but we use RDP to access our servers and never have
hands-on access to the console. Just an FYI if an MS tech ever reads this.

Nod, same exact issue. I used procexp and tried restarting some of the
services that were associated with some of the memory usage in winlogon, this
had no effect on the overall usage. It's also interesting to note that the
amount of current memory usage doesn't seem to add up to the total current
physical, VM usage by winlogon.exe, almost as if the memory is just flat out
not being freed.

This is a real problem for us. We cannot be rebooting our production servers
every week because of this.

Update: We have WinVNC installed on one of these servers. I logged into the
console via VNC, the standard login screen was up with about 5 "out of
Virtual Memory errors". I cleared those errors, *as soon* as I logged in to
the console session the winlogon.exe memory usage went back to normal.

It's like if you're not there to login to the console winlogon.exe just
consumes more and more memory.

Perhaps installing a VNC server that will allow you to login would be a
temporary workaround for now. You will probably still have to reboot once but
it will keep you from happening to do it again in the future.

I'm still testing with this but I think that's the problem.

This is a huge problem for a "Server" operating system to have and needs to
be addressed. We have some 2003 servers w/out SP1 applied (actually some that
haven't had updates run for some time) that are not having the same issue. It
must have started happening with a recent update (in the last few months I'd
say).

What kind of threatening keywords do we need to put in our posts so an MS
tech reads this? ;-)

[Malik]

Seeing same memory over-usage by winlogon process on two Win2k3 Standard
servers. Our Win2k3 SBS server is NOT having this issue, however.

Only method to set the mem usage back to normal has been a reboot, which is
of course unacceptable.

ANYONE heard of a solution?

One more point worth noting - the PID of the winlogon that is consuming RAM
and VM matches the PID for the winlogon process associated to the
'Disconnected' session listed in Terminal Services Manager. Have tried to
reset this session, with no obvious results.

Only really have rdp access to these machines at present, so I cannot really
restart the terminal services service.

CORRECTION - the PID for winlogon matches the process used by 'Console'.

1) Thanks for the tip, will look into VNC, but 2) connected keyboard, video
and mouse to each server, logged in, and saw the same behaviour: RAM usage
went down to normal levels, and the problem has gone away. I speculate the
same as you, that for whatever reason, winlogon needs the local logon to
happen. The only remaining hitch is the amount of VM used is still way high
- will probably require a reboot to clear that up, unless there's some other
method - but I fear this RAM consumption behaviour will just start up again...

[sparkyjf]

Interesting, but reassuring to know that I'm not the only one with this
problem. I have very similar experience, and I'm struggling to find a
fix. I've worked with several Windows 2003 SP1 servers, and all will
run for months of uptime, until you log into them using the terminal
services client, after which it's only a matter of days before they
need a reboot.

I have tried logging into the console, but this doesn't seem to fix the
problem. Logging in using the TS client is definitely the trigger, but
the only fix I've found so far is a reboot, which is far from ideal for
production servers.

If anyone has any other ideas or fixes they would be most welcome.

[Justin]

And actually you can force the remote desktop client into the console session
of a server.

mstsc -v:SERVER /console

I don't know if it will help prevent the VM issue but it will definitely
make it easier to flush out the physical memory.

[dcee]

Just to say that we also have the problem...

It would be pretty interesting to have input from someone at microsoft.

I searched like hell their website, nothing about this...

Anyway, thanks for the workaround! It works great!

Another great bug by Microsoft! "Eh, it's only a production server"

[bfloeagle]

Sorry for resurrecting such an old post but this is very close to what I am experiencing as well (my problem is with CPU usage, instead of memory). My production servers are remote and accessed via RDP. We frequently seeing the winlogon.exe process taking up huge amount of CPU usage (up to a core of a multi-core box) and the only solution to free the core back up for normal use is to reboot the server. The winlogon process is always tied to a disconnected RDP session that fails to reset. As an added bonus, the console RDP port AND the physical port fail to respond (we sit at a grey screen after we logon, almost like the explorer does not start) whenever this happens.

Seeing that it has been just over two years since this was last commented on, has anyone found a solution to the memory problems you were having?? I've got a feeling that whatever may fix this leak, may also fix the problem I am having...

[kozaczek]

Hi Guys,

We are getting the same problems here, again i know its a very old post, but did anyone find a solution to this?

A bit about our situation: Running Citrix servers with Kaspersky Antivirus installed. With Kaspersky running the winlogon.exe memory grows and grows up to a point where users seem to get a problem logging on and their sessions freezing.

Turning Kaspersky off will eventually return the server to a usable state, but this can take anything up to an hour without a hard restart. Not Having Kasperky running seems to leave the server in a usable state from the start, however we have also had days where this Kaspersky IS running and everything works fine.

Any help would be appreciated.

[DaveMills]

It is so old that it has been removed from the servers so most won't have a clue
what you are talking about. Please start a new thread giving all the details of
your problem