How To Generate and Read CRS Log Files (177748)


The information in this article applies to:

  • Microsoft Commercial Internet System 1.0
  • Microsoft Site Server 2.0
  • Microsoft Site Server 3.0
This article was previously published under Q177748
IMPORTANT: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 Description of the Microsoft Windows Registry

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 ServerName:
          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 ServerName 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.
WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.
To add the FullLogging value:
  1. Start Registry Editor (Regedt32.exe).
  2. Go to the following key in the registry:

    HKEY_LOCAL_ MACHINE\SOFTWARE\Microsoft\CRS

  3. On the Edit menu, click Add Value, and then use the following entry:

    Value Name: FullLogging

  4. 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. 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

Log files will be written to the following 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, follow these steps:
  1. Start Registry Editor (Regedt32.exe).
  2. Go to the following key in the registry:

    HKEY_LOCAL_MACHINE\Software\Microsoft\CRS

  3. On the Edit menu, click Add Value, and then type the following:

    Value Name: LogLimit
    Data Type: REG_DWORD
    Radix: Dec
    Value: 25165824

  4. Exit Registry Editor.
  5. 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.
Modification Type:MinorLast Reviewed:3/11/2005
Keywords:kbhowto kbnetwork KB177748
©2004 Microsoft Corporation. All rights reserved.