Errors And Debugging

Your client and server programs might work the first time you activate them, but probably they won't. Herein lies the big problem with DCOM.

If you're trying to make things work in a real-world network situation, you're going to hit some snags.

Remote connection problems usually come in four flavors:

1. The client and server didn't work to start with. Debug locally before you try it over the network.

2. Connection problems. If you can't get a good network connection between the client and server computer, DCOM will never work.

Network configuration can be complex.

3. Launching problems. COM will not start the COM server program on the server computer. This is usually a security or registration

problem.

4. You can't connect to the COM object on the server. This is usually a security or registration problem.

The following section discusses some of the problems you may encounter when working across a network. I've tried to outline some of the

approaches I've found useful in diagnosing and fixing problems. Here are some suggestions about how to debug network problems with DCOM.

Step 1: Get it working locally

The first step in debugging is to get the client and server working locally. Install both components on the server machine, and keep at it until

you can successfully communicate. If a component won't work locally, it won't work across a network. You probably developed and tested the

application on a single computer, but if the server is being installed on a different computer, test both client and server on that system too.

By getting the system to work locally, you've eliminated most of the common programming and registration errors. There are still a few things,

like security and remote activation, that you can only test across the network. Specify your local computer in the COSERVERINFO structure,

which will exercise much of the network-related code.

Step 2: Be sure you can connect

Before you even try to install your program, first test and debug the network configuration between the client and server machines. Start by

checking the network neighborhood to ensure that you can browse the remote computer. This is not always possible, but a failure to browse

doesn't necessarily mean that DCOM won't work. In most cases, however, browsing is good starting place for checking connections. Check the

connection in both directions.

Perhaps the most useful tool is PING. PING sends a series of network packets to a specific machine and waits for a response. Most

installations support PING.

C:\> PING www.iticentral.com

Pinging www.iticentral.com 216.27.33.21 with 32 bytes of data:

Reply from 216.27.33.21: bytes=32 time=217ms TTL=120

Reply from 216.27.33.21: bytes=32 time=210ms TTL=120

Reply from 216.27.33.21: bytes=32 time=197ms TTL=120

Reply from 216.27.33.21: bytes=32 time=209ms TTL=120

Ping statistics for 216.27.33.21:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 197ms, Maximum = 217ms, Average = 208ms

C:\>

PING does a number of interesting things for you. First, it resolves the name of the remote computer. If you're using TCP/IP, the name of the

remote computer will be converted to a TCP/IP address. In the above example, PING converts the name "www.iticentral.com" into the TCP/IP

address 216.27.33.21.

You should try PING from both directions. If you are using callbacks or connection points, you must have COM working in both directions.

Callbacks and connection points can be very difficult to debug unless you know the network connection is working.

Step 3: Try it out. Don't forget to register the proxy/stub DLL or type library

http://devcentral.iticentral.com/articles/DCOM/intro_DCOM/part3/default.php (8 of 11) [7/9/2001 2:53:00 PM]

DevCentral - Understanding DCOM - Part III

Once you've finished the first two steps, it's worth trying the remote connection. If it works, consider yourself blessed.

The most common reasons for an otherwise OK connection to fail are registration problems. Be sure you registered the COM server on the

server computer. Be sure you registered the proxy/stub DLL on both the client and server computer. If you're using an automation or dual

interface, be sure the type library is registered on both systems. (To register a proxy/stub DLL, use the REGSVR32 command.)

Step 4: Try to get around name resolution problems

Name resolution can be a vexing problem in remote connections. Most people want to work with names like "\\RAOUL" and "\\SERVER" rather

then TCP/IP addresses. The process of turning that readable name into a network address is called Name Resolution, and it can be very

complicated on some system configurations. A common work-around is to refer to the server by its TCP/IP address. This will eliminate many

name resolution problems - which are outside the scope of this discussion. You can easily put a TCP/IP address instead of a standard computer

name into the COSERVERINFO structure.

You can also glean interesting information from the TRACERT (trace route) utility. If you have weird network configurations, they may show

up here.

C:\> TRACERT www.iticentral.com

Tracing route to www.iticentral.com 216.27.33.21

over a maximum of 30 hops:

1 184 ms 169 ms 182 ms ct1.intercenter.net [207.211.129.2]

2 182 ms 189 ms 188 ms ts-gw1.intercenter.net [207.211.129.1]

3 195 ms 192 ms 161 ms ilan-gw1.intercenter.net [207.211.128.1]

4 220 ms 178 ms 206 ms 206.152.70.33

5 188 ms 207 ms 216 ms 207.211.122.2

6 196 ms 189 ms 205 ms 216.27.1.71

7 * * * Request timed out.

8 201 ms 221 ms 197 ms rampart.iticentral.com [216.27.12.142]

9 210 ms 205 ms 192 ms www.iticentral.com [216.27.33.21]

Trace complete.

C:\>

As you can see, the route your DCOM packets are taking to their destination may be surprising!

Be especially aware of gateways, routers, proxies, and firewalls, as they will often block your connection. Firewalls in particular must be

scrutinized, because firewalls will often block DCOM packets. Check with the network administrator.

Step 5: Can't launch the server?

By launching, we mean that COM automatically starts the server on request. This should always work on a local COM connection, but it can be

problematic with network connections. If you're working with Windows 95/98, COM won't automatically launch a server. This limitation is

necessary because of the lack of security on these operating systems. Because Windows NT provides full-blown security, it can automatically

launch servers.

The work-around for this problem with Windows 95/98 clients is simple. Manually start the server before the client connects. Once the server is

launched, it will connect normally.

There is one big 'gotcha'. The server will shutdown as soon as the last client calls Release() . The COM server's reference count will be zero,

and the server will shut itself down. This means the client will fail the next time it tries to connect. You'll get RPC_S_SERVER_UNAVAILABLE or

E_ACCESSDENIED from your call to CoCreateInstanceEx.

My favorite solution is to run a simple "watchdog" program on the server computer. This simple application always maintains a COM connection

to the server. Because this program runs from the server computer, it launches the server automatically when it starts. As long as the

watchdog program is running, the server will stay alive. If desired, you can start the watchdog program from the Startup group to bring the

server up when the machine boots.

Step 6: Try DCOMCNFG and OLEVIEW

You've probably already been using these tools. DCOMCONF and OLEVIEW are two Microsoft utilities that show you registration information

about your COM servers. Both of these products show you registry information in a more structured format. Both tools have disadvantages.

OLEVIEW shows you a lot more information than you may want to see. The latest version of this utility has many good features, and you

should get the latest download download at Microsoft's site: http://www.microsoft.com/com/resource/oleview.php. DCOMCNFG is a fairly crude

tool. It shows a lot of information, but many people have trouble using it effectively. If you aren't already using one of these tools, you should

http://devcentral.iticentral.com/articles/DCOM/intro_DCOM/part3/default.php (9 of 11) [7/9/2001 2:53:01 PM]

DevCentral - Understanding DCOM - Part III

start. There are also some good third-party COM utilities you can preview on the Internet.

Step 7: Re-Register the server and proxy/stub (or Typelib)

Sometimes re-registering the server and proxy/stub DLL can do wonders. If you're using Automation (or dual) interfaces, re-register the type

library.

Step 8: Ask a network administrator

Sometimes the best line of defense will be a competent network administrator. If you've got one, you're lucky. Unfortunately, competent

network administrators are a) rare, b) very busy, and c) averse to working with pesky programmers. An administrator may be able to help you

resolve tough security and name resolution problems.