Environment:

NT4 SP6a
Visual C++ 6.0

DCOM Using TCP/IP
COM components, hosted under dllhost.

Problem:

After prolonged calls (from various clients) to a remote com component
the handle count of the DLLHOST process increases continuosuly. After
a period there are no handles left and the machine stops responding,
clients see the error 'RPC Server Unavailavle'. Manually killing the
DLLHOST process allows the machine to continue.

Observations:

During the calls the CPU load is almost permanently 100%

Inspection with processExplorer (sysinternals) shows that a large number
of the handles from the DLLHOST process are unnamed events and a number
are for '\Device\Afd\Endpoint'.

Question:

Are there any issues with a NT4 system where the process is constantly
100% in use for a prolonged period ? Can this lead to a delay in the
cleanup of event object or a handle leak ?

We have done a basic code analysis to look for a handle leak, any good
tips on how to track down a leak ?

If there are issues with 100% process use, any ways to solve ?

Thanks

David McAlister

David McAlister wrote:

The is a known bug with DCOM and the default settings of "dcomcnfg"

By default DCOM uses connection-less protocols (UDP or IPX).
In this implementation DCOM is generation leaks.

Starting with W2k, MS removed all "connection-less" protocols, so the
problme does not apear on W2k.

Just remove all connection-less protocols and it should not leak.

--
Greetings
Jochen

Do you need a memory-leak finder ?
http://www.codeproject.com/tools/leakfinder.asp

We tried this already and it did help a bit, the time between 'rpc
server unavailable' became greater, doubling the ram also helped but
still no solution........

Jochen Kalmbach <nospam-Jochen.Kalmbach@holzma.de> wrote in message news:<Xns93FFB5B197A40nospamJochenKalmbach@207.46. 248.16>...

I did run into similar situation with EXE server (using DCOM). DCOM was
creating a new process (our COM EXE server) for each user. Furthermore, once
created it didn't shut them down. But there's one quirk: this was happening
with Software AG's DCOM for Solaris (our COM server ran on Solaris); we
never experience that problem with NT version of our COM EXE server.
So, isn't it possible that your DLL COM server doesn't shut-down when user
stops using it? Because DLLHOST creates a separate thread (in DLLHOST
process) for each user, isn't it possible that your new threads are created
but never being shut down in DLLHOST?
I would check how you implement DllCanUnloadNow() method in your COM server.

Boris

"David McAlister" <david@dmcalister.com> wrote in message
news:e8b1c11.0309222212.cd6664@posting.google.com. ..