BUG: Disabling TCP-IP Can Cause DCOM to Fail (240868)



The information in this article applies to:

  • Microsoft COM+ 1.0
  • Microsoft COM+ 1.5

This article was previously published under Q240868

SYMPTOMS

When TCP/IP on two computers are disabled (in other words, in Network Connections, the check box is disabled, but TCP/IP is not actually uninstalled), the computers are in a state in which all DCOM calls fail, even when the two computers have other enabled protocols in common.

CAUSE

The problem happens only when TCP/IP is disabled and not when it is completely uninstalled, which is generally not a common scenario.

When TCP/IP is disabled, TCP/IP will resolve to "localhost", which means "local connections only." Remote Procedure Call is still listening on TCP/IP for local connections only, and thus DCOM thinks that TCP/IP is active, when it is actually not. So when DCOM tries to use this protocol, it fails.

In Microsoft Windows 2000 and Microsoft Windows XP, DCOM implements the wire protocol by sending multiple requested protseq IDs in the activation/resolve calls. In Windows NT 4, DCOM sends only one protseq ID, and this ID is always the same as the protseq on which the call is made. Thus, if the call is on ncacn_nb_ipx, the requested protseq ID is ncacn_nb_ipx. In Windows 2000 and Windows XP, the call could be on ncacn_nb_ipx, but the protseq ID array would be ncacn_ip_tcp,ncacn_nb_ipx.

RESOLUTION

There are two possible ways to work around this problem:
  1. Remove TCP/IP from the list of DCOM protocols using DCOMCNFG on either the server or client computer. -or-

  2. Move TCP/IP down to after other protocols in the client protocol list.

STATUS

Microsoft has confirmed that this is a bug in the Microsoft products that are listed at the beginning of this article.

Modification Type:MajorLast Reviewed:10/15/2002
Keywords:kbBug kbDCOM kbDSupport kbSysAdmin KB240868