DCOM : Problem with Windows 2000

[ip5dev]

Hi,

I have a DCOM exe written in C++ using ATL. I tested it using a client firing events to the server and the server firing events to the client. It works fine when I'm running the server on Windown NT 4.0, but when I try it on a Windows 2000 Advanced server or Professional, the client stop receiving the events from the server after some times, usually about 15 minutes. The client is not disconnected because it continue to fire the events on the server.

It may helps if I add that the client side and server side use a COM DLL to communicate with the COM exe. The DLL is only a wrapper of the COM methods, events and properties to interface with Visual Foxpro. I tested with MFC and the same problem occurs.

The COM is STA and each clients has a thread that is used to fire events on the client.

Is there anyone that already had that problem?

Any help would be greatly apreciated,

Thank you

 

[marieotoole]

HI

I'm having exactly the same problem but on WindowsNT Server.

Again any help would be appreciated

 

[ThierryF]

Same Problem!

Any help would be appriated.

Have a look at my thread!

"DCOM - Disconnection Problem"

 

[ip5dev]

I am currently invistigating this problem with Microsoft.

I just checked the hResult returned by pDispatch->Invoke pn the server and it returned DISP_E_EXCEPTION every time the event is fired and RPC_E_DISCONNECTED when the client stop receiving the events. I've tried to check the struct EXCEPINFO but it was all empty except for scode field that have a random value, either 0xCCCCCCCC or 0xFFFFFFFF.

I'm not sure if it's the data used in the parameters, I have 2 events out of 6 that return this exception and both of them have 1 BSTR parameter.

They told me to check this article in the knownledge base :
Q198623. It tells how to debug exception. It didn't really help for me but maybe it may be useful to you. They referred me also to Q201573, but it was fixed on WinNT with SP5.

Anyway, if you have more informations on that matter, please tell them. Any help is always welcome.

 

[jcasetnl]

We're having a similar problem. We call our objects from IIS/ASP. After restarting IIS, a period of inactivity and/or killing all dllhosts we *sometimes* get a 'create object failed' after we exceed the asp script time out. I would guess about 1/3 of the time. But if you hit the refresh button after it fails on the browser the correct page comes back *immediately*. Still the client is worried about these types of failures since it's only a handful of testers right now(and not the many thousands of users they're planning for). The problem is clearly not load related. It appears to happen when the object is first instantiated.

I read an article on MTS a while back and they recommended object pooling (which I understand is now available with COM+), especially for objects that make db calls because the creation of the object and building of the odbc connection is so expensive. Right now we're doing it per global.asa

Has anyone who has built objects that interact with a db backend found this to 1) Increase reliability and or 2) increase performance?

thanks in advance

best..
j

 

[antwerp]

Hi,

I'm having a similar problem.

I have a remote COM ptr and when the RPC_E_DISCONNECTED error is encountered, I call CoCreateInstance to get a new ptr and still it returns the disconnect error intermittently.

Anybody found any fix/workaround

Any help will be highly appreciated

 

[ThierryF]

We are still having this problem about the user being disconnected. What I mean by that just as it is explained above, is that the client can still sent events to the server, but the server cannot send events to the client as it seems that the client has been destroyed.

We have add some debugging, and we spotted that the server is calling the terminate event without our consent! Why we don't know!!!! All we know is that is it doing it.

We thought it may have been a vb issue, but it seems based on the answers we are seeing that it applies as well to C++ developers!

One thing we have spotted thought it is not confirmed 100%, but it seems that this problem seems to occur to client who give access to the internet to their users via a router. We have a lot of client that do not have any problems with our software and all these clients do not have access to the internet while the ones who do have access! Do that ring a bell to anyone else??? Let us know!

A work around, which is not a nice one but has worked for us, is that via an option we re-send the client object everytime which in turns updates the collection held in the server. This means that if the client object has been destroyed without our consent, it will be added again anyway!!! This works, but obviously increases your network traffic, not enormously but still!!!

Also we have checked a couple of arctiles from microsoft which explain something similar to what is happening to us, but their recommendation is SP6, which we have done, and it is still occuring?

Any ideas????

Thanks all!

Thierry

 

[bruessler]

I'm observing the same problem between Windows 2000 Server and Professional, different service packs installed.
The clients register on the server and expose an event interface towards the server. From time to time it happens that the server failes to signal an event (gets RPC_E_DISCONNECTED) although the client still works and still is able to use the severs interfaces.
That does occure with different client machines.

On

http://devguy.com/fp/Tips/COM/

I found the following hint:
> RPC_E_DISCONNECTED_DNE / RPC_E_DISCONNECTED
> COM clients must ping remote servers every 6 minutes
> If a remote server doesn't hear from a client after 6
> minutes it terminates the connection
> The service that pings the remote server is called rpcss
> There is only one rpcss process per machine (it's a
> service)
> rpcss can get "stuck" by bad processes that call
> WaitForSingleObject in a single-threaded apartment (STA),
> or when other STAs for one reason or another do not
> process the Windows event queue
> When rpcss gets stuck no "pings" can be sent out from the
> ENTIRE MACHINE
> Therefore this error might not be caused by your code!
> The problem might be caused by another process, in which
> case the resolution is pretty much hopeless. Microsoft
> technical support can help you identify the "bad"
> process.

Then the question is: is the COM object on the client machine not responding to the ping and therefore it terminates, or is the server machine failing sending pings and the client object terminates?

Since in my case there are about 60 clients registered and get events succesfully, I would suspect that the problem is on the client machine.