Troubleshoot and Log RRAS Connections

Use log files to solve connection problems

In February, I showed you how to enable Point-to-Point Protocol (PPP) logging to troubleshoot PPP-based RAS connections. This time, I broaden the discussion to include RRAS and show you how to enable Windows NT 4.0 device logging.

Enabling PPP logging under RAS is a simple matter of modifying a Registry value and selecting the degree of logging you desire. However, RRAS supports a much wider array of features than RAS supports, so NT offers a greater number of RRAS logging options. RRAS is unique because it lets you log on to the console as well as to a disk file, and lets you switch logging on or off for each RRAS protocol and feature. You can find all RRAS logging options in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTracing Registry subkey. The main Tracing subkey supports one REG_DWORD value—EnableConsoleTracing—that acts as a global toggle for console tracing (i.e., logging) for all the Tracing subkeys. Therefore, you can enable console tracing for all RRAS features by setting EnableConsoleTracing to 1. However, additional subkeys under the Tracing subkey represent individual protocols or features installed on the local RRAS server. Depending on your RRAS server's configuration, as many as 28 subkeys might exist under the Tracing subkey. Each subkey represents a different feature, protocol, or RRAS component.

Microsoft doesn't include a similar global logging option for file tracing, so you won't find an EnableFileTracing value under the Tracing subkey. As a result, NT supports RRAS file tracing only on a per-component basis. You can enable or disable console and file tracing for individual RRAS subcomponents by modifying the EnableFileTracing and EnableConsoleTracing values under the subkey representing that subcomponent.

By default, NT stores file-tracing log files under the %systemroot%tracing subdirectory (e.g., C:winnttracing). To change this default location to the directory of your choice, modify the FileDirectory value of type REG_EXPAND_SZ under a component's subkey. In addition, when you enable file tracing for any subcomponent, the system begins tracing immediately after you enable the setting. (NT even creates the %windir%tracing subdirectory if it doesn't already exist.) However, if you turn on console tracing, the setting doesn't take effect until after you stop and restart RRAS.

Device debugging is the final stop on our tour of RAS logging features. Viewing the commands and responses that the RAS device (e.g., modem or ISDN terminal adapter) receives can be quite helpful in troubleshooting a problem. To enable NT 4.0 device command logging, go to the Connections tab of the Control Panel Modems applet. In the Advanced section of an adapter's Properties dialog box, select the Record a log file check box. After you select this check box, NT immediately creates a log file. You can find the resulting log file, ModemLog_model.txt (where model is your modem's model name), in the %systemroot% directory (e.g., C:winnt). This log file contains a detailed list of the commands that the modem receives and the responses to commands that the modem sends during a session. The log file also includes general information about the modem's state (e.g., Dialing, Initializing Modem) at a given time. Often, you can use this information to pinpoint where a connection is failing and zero in on the cause.

To troubleshoot NT 3.x modem or RAS connection problems, you can capture modem commands (e.g., commands that switch.inf modem configuration files and session script files issue) in a file named device.log. To enable the device.log log file, you must modify a Registry entry and reboot the machine. (For more information about this solution, see the Microsoft article "Troubleshooting RAS Problems and Using the DEVICE.LOG File" at http://support.microsoft.com/ support/kb/articles/q102/7/82.asp.) You can also use this older device.log logging method to troubleshoot NT 4.0 problems with script files or modems that use legacy switch.inf-based (i.e., non-Unimodem) drivers.