Interpreting CDiag Output and Solving Windows Networking Problems

In any Client – Server relationship, if there is a problem, how do you identify if the problem is with the Client or the Server? What if there are actually two problems – how do you isolate each problem?

Every desktop support or network tech doubtless has his (her) own approach to this problem. But when you work face to face with a problem, it’s easy to overlook the details, so how do you tell someone else how you solved a problem?

What if you can’t work face to face with a problem? What if you have to ask questions, and have the symptoms described to you, by someone that you can’t see? How about someone you can’t even talk to (using realtime voice communication)? How do you gather enough diagnostic data to decide if a networking issue is related to connectivity, name resolution, or permissioning?

I start with CDiag. The CDiag log, from each computer on a LAN, can usually help isolate the source of a problem or problems that affect Windows File Sharing. My previous article What Is CDiag (“Comprehensive Diagnosis Tool”)? explained how to setup a CDiag run, so the owner of a LAN can gather diagnostic data, and pass it to you (if you’re providing assistance), or so you can setup and run CDiag (if you’re using it in self-assist mode).

Now that you have two or more CDiag logs, how do you interpret them?

With one exception, the tests in CDiag are binary. Can Computer A ping Computer B successfully (by name / ip address)? Can Computer A view shares (“net view”) of Computer B? By observing which test is successful, and which test is not, we can isolate the problem(s) between Computers A and B.

A successful ping by name, from Computer A to Computer B, verifies connectivity between Computers A and B, and verifies successful address resolution of Computer B. If the ping is unsuccessful, what error do you see? Does it show an inability to resolve the address of Computer B (“…could not find host…”), or does it show a connectivity problem (“Pinging nnn.nnn.nnn.nnn … Request timed out”)?

Similarly, successful viewing of network shares, as in Computer A able to get results from a “new view” of Computer B, verifies successful file sharing from Computer B to Computer A. In cases where Computer B can’t be pinged from Computer A, but the results of “net view” of Computer B is successful, one can suspect a problem with TCP/IP (and look for gratuitous protocols like IPX/SPX).

There is also three-level pinging to observe. We can compare the results of pinging Computer B from Computer A, pinging Computer A from itself (by public ip address), and pinging Computer A from itself (by loopback ip address – An inability to ping either Computer B, or Computer A, from Computer A, means we must first look for a problem on Computer A. Success or failure in pinging the loopback address identifies the network adapter or the IP stack, respectively, as the initial problem to be resolved.

If a third computer is involved, a single problem is somewhat easier to isolate. Where simple inability to ping Computer B from Computer A could point to a problem with either Computer A or B, inability for both Computers A and C to ping Computer B probably indicates a problem with Computer B.

Oh yes, the one non-binary test? When you ping Computer B by name, observe the resolved address. Is it equal to the ip address by which we ping Computer B (from “ipconfig /all”)? A discrepancy here can indicate an address resolution problem, which will indeed lead to a variance of “access denied”.

When all pinging between computers is successful, ruling out connectivity problems, one turns to analysis of the “net view” commands, and similar possibilities.

Let me try and describe what tests are included in a single run of CDiag.

  • Share Enumeration
  • Ad-Hoc Browser View
  • FullTarget Tests
  • PingTarget Tests

The FullTarget Test is run against a host which is expected to be running as a server (and NetBIOS Over TCP/IP). A FullTarget Test involves:

  • Ping the target.
  • Net view the target.

The PingTarget Test is run against a host which is running TCP/IP only. A PingTarget Test involves:

  • Ping the target.

In this example, I have 5 FullTargets (Pchuck1 by name and by IP address, PChuck2 by name and by IP address, and, and 3 PingTargets (Yahoo by name and by IP address, and the router).

set FullTarget1=PChuck1
set FullTarget2=PChuck2

This results in the following tests:

  • Net Share
  • Net View
  • Ping Pchuck1
  • Net View PChuck1
  • Ping
  • Net View
  • Ping Pchuck2
  • Net View PChuck2
  • Ping
  • Net View
  • Ping
  • Net View
  • Ping
  • Ping
  • Ping

Note that this is simply one set of tests, from a 2 computer LAN. Tests for a 3 computer LAN will be more complex.

In this example, starting from the CDiag Assembled Code, and run from PChuck1, we get this output log (showing no problems, all tests returning positive results):

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: