HOWTO: Generate and Read CRS Log Files

ID: Q177748

The information in this article applies to:

Microsoft Commercial Internet System version 1.0
Microsoft Site Server versions 2.0, 3.0

IMPORTANT: This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information on how to do this, view the "Restoring the Registry" online Help topic in Regedit.exe or the "Restoring a Registry Key" online Help topic in Regedt32.exe.

SUMMARY

To troubleshoot Content Replication System (CRS), you can generate and analyze log files.

MORE INFORMATION

Windows NT Logs

CRS always writes basic logging to the Windows NT Event Log. Below is an example of the events written to the application log during a successful replication. The timestamp and machine name have been omitted:


   CRS  Information  None  15024  Summary information for replication of
   project test to server WILLBELL:
          Total Scanned          :   1733 Files 257684188 Bytes
          Actually Sent          :      8 Files   133877 Bytes
          Not Sent due to match  :   1599 Files 257550311 Bytes

   CRS  None  None    15018  Replication for project test completed
   sucessfully.
   CRS  Information  None  15017  Replication for project test started by
   user willbell with flags NONE.
   CRS  Information  None  15015  Content Replication Service started
   successfully.
   CRS  Information  None  15016  Content Replication Service shutdown
   successfully.

To save event logs, click Save As on the Log menu. If the file is large, select Event Log Files (*.EVT) as the Save As type. It is also useful to clear the Application log before doing a replication. Always verify that there are no hardware-related problems in the System log.

Generating Logs

If CRS generates an error, you will need to generate CRS log files. To do this, add the global setting FullLogging. (Note that the CRS service must be running when you modify global variables.) Three commands are needed to turn on this setting:


   crs setglobal fulllogging=YES
   crs stop
   crs start

This will add the registry key FullLogging with a value of YES to the Windows NT Registry. You can check this either with the command:


   Crs queryglobal

Or, you can add the registry value manually with Regedt32.exe. If you edit the registry, be aware of the following:

WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall Windows. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.

For information about how to edit the registry, view the "Changing Keys And Values" online Help topic in Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Data" online Help topics in Regedt32.exe. Note that you should back up the registry before you edit it.

To add the FullLogging value:

Start Registry Editor (Regedt32.exe).

Go to the following key in the registry:
HKEY_LOCAL_ MACHINE\SOFTWARE\Microsoft\CRS

On the Edit menu, click Add Value and use the following entry:
Value Name: FullLogging

Exit Registry Editor.

If you open this key and find that the value has a type of REG_UNKOWN and a hexadecimal value of 59 45 53, you mistyped the word FullLogging. Remember is that there is no error checking. Any word that you type after setglobal will be added to the registry. Obviously, if the value is not correct, no log files will be generated.

Log Files

When replication is log files will be written to this location:

<Site Server Root>:\CRS\Logfiles

There are three different log files:

CRS.LOG
CRSSRV.LOG
WEBADMIN.LOG

Crs.log is created if you use the CRS command line interface. This file will be renamed Crs.old when CRS is stopped and restarted. Webadmin.log is only generated if you open the CRS Web Administration page. This file is kept locked by the World Wide Web Publishing Service even after CRS is stopped. Thus the only way to delete or rename the Webadmin.log file is to stop and restart the WWW service. Both of these files will give information such as this the creation of a socket. Generally these files do not contain useful information.

Crssrv.log contains the information you will need to understand any problem that has happened in a replication. The Crssrv.log has a limit of 8 MB (8,388,608 bytes). Once this limit is reached, the file will be copied to Crssrv.old. Remember that only the next time the limit is reached the OLD file will be overwritten. Thus by default you will get a maximum 16 MB of log data.

If you cannot find the error in the log or the old file then you will need to increase the amount of data being logged. To increase the limit:

Start Registry Editor (Regedt32.exe).

Go to the following key in the registry:
HKEY_LOCAL_MACHINE\Software\Microsoft\CRS

On the Edit menu, click Add Value and type the following:
Value Name: LogLimit
Data Type: REG_DWORD
Radix: Dec
Value: 25165824

Exit Registry Editor.

Stop and restart the CRS service by using Services in Control Panel or

by doing either of the following at the command prompt:

Net Stop CRS

-OR-

Net Start CRS

In this example, a LogLimit value of 25165824 will produce a Crssrv.log file that will grow up to 24 MB. Then it will roll over to the Crssrv.old file. Thus you will get a total of 48 MB (24 MB+24 MB) of data.

Reading Log Files

All three log files have the same format. The file is separated into six columns: Date, Time, Type, Error Number, Thread Number, and Text Message.

The timestamp only is accurate to seconds, just like the Windows NT Event Log. The number of actions that are handled in a second make this field not useful for search purposes. It is always a good idea to synchronize the clock on the starting-point and end-point servers. You can do this with the following command:

Net time \\<machine_name> /Set

There are six types of possible log entries:


   DBG   = Debug
   INF   = Information
   WRN   = Warning
   ERR   = Error
   FTL   = Fatal
   UNK   = Unknown.

Most of the events are marked DBG and the error number is zero. If the type is not DBG or INF, you will also get an Error Number.

The next field is the Thread number. This is crucial to understanding where CRS is sending the file. If multiple destinations are configured you can find the destination by looking when a thread is created. This will tell you what files are being sent.

The final field is the Text Message. This will tell you what action is taking place. If an error occurs you can see what function was called and what line of source code was executing. In some cases you can also find the return code.

Sample Log

This is an example of an error found in the CRSSRV.LOG file:


   11/21/97 15:55:33 WRN 10053 183 recv
   @E:\77fre\server\crs\crsdll\cserve.cpp 1876

First, you should notice that the type is not set to ERR. Most of the time CRS will write a Windows NT Event as an error but in the log it has the WRN type. This is what was written to the Application Log:


   11/21/97 3:55:33 PM CRS Error  None 15162 Waiting to abort project
   CRSVIEW after losing connection with source machine.

Second, the error code written to the event log (in this case 15162) is different from the error number in the log (in this case 10053).

Third, you can see that thread 183 failed in the recv function, which is located in the CSERVE.CPP source file. The failure happened on line 1876.

Additional query words: replicate site server

Keywords : kbnetwork
Version : winnt:1.0,2.0,3.0
Platform : winnt
Issue type : kbhowto