Florin,
I wished I had answers for you. It sounds like a memory leak still, as you
are seeing the Gen2 heap grow without bounds. If you can't debug it with the
SciTech profiler, I'm not sure where to go from here. If you can make the
app crash, the crashdump files will probably be your bes bet - but analyzing
them is hard.
I would open up an MSDN Support incident, (with will cost a few hundred
dollars) and ask them for their help. They'll want a crashdump file (or
two). I've had very positive experiences with the MS folk on a
pay-per-incident basis.
If you're an MSDN Subscriber (Profssional? Universal? Preferred? I can't
keep the new things straight) you are entitled to a few support calls as
part of your subscription.
As to Win32 and Com, sometimes it's not at all obvious. For example, most of
my code is "pure managed code", but I call into the Sockets class. This
causes memory to be pinned while the sockets class in turn calls into Win32
land. My code wasn't doing any Win32 stuff, but under the hood it sure was.
--
Chris Mullins
"Florin" <ilieflorinclaudiu@hotmail.com> wrote in message
news:1141724522.081812.257700@z34g2000cwc.googlegr oups.com...[color=blue]
> Hi Chris,
>
> First of all, thank you for posting you reply. I will answer here to
> all your questions:
> 1) I am not using any calls to Win32 or COM.
> 2) I have used the same application (
http://www.scitech.se/memprofiler/
> ) as you recommended. I know about it, is very good and we bought it.
> It has helped us here to find the STA/MTA problem on server side.
> Unfortunately it has a defect: I am able to record the calls to the
> server, and then replay them. At high load, the .NET Memory Profiler
> crashes along with the application is hosting and I cannot use it on
> production for example. This time I used it for a set of
> functionalities and I could not find and excessive grow. I saw some
> bytes[] grow, but not significant (and I am using some statis fields on
> server)... I will check them, but with the dump file (according to the
> article you gave me). The test I have done with this application where
> on win 2003 server, but on this type on OS is working without problem
> (I tested this on production - same application, different behavior on
> different OS 2000 vs 2003).
> 3) The counters, yes, I checked them:
> - the heap that grows is Gen2, and not large object
> - the Private bytes grows in the same time with .NET Bytes in all
> Heaps. This suggests managed memory leak/problem. But I could not find
> it..
> 4) I am running in workstation mode. I was planning to suggest server
> mode for tests.. So you say is not a good choice..
> 5) Regarding the memory leak.. I tried, nothing got my attention... And
> is working correctly on 2003, so no leaks here. But I will keep
> searching.
> 6) Regarding WinDbg, I made a dump a while ago. I saw only free object
> followed by another allocated object. I will try to read it according
> to the article you posted.
>
> Also one thing that I not mentioned: Because of some internal
> decisions, we are deploying files that are complied in debug mode. I
> understand that GC is behaving differently in this situation. Next
> builds, I will try to make it as release and see what this brings,
> maybe more problems :)...
>
> Thanks for the reply,
> Florin
>[/color]