Memory leak in aspnet_wp.exe

[Guest]

{Willy Skjveland} Hi, how can I trace a Memory leak in aspnet_wp.exe?

{Rheena} One moment please while I search it for you. It may take me a few
moments

{Willy Skjveland} I need to find out which application and which dll and
asmx page that cause the problem.

{Rheena} May I know what operating system you are using?

{Willy Skjveland} Windows 2000 server with latest patches.

{Rheena} Thanks for waiting Willy, I found this article that may help you:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/dbgch02.asp

{Rheena} Is the article provide you the direction to achieve the goal?

{Willy Skjveland} As far as I can tell this does not help me finding out
which dll/asmx or aspx page is causing the problem.

{Willy Skjveland} We have a lot of solutions developed by different
developers. Aspnet_wp.exe is using all the memory and the mashine finaly
gives no response.

{Willy Skjveland} We have to restart the aspnet_wp.exe process every day
because of this.

{Willy Skjveland} So we realy need to find out which dll/asmx or aspx page
that is consuming all the memory during the day.

{Willy Skjveland} How can we trace this?

{Willy Skjveland} Is it possible?

{Rheena} For technical questions or technical support, you may sin in and
post the specific problem description to one of the 230+ MSDN managed
newsgroups and receive a response from the community within two business
days. https://msdn.microsoft.com/subscriptions/managednewsgroups/list.aspx

{Willy Skjveland} I have searched the net and all I have found is this:
http://www.pcreview.co.uk/forums/thread-1286252.php

{Rheena} I suggest to post it on manage newsgroup where in support
professional can help you better.

 

[Ersin Gençtürk]

Hello Anton,

There is tool called memory profiler , http://memprofiler.com/
You can use this tool to find which partition of your code causes leak.

Regards,
Ersin Gençtürk

 

[Guest]

Thanks, but it must be possible to trace this without bying anoter product?

 

[Cowboy \(Gregory A. Beamer\)]

Sysinternals.com has some neat free tools. I am not sure if there is a tool
to track memory directly; you may have to go to winternals.com for a tool.
There is a free tool called Process Explorer that can show you which DLLs
are being run. As .NET leaks, at least that I have seen, are caused by
interop with underlying COM bits, knowing what is being called may help you
determine where you need to change your code (add a Dispose(), for example).

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***********************************************
Think Outside the Box!
***********************************************

 

[Kevin Spencer]

There are several things you can do. The first is to understand that .Net
does not have memory leaks. This means that while the platform does not,
your code may. So, this narrows it down to a flaw in your code.

The second is to be sure that you understand Garbage Collection. It does not
happen immediately. IOW, you may not actually have a memory leak. If memory
accumulates, but eventually is reduced, you may simply be seeing the .Net
platform managing memory.

The third thing is to look for usage of Interop assemblies that connect with
unmanaged resources. Do you have any Interop in your application? Interop
can be tricky, as unmanaged components can indeed leak memory, and not
shutting them down properly can cause a memory leak.

The fourth thing is to look for .Net classes that implement the IDisposable
interface. These are managed classes that connect to unmanaged resources,
and either must be Disposed explictly, or, if they are designed by
Microsoft, will generall be Disposed when Garbage Collection occurs. There
is no guarantee, however, and Disposing is the right way to take care of the
possible issues. Among the chief offenders here are System.IO classes,
classes that work with the file system, and database-connection-related
classes. There are others as well.

All of these will narrow the scope of your investigation tremendously. If
these fail, you can build Performance Counters into your app, and use
Performance Monitor to watch it as it runs.

See if these suggestions don't help you solve your problem. If not, we'll be
here.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
If you push something hard enough,
it will fall over.
- Fudd's First Law of Opposition

 

[Guest]

Memory accumulates, but is not eventually reduced.
When there is no more available memory the server stops responding.

We can sure look for Interop assemblies, .Net classes that implement the
IDisposable interface and other things - but it would be of great help to get
a clue where to start?
We have a lot of web pages and web-server pages /solutions running,
developed by different developers.
Many of this different solutions runs under the same application because
they need to share session values.
We therefore need to find out which web-page/web-service consuming memory.
Then we can look for all of the above in the right code.

 

[Kevin Spencer]

Well, you have 2 basic choices. You can go with the methodologies I
enumerated in response to your query about something that you don't have to
buy, or you can go with Ersin and Cowboys's suggestions, and any other
suggestions as to what analysis software you may want to buy. IOW, you need
to decide between "buy" and "diy."

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
If you push something hard enough,
it will fall over.
- Fudd's First Law of Opposition

 

[Patrice]

For a start you could try to see the ASP.NET performance counters (using
perform) and/or use the System.Web.ProcessInfo class that allows to get the
peak memory used...

It should allow for a start to see which application grows each day...

Good luck.

 

[Guest]

If you are using application variables, or/and session variables (with large
timeout), or/and truning off caching, or/and storing large datasets in
session variables...then this could cause your prb.

Resolution: Use session variables conservatively (small amount are stored
every time), use ASP caching as needed.

This could be the prb. I will try this, before diving in the other analysis
suggested by the guys (which are valid too).

 

[Jason Kester]

You have your code handy, so you'll have to do the looking.

Look for File Handles, Database Connections, and other things that rely
on objects outside of .NET. Every one of these should be living inside
a using{} block. Never open a resource in one place and rely on it
getting closed in another. If your .open() and .close() are ever more
than a few lines apart and not surrounded by a using{} block, you are
leaving yourself open to leaks*.

*leaks in this context meaning having garbage collection scheduled the
same way the Phone company schedules your DSL installation. "Friday
between noon and 5pm".

Jason Kester
Expat Software Consulting Services
http://www.expatsoftware.com/