I suspect memory leak !!

[Newbie]

We have a web application in AS. It also uses COM+ and SQL Server as
back-end.

Sometimes the size of the dllhost.exe grows unexpectedly. It is such that we
restart our IIS/ PWS. Also there is only one instance of dllhost running
when we restart the webserver but later on we notice more than one instance
sometimes.

Please suggest.

 

[Dominique]

one of your COM objects is causing it.

check that you clean up in your classes. ie. close objects and db
connections etc.
and do proper error trapping to avoid endless loops etc.

many instances of dllhost isn't really a problem, but untidy code inside COM
objects will definitely cause them to munch memory

 

[Aaron Bertrand - MVP]

The problem is almost certainly caused by something you introduced to the
system. I have never seen dllhost.exe go crazy except in cases where there
is a rogue component, an infinite loop, unclosed objects or an MDAC version
in desperate need of an upgrade. Please review http://www.aspfaq.com/2227

 

[Aaron Bertrand - MVP]

We recently diagnosed a serious memory leak in Analysis Services that was

causing our DLLHOST processes to eventually fail.

I was speaking about DLLHOST in relation to IIS and ASP. What does Analysis
Services have to do with your COM DLLs?

 

[Tony Proctor]

"almost certainly" ?

We recently diagnosed a serious memory leak in Analysis Services that was
causing our DLLHOST processes to eventually fail. I remember taking
exception to the MSDN guidelines that implicitly suggested all memory
problems were due to design/programming errors by the customer.

Tony Proctor

 

[Tony Proctor]

So was I Aaron. The web application used a number of VB components via ASP.
Most of these used both SQLServer and MS OLAP.

Tony Proctor

 

[Aaron Bertrand - MVP]

So was I Aaron. The web application used a number of VB components via
ASP.

Most of these used both SQLServer and MS OLAP.

And is this the case now, or only in your "recently diagnosed" scenario?
Did you raise the issue with Microsoft? Did you have a support ticket? Did
you get it resolved by Microsoft? Is there already a hotfix for the
problem? How do you expect them to fix something if you don't make them
directly aware of the problem? For all intents and purposes, your own
diagnosis points to OLAP as the cause only in your own isolated environment.
Until there is an issue acknowledged by the vendor, you can't expect us to
take for gospel that the problem is with OLAP. In any case, I have used MS
OLAP tools in ASP applications before (I currently maintain one such app for
2000+ clients), and I have yet to see them cause dllhost problems on their
own. So obviously my initial statement stands: there is something involved
here that you are doing differently.

 

[Tony Proctor]

Heh, steady on Aaron. I'm not asking you to take anything as gospel. My
point was merely that MS can be as guilty of a memory leak as anyone else,
and AS (Analysis Services) has a particular reputation in this area.

As it happens, the problem *was* reported to MS. They did acknowledge there
was a leak, and that our diagnosis was spot on. A non-redistibutable hotfix
was created, but then removed from their web site as soon as we took it.
This is not acceptable as all our customers need the fix too. Unfortunately,
the issue is slightly complicated by the fact the initial report was done
via an OEM partner in the US, and now has to be reported independently by
ourselves in the UK - such is the machinery of MS support. :-(

Tony Proctor

 

[Aaron Bertrand - MVP]

Your original issue mentioned nothing of Analysis Services, and I am still
going on the assumption that it is a different issue than the case you
brought up with Microsoft.

Do you want help with your initial issue, or do you want to discuss how
poorly Microsoft treated you?

If the latter, this isn't the place.

 

[Tony Proctor]

eh? Are we at cross-purposes here?

My original reply in this thread mentioned Analysis Services (or Microsoft
OLAP, as it used to be called). msolap80.dll was the hotfixed MS component.
We've confirmed that the hotfix cures our leak.

Unless the OP's problem fits the same description as ours then this
direction is not helping him. As I said before, my intention was merely to
suggest that leaks are not always the fault of the application developer.

Thanks for the offer but we'll progress the call, and the request for a
redistributable fix, through normal channels Aaron.

Tony Proctor

 

[Dominique]

ahem... if you ladies are quite done...

eh? Are we at cross-purposes here?

My original reply in this thread mentioned Analysis Services (or Microsoft
OLAP, as it used to be called). msolap80.dll was the hotfixed MS component.
We've confirmed that the hotfix cures our leak.

Unless the OP's problem fits the same description as ours then this
direction is not helping him. As I said before, my intention was merely to
suggest that leaks are not always the fault of the application developer.

Thanks for the offer but we'll progress the call, and the request for a
redistributable fix, through normal channels Aaron.

Tony Proctor

 

[Tony Proctor]

Just to follow-up on this, and show that my "AS memory leak" wasn't hot air:
details may be found at
http://support.microsoft.com/default.aspx?scid=kb;EN-US;838840

Tony Proctor