Our memory leaks?

[James Hunter Ross]

Friends,

I've been watching or W3WP process size (using Task Manager), and it grows
and grows when using our application. I am the only one on our server. I'll
end my session, either through timeout or logout, and the process size never
goes down. I could understand that if the next time I logged in the size
didn't change, implying that the process was big but had "headroom". But,
things start growing again.

I guess that we have leaks! I didn't think it was easy for a ASP.NET/C#
implmentation to leak? I've seen bad programming where a reference is held
so an object lives longer than one might expect, but once an object is
destroyed, (such as when the Session goes away), it should be freed.

Should I conclude that my app is leaking in an extreme way? How might I
ever find these things, the code looks good to us?

A friendly word or two will be very much appreciated. Thanks in advance!

James

[Jeff Siver]

I believe that what you are seeing is normal. The memory requested by
ASP.NET stays allocated to it. When garbage collection runs, the memory is
marked as available but ASP.NET doesn't return the memory to the operating
system, it keeps it so that it can be allocated to later tasks.

"James Hunter Ross" <ja********@oneilsoft.com> wrote in message
news:ef**************@TK2MSFTNGP09.phx.gbl...

Friends,

I've been watching or W3WP process size (using Task Manager), and it grows
and grows when using our application. I am the only one on our server.
I'll end my session, either through timeout or logout, and the process
size never goes down. I could understand that if the next time I logged
in the size didn't change, implying that the process was big but had
"headroom". But, things start growing again.

I guess that we have leaks! I didn't think it was easy for a ASP.NET/C#
implmentation to leak? I've seen bad programming where a reference is
held so an object lives longer than one might expect, but once an object
is destroyed, (such as when the Session goes away), it should be freed.

Should I conclude that my app is leaking in an extreme way? How might I
ever find these things, the code looks good to us?

A friendly word or two will be very much appreciated. Thanks in advance!

James

[Bruce Barker]

actually they are pretty easy to get.

you need to determine if you are leaking managed or unmanaged memory.
failing to call dispose on component objects or not calling
Marshal.ReleaseComObject() on com objects is a sure way to "leak" unmanaged
memory. managed memory "leaks" happen when too much data is stored in inproc
sessions (takes 20 minutes to be released), statics holding references.

here is an article to get you started:

http://msdn.microsoft.com/library/de...ml/dbgch02.asp

-- bruce (sqlwork.com)
"James Hunter Ross" <ja********@oneilsoft.com> wrote in message
news:ef**************@TK2MSFTNGP09.phx.gbl...

Friends,

I've been watching or W3WP process size (using Task Manager), and it grows
and grows when using our application. I am the only one on our server.
I'll end my session, either through timeout or logout, and the process
size never goes down. I could understand that if the next time I logged
in the size didn't change, implying that the process was big but had
"headroom". But, things start growing again.

I guess that we have leaks! I didn't think it was easy for a ASP.NET/C#
implmentation to leak? I've seen bad programming where a reference is
held so an object lives longer than one might expect, but once an object
is destroyed, (such as when the Session goes away), it should be freed.

Should I conclude that my app is leaking in an extreme way? How might I
ever find these things, the code looks good to us?

A friendly word or two will be very much appreciated. Thanks in advance!

James