RE: DLLHOST.EXE and Secure Server Crash

From: Michael Laing (mdonlinelaing@microsoft.com)
Date: 08/23/02


From: mdonlinelaing@microsoft.com (Michael Laing)
Date: Fri, 23 Aug 2002 21:01:38 GMT


Hi Tom,

Further to Tibor's suggestions, check and see that all of your COM+ .dll's
have been compiled with "Retain in Memory" and "Unattended Execution" both
set to "On". This is a very common problem with COM+ components and IIS.

Instead of using Exception Monitor, use Autodump+ as it gives more
information when the dump file(s) are created. You can download Autodump
Plus as part of the Debugging Tools for Windows from the following location:

http://www.microsoft.com/ddk/debugging/installx86.asp

If you require assistance debugging the dump files, you can create an
Incident with Microsoft Product Support Services.

Good luck,

Michael Laing
Microsoft Developer Support
Internet Information Server

***********************
>>Please do not send email directly to this alias. This is an online
account name for newsgroup participation only.<<

This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
2002 Microsoft Corporation. All rights reserved.
***********************
--------------------
| Content-Class: urn:content-classes:message
| From: "Tibor Biro" <tiborbiro@rogers.com>
| Sender: "Tibor Biro" <tiborbiro@rogers.com>
| References: <O$IsHPtSCHA.1468@tkmsftngp11>
| Subject: DLLHOST.EXE and Secure Server Crash
| Date: Fri, 23 Aug 2002 13:41:06 -0700
| Lines: 107
| Message-ID: <7ba701c24ae5$67c44f40$3bef2ecf@TKMSFTNGXA10>
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="iso-8859-1"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
| Thread-Index: AcJK5WfE6W2AAdkJQUeRsqsvFEhMBQ==
| Newsgroups: microsoft.public.inetserver.iis.security
| Path: cpmsftngxa10
| Xref: cpmsftngxa10 microsoft.public.inetserver.iis.security:10092
| NNTP-Posting-Host: TKMSFTNGXA10 10.201.226.38
| X-Tomcat-NG: microsoft.public.inetserver.iis.security
|
| Hi there,
|
| Try to locate the COM+ process linked to the runaway DLL
| process. You can do this by matching the process ID to the
| process ID displayed in Component Manager (in the COM+
| Applications view switch to Status View)
|
| This should point you to the failing COM+ application
| running inside dllhost.exe.
|
| If the application is IIS Out-Of-Process Pooled
| Applications then the problem is in your ASP code and
| whatever COM component it is calling at the time. In this
| case try using the IIS Exception Monitor
| (http://www.microsoft.com/technet/treeview/default.asp?
| url=/technet/prodtechnol/iis/downloads/ixcptmon.asp) to
| create a dump and examine it.
|
| Other than the above try putting all your COM components
| in separate COM+ applications and run them as Server
| Applications. This will create different dllhost.exe
| processes for each component allowing you to narrow down
| the problematic one.
|
| I hope this helps, post your progress here please.
|
| Regards,
| Tibor Biro
|
| >-----Original Message-----
| >We seriously need help with this one:
| >
| >1. We are medium-size, medium volume transaction
| ecommerce site running IIS
| >5.0 on Windows Server 2000 (SP2 and 3). We run between 6-
| 8 front end servers
| >(HTTP) with 2-3 dedicated SSL servers. We have very few
| COM objects (a third
| >party mailer object, two online payment verification
| objects), with the bulk
| >of the application written in ASP (using VBScript).
| Not .NET Framework
| >installed on any of the servers.
| >2. Somewhere around mid- to late July the SSL servers
| began to inexplicably
| >crash. The problem continues up to the present. The HTTP
| front end servers
| >do not seem to be effected. Through troubleshooting
| steps, we have
| >eliminated two pieces of software we installed at roughly
| the same time as
| >possible suspects. We also performed a code review in the
| secure area at the
| >same time.
| >
| > 3. A symptom of the problem centers around memory
| consumption by the
| >dllhost.exe process. Typically, memory consumption is
| observed to increase
| >until an error is thrown--"Address cannot be read,
| dllhost.exe." After
| >attaching Windows Debugger to a runaway dllhost.exe
| process, there are two
| >things to note: A). access is denied to the loaded module
| listing, and B).
| >the expanded info on each dllhost.exe instantiation
| reports on info coming
| >from Component Services. In one instance, the mailer
| object was listed, and
| >in most of the others, the IIS Out-Of-Process Pooled
| Applications (The Web
| >Applications Manager).
| >
| >QUESTIONS:
| >
| >1. I would like to get more information on DLLHOST.EXE.
| Specifically: How
| >does it work? How can I safely view the modules it is
| loading (Again, the
| >Debugger does not allow access to the proccesses). Any
| help here would be
| >greatly appreciated, as there seems to be a complete
| dearth of info out
| >there on the subject. Also, more info on the IIS Out-Of-
| Process Pooled
| >Applications would be great. What little info I've found
| is well-nigh
| >incomprehensible.
| >
| >2. What are some of the common reasons for excessive
| DLLHOST.EXE memory
| >consumption? Does anyone have a list of ASP/ADO errors
| that could lead to
| >problem we're dealing with? With the software eliminated
| as a possibility,
| >we're going to take another look at the ASP code again.
| >
| >Any suggestions?
| >
| >
| >
| >
| >
| >
| >
| >.
| >
|