aspnet_wp recycled

[José Miguel del Río Martínez]

Hi,
we are experiencing event ID 1001 (aspnet_wp.exe recycled due to memory
consumption) in our website. The aspnet_wp.exe consumes up to 613 Mb (60% of
RAM) and then recycles itself.
According to MS docs, as:
- .NET CLR Memory / # Bytes in all Heaps is low
- Process / aspnet_wp / Private bytes is high (aprox. 613 Mb)
we guess it is mostly native memory.
Our app is a mix of .NET and COM+ DLLs. In fact, our .NET DLL's call
third-party COM+ DLLs (hence, native memory).
Although all the memory (613 Mb) is apparently assigned to aspnet_wp.exe, we
would like to know who (which DLL) is really allocating so much memory.
Is it possible?
I’ve read several MS docs and I’m diving into WinDbg + SOS.dll. It looks
promising but it is hard. How could I check this with WinDbg?

[Scott Allen]

Hi José:

To diagnose a memory related problem like the one you describe, I
think I would first start with the CLR profiler:

http://msdn.microsoft.com/library/de...nethowto13.asp

HTH,

--
Scott
http://www.OdeToCode.com
On Thu, 5 Aug 2004 05:37:04 -0700, "José Miguel del Río Martínez"
<Jo*******************@discussions.microsoft.com > wrote:

Hi,
we are experiencing event ID 1001 (aspnet_wp.exe recycled due to memory
consumption) in our website. The aspnet_wp.exe consumes up to 613 Mb (60% of
RAM) and then recycles itself.
According to MS docs, as:
- .NET CLR Memory / # Bytes in all Heaps is low
- Process / aspnet_wp / Private bytes is high (aprox. 613 Mb)
we guess it is mostly native memory.
Our app is a mix of .NET and COM+ DLLs. In fact, our .NET DLL's call
third-party COM+ DLLs (hence, native memory).
Although all the memory (613 Mb) is apparently assigned to aspnet_wp.exe, we
would like to know who (which DLL) is really allocating so much memory.
Is it possible?
I’ve read several MS docs and I’m diving into WinDbg + SOS.dll. It looks
promising but it is hard. How could I check this with WinDbg?

[José Miguel del Río Martínez]

Thanks, Scott & Hans.
When I posted my question I had already read both links you send.
In fact, I had already downloaded and tried CLR Profiler and Allocation
Profiler.
The problem is both the links and the applications focus on managed memory,
not native memory, which seems to be my problem.

[Hans De Smaele]

José,

since it is a COM component (eventually running in the context of a COM+
application), you can write a small application (e.g. in VB6) that uses this
component. Depending if you use it in a COM+ application or not, you can
check the memory consumption of the DLLHost.exe application or the VB
applicaton. Then, when the component is compiled with symbol file creation
on, use a tool like "LeakDiag" to find the memory leak (or use "umdh.exe").
Note : LeakDiag can be obtained from your Microsoft Premium Support Engineer
(it is not free downloadable).

success.

Hans.

"José Miguel del RÃ*o MartÃ*nez" wrote:

Thanks, Scott & Hans.
When I posted my question I had already read both links you send.
In fact, I had already downloaded and tried CLR Profiler and Allocation
Profiler.
The problem is both the links and the applications focus on managed memory,
not native memory, which seems to be my problem.

[José Miguel del Río Martínez]

Thanks, Hans:
I've been trying LeakDiag but, as far as I'm aware, it works by recording
every allocation. No way to know whether they were ever released or what is
currently allocated. Well, in fact it has a flag to detect "memory leaks"
based on some parameters you configure but this is not really what I'm
looking for.
Maybe umdh best suits my needs: I'll get a umdh dump when aspnet_wp.exe gets
considerably overweighted in order to see what's in the heap and who
allocated it.
Additionally I'm working on obtaining at that time a .dmp file of the
process (i.e. with ADplus) and analyzing it later with WinDbg to obtain the
same information.

"Hans De Smaele" wrote:

José,

since it is a COM component (eventually running in the context of a COM+
application), you can write a small application (e.g. in VB6) that uses this
component. Depending if you use it in a COM+ application or not, you can
check the memory consumption of the DLLHost.exe application or the VB
applicaton. Then, when the component is compiled with symbol file creation
on, use a tool like "LeakDiag" to find the memory leak (or use "umdh.exe").
Note : LeakDiag can be obtained from your Microsoft Premium Support Engineer
(it is not free downloadable).

success.

Hans.

"José Miguel del RÃ*o MartÃ*nez" wrote:

Thanks, Scott & Hans.
When I posted my question I had already read both links you send.
In fact, I had already downloaded and tried CLR Profiler and Allocation
Profiler.
The problem is both the links and the applications focus on managed memory,
not native memory, which seems to be my problem.