FIX: IP Is Mangled When Using UDP on Multihomed Computers

When you are running a COM server on a multi-homed computer using UDP as the DCOM protocol, the IP address list that is returned in the RPC response packet might be garbled. If you use network sniffers, such as the Network Monitor, you can see the incorrect IP addresses.

This occurs when your application acts like a "server" (that is, when it needs to hand back an interface pointer to the caller). For example, when you are using connection points, the client calls IConnectionPoint::Advise() to pass a sink interface pointer to the server. If the client is running on a multi-homed computer using UDP as the DCOM protocol, the IP address list returned as a result of that call contains the mangled IP addresses.

Using standard marshaling, when the client asks for an interface pointer from a server, the client gets back a marshaled object reference packet. This packet contains the bindings of the OXID Resolver (OR) process of the server machine. For IP transports, these bindings contain the IP addresses of the server machine. When using UDP over IP and when there are multiple IP addresses in the bindings, these addresses may be garbled. When the OR on the client computer tries to resolve the addresses in the bindings, it will try to call an incorrect address. This call times out. This can cause delays or errors in calls.

Change the DCOM protocol to use TCP to work around this problem. You can do this by moving TCP protocol to the top (in NT4 UDP is at the top) in the registry for the value of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\DCOM Protocols using Regedt32.exe.

To resolve this problem, obtain the latest service pack for Windows NT 4.0 or Windows NT Server 4.0, Terminal Server Edition. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
For your convenience, the English version of this post-SP3 hotfix has been posted to the following Internet location. However, Microsoft recommends that you install Windows NT 4.0 Service Pack 4 to correct this problem.

Microsoft has confirmed that this is a problem in Windows NT 4.0 and Windows NT Server 4.0, Terminal Server Edition. This problem was first corrected in Windows NT 4.0 Service Pack 4.0 and Windows NT Server 4.0, Terminal Server Edition Service Pack 4.