Services.exe + handles leak (?) + windows 2000 server sp4

  • Thread starter Thread starter Joop
  • Start date Start date
J

Joop

Hello,

Im faced with the following problem. I have a client-server application
using remoting, and running both client and server on the same machine for a
few hours almost "kills" my windows2k server. I guess it has something to do
with some sort of leak somewhere, maybe even outside my own applications.
When i look at the memory usage pattern of my applications in the task
manager i dont see anything strange, memory seems to get released properly
(VM size+normal mem size). But when i look at how many handles are being
used, i notice that the amount seems to increase for services.exe. About 20
handles per second are added to the total.

Closing down my applications does not reduce the amount of handles used by
services.exe at all. Another point is that the overal memory usage as shown
by the task manager does increase up to the point where the system is unable
to function properly, but no application seems to holding on to it.

Yesterday i even got this message in the event log after a few hours:
Event Type: Error
Event Source: Srv
Event ID: 2020
The server was unable to allocate from the system paged pool because the
pool was empty.

The client-server app uses sql-server, remoting, transfers files with tcp
sockets, retrieves and stores files from a share. In my setup everything
runs on the same machine (sql, shares, client, server).

Is there any way i can investigate where these handles are used for? Or
maybe someone has suggestions what to do to pinpoint where this leak is?
 
The first thing I would do is determine if the problem is in the client or
the server. Set them up on different computers and do the same tests.

Hope that helps,
David
 
I already figured it out.... i think (or hope, im still running a test).

It looks like the RSACryptoServiceProvider im using in my code was leaking
the handles for some reason.. I created a new instance for every
"transaction" which not only slowed down the code, also kept increasing the
number of handles and in the end memory used (calling dispose on the object
didnt make a difference).... Making it static var and creating it once made
the problem go away. I still dont know why this is happening, and why even
after shutting down the program the handles count in the task manager stays
that high.
 
Joop wrote:
|| I already figured it out.... i think (or hope, im still running a
|| test).

|| why this is happening, and why even after shutting down the program
|| the handles count in the task manager stays that high.



How could you see the handle count after the program was stopped?

Willy.
 
I enabled the 'Handle Count' column in task manager

View -> Select Columns... -> Handle Count
 
But your program has gone from the TM list!
So what handle count are you looking at?

Willy.

Joop wrote:
|| I enabled the 'Handle Count' column in task manager
||
|| View -> Select Columns... -> Handle Count
||
|| |||
|||
||| Joop wrote:
||||| I already figured it out.... i think (or hope, im still running a
||||| test).
|||
||||| why this is happening, and why even after shutting down the
||||| program the handles count in the task manager stays that high.
|||
|||
|||
||| How could you see the handle count after the program was stopped?
|||
||| Willy.
 
Joop wrote:
|| Hello Wily,
||
|| In my first post i believe i refered to the handle count of windows'
|| Services.exe and how it increased and didnt decrease when i closed
|| down my programs. Its not the handle count of the dotnet apps that
|| kept rising. Sorry if i wasnt clear enough
||
||
Hi Joop,
Sorry overlooked services.exe.
This process is the host for the EventLog and PlugAndPlay services, and is in no way directly related with your service which runs
in a separate process so the handles cannot be shared, the only reason for the handle leak is IMO the eventlog service, are you or
one of the related processes (SQL ...) writing to the eventlog.
What version of the framework are you running?

Willy.
 
That surprises me.... Im using framwork version 1. I do make use of the
event log, but only once, and only during initalization of the program. What
looks like the offending part of the code doesnt make use of the event log
at all. The offending part is a thread that handles a file transfer and it
uses a RSACryptoServiceProvider to exchange a shared key between the server
and the client. I have a feeling that the thread doesnt get GC'ed correctly
after its finished, or at least the RSACryptoServiceProvider isnt cleaned up
properly even though i call the Clear (dispose) method on it. Not creating a
new RSACryptoServiceProvider for each key exchange but reusing the same
instance solved the problem. I'll have a look tomorrow if *not* using the
event log during program startup makes a difference.. it seems completely
unrelated but you never know in this business. Mind you, i ended up with
100.000+ handles.

The "module" that makes use of SQL is running on a different machine now
and doesnt seem part of the problem.

Thanks for your effort

Hi Joop,
Sorry overlooked services.exe.
This process is the host for the EventLog and PlugAndPlay services, and is
Click to expand...
in no way directly related with your service which runs
in a separate process so the handles cannot be shared, the only reason for
Click to expand...
the handle leak is IMO the eventlog service, are you or
 
Back
Top