From: David Shutt (david.shuttNVB.CO.UK)
Date: Fri Aug 08 2003 - 03:10:47 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi

We are seeing a similar situation with w2k SP3. A remote DCOM client
process suddenly gets RPC_E_DISCONNECTED calling a method. The server
process is still alive and infact calling into the client using a
connection point callback interface. As far as I am aware MTA is not being
used on either & IE is not running. Is anyone else experiencing this on w2k
sp3 and aware of other scenarios that may induce this behaviour.

On Tue, 28 May 2002 12:31:54 +0200, Valery Pryamikov
<Valery.PryamikovSM.SIEMENS.NO> wrote:

>Hi,
>
>I decided to send some information here, so that it will be available in
>the list archives.
>
>
>
>Scenario #1 (checked only on W2k server/ advanced server SP2 + DCOM
>rollup fix):
>
>
>
>Problem: all DCOM interface proxies on one computer starts getting
>0x80010108 (RPC_E_DISCONNECTED) error code after 6 minutes after initial
>creation of the DCOM interface proxy.
>
>Description: W2k server box AppServer runs MTA COM server which loads
>DLL that call WaitForSingle/Mutlipe/Object/s in DLLMain/PROCESS_DETACH
>(f.e. some Oracle dlls does this if some conditions are met). The DLL
>(of course) hangs the process shutdown. If three are three (or more)
>such processes hangs on AppServer, then DCOM pinging system from all
>other boxes (W2k or WXP) to the AppServer starts erroneously disconnect
>all outstanding proxies on AppServer (per-computer basis) after 6
>minutes timeout. So, if there is some AppServer2 box that is used from
>AppServer or if some AppClient box that provides callback interface to
>the AppServer (in any running DCOM application), than they all will be
>disconnected after 6 minutes timeout, and attempts to call such
>erroneously disconnected object from AppServer will result in
>RPC_E_DISCONNECTED (0x80010108) error.
>
>Killing all processes that hangs on
>DLLMain/ProcessDetach/WaitForSingleObject on AppServer cures the problem
>with 6 minutes DCOM pinging timeout.
>
>The worst thing with this problem is that third-party program that
>exposes such behavior (hung in
>DLLMain/ProcessDetach/WaitForSingleObject) affects all DCOM client
>programs that run on the AppServer... We informed Microsoft about this
>problem.
>
>
>
>Scenario #2 (checked with Internet Explorer 5.01, 5.5, 6.0 on W2k and
>WXP).
>
>Problem: Internet Explorer doesn't process messages on main thread when
>it is starting new Internet Explorer window (the same process). Example
>- right click hyperlink and choose Open in New Window in the context
>menu.
>
>
>
>Description: The New Window of Internet Explorer is created on the new
>thread. If New Window was opened when Internet Explorer Band object was
>visible, than this band object is also automatically activated during
>startup of the New Window. If the band object is trying to unmarshall
>interface pointer from the main IE thread during startup (f.e.
>IGlobalInterfaceTable::GetInterfaceFromGlobal) then this unmarshalling
>attempt will (obviously) hung. Internet Explorer will be irresponsible
>for long period during such a hung. If it hangs for more than 6 minutes,
>it affects DCOM pinging system (disconnecting DCOM stub from DCOM
>proxies that resides on the computer which runs Internet Explorer that
>hangs during activation of new window after 6 minutes timeout).
>
>Spelunking also shown that after some period of time ( <= 30 seconds ?)
>of waiting for new window to appear, Internet Explorer attempts to
>launch yet another new window (in yet another new thread), repeating all
>activation steps that also includes activation of the band object...
>Killing Internet Explorer during its attempt to start the second window
>(which will be also hanging on the call to
>IGlobalInterfaceTable::GetInterfaceFromGlobal) somewhere in the period
>between 30 seconds to one minute after initial hung on WXP Professional
>could results in one of the running svchost starts using 100% CPU until
>the rebut of the computer (killing this svchost will immediately show a
>message that RPC service has catastrophically terminated - computer will
>automatically rebut in 30 seconds).
>
>
>
>-Valery.
>
>
>
>
>
>----------------------------------------------------------------
>Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
>contains important info. Save time, search the archives at
>http://discuss.microsoft.com/archives/index.html .
>To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.html
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]